diff --git a/packages/security_detection_engine/changelog.yml b/packages/security_detection_engine/changelog.yml index 4f04e13b310..1f3a21b59a8 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.16-beta.1 + changes: + - description: Release security rules update + type: enhancement + link: https://github.com/elastic/integrations/pull/17543 - version: 8.19.15 changes: - description: Release security rules update diff --git a/packages/security_detection_engine/deprecated_rules.json b/packages/security_detection_engine/deprecated_rules.json new file mode 100644 index 00000000000..99fc1fc9451 --- /dev/null +++ b/packages/security_detection_engine/deprecated_rules.json @@ -0,0 +1,557 @@ +{ + "015cca13-8832-49ac-a01b-a396114809f6": { + "deprecation_date": "2026/01/16", + "rule_name": "Deprecated - AWS Redshift Cluster Creation", + "stack_version": "8.19" + }, + "03a514d9-500e-443e-b6a9-72718c548f6c": { + "deprecation_date": "2025/03/14", + "rule_name": "Deprecated - SSH Process Launched From Inside A Container", + "stack_version": "8.14" + }, + "041d4d41-9589-43e2-ba13-5680af75ebc2": { + "deprecation_date": "2023/09/25", + "rule_name": "Deprecated - Potential DNS Tunneling via Iodine", + "stack_version": "8.3" + }, + "08d5d7e2-740f-44d8-aeda-e41f4263efaf": { + "deprecation_date": "2021/04/15", + "rule_name": "TCP Port 8000 Activity to the Internet", + "stack_version": "7.14.0" + }, + "09443c92-46b3-45a4-8f25-383b028b258d": { + "deprecation_date": "2026/02/04", + "rule_name": "Deprecated - Process Termination followed by Deletion", + "stack_version": "8.19" + }, + "0968cfbd-40f0-4b1c-b7b1-a60736c7b241": { + "deprecation_date": "2022/05/09", + "rule_name": "Linux Restricted Shell Breakout via cpulimit Shell Evasion", + "stack_version": "7.16" + }, + "0c9a14d9-d65d-486f-9b5b-91e4e6b22bd0": { + "deprecation_date": "2023/07/03", + "rule_name": "Deprecated - Threat Intel Indicator Match", + "stack_version": "8.5" + }, + "0f616aee-8161-4120-857e-742366f5eeb3": { + "deprecation_date": "2021/04/15", + "rule_name": "PowerShell spawning Cmd", + "stack_version": "7.14.0" + }, + "10754992-28c7-4472-be5b-f3770fd04f2d": { + "deprecation_date": "2022/05/09", + "rule_name": "Linux Restricted Shell Breakout via awk Commands", + "stack_version": "7.16" + }, + "119c8877-8613-416d-a98a-96b6664ee73a5": { + "deprecation_date": "2021/08/02", + "rule_name": "AWS RDS Snapshot Export", + "stack_version": "7.13" + }, + "120559c6-5e24-49f4-9e30-8ffe697df6b9": { + "deprecation_date": "2021/04/15", + "rule_name": "User Discovery via Whoami", + "stack_version": "7.14.0" + }, + "125417b8-d3df-479f-8418-12d7e034fee3": { + "deprecation_date": "2022/07/25", + "rule_name": "Attempt to Disable IPTables or Firewall", + "stack_version": "7.16" + }, + "139c7458-566a-410c-a5cd-f80238d6a5cd": { + "deprecation_date": "2021/04/15", + "rule_name": "SQL Traffic to the Internet", + "stack_version": "7.14.0" + }, + "1859ce38-6a50-422b-a5e8-636e231ea0cd": { + "deprecation_date": "2022/05/09", + "rule_name": "Linux Restricted Shell Breakout via c89/c99 Shell evasion", + "stack_version": "7.16" + }, + "1ba5160d-f5a2-4624-b0ff-6a1dc55d2516": { + "deprecation_date": "2026/01/16", + "rule_name": "Deprecated - AWS ElastiCache Security Group Modified or Deleted", + "stack_version": "8.19" + }, + "1c84dd64-7e6c-4bad-ac73-a5014ee37042": { + "deprecation_date": "2025/06/26", + "rule_name": "Deprecated - Suspicious File Creation in /etc for Persistence", + "stack_version": "8.18" + }, + "1defdd62-cd8d-426e-a246-81a37751bb2b": { + "deprecation_date": "2026/02/04", + "rule_name": "Deprecated - Execution of File Written or Modified by PDF Reader", + "stack_version": "8.19" + }, + "20dc4620-3b68-4269-8124-ca5091e00ea8": { + "deprecation_date": "2022/07/25", + "rule_name": "Auditd Max Login Sessions", + "stack_version": "7.16" + }, + "231876e7-4d1f-4d63-a47c-47dd1acdc1cb": { + "deprecation_date": "2023/03/04", + "rule_name": "Potential Shell via Web Server", + "stack_version": "8.3" + }, + "2377946d-0f01-4957-8812-6878985f515d": { + "deprecation_date": "2024/04/01", + "rule_name": "Deprecated - Remote File Creation on a Sensitive Directory", + "stack_version": "8.9" + }, + "28738f9f-7427-4d23-bc69-756708b5f624": { + "deprecation_date": "2024/07/18", + "rule_name": "Suspicious File Changes Activity Detected", + "stack_version": "8.10" + }, + "28896382-7d4f-4d50-9b72-67091901fd26": { + "deprecation_date": "2022/08/03", + "rule_name": "Suspicious Process from Conhost", + "stack_version": "7.16" + }, + "2f0bae2d-bf20-4465-be86-1311addebaa3": { + "deprecation_date": "2022/10/04", + "rule_name": "GCP Kubernetes Rolebindings Created or Patched", + "stack_version": "8.3" + }, + "301571f3-b316-4969-8dd0-7917410030d3": { + "deprecation_date": "2023/12/14", + "rule_name": "Malicious Remote File Creation", + "stack_version": "8.9" + }, + "30e1e9f2-eb9c-439f-aff6-1e3068e99384": { + "deprecation_date": "2026/02/04", + "rule_name": "Deprecated - Network Connection via Sudo Binary", + "stack_version": "8.19" + }, + "3115bd2c-0baa-4df0-80ea-45e474b5ef93": { + "deprecation_date": "2026/02/04", + "rule_name": "Deprecated - Agent Spoofing - Mismatched Agent ID", + "stack_version": "8.19" + }, + "3605a013-6f0c-4f7d-88a5-326f5be262ec": { + "deprecation_date": "2022/08/01", + "rule_name": "Potential Privilege Escalation via Local Kerberos Relay over LDAP", + "stack_version": "7.16" + }, + "378f9024-8a0c-46a5-aa08-ce147ac73a4e": { + "deprecation_date": "2026/01/16", + "rule_name": "Deprecated - AWS RDS Security Group Creation", + "stack_version": "8.19" + }, + "3a86e085-094c-412d-97ff-2439731e59cb": { + "deprecation_date": "2021/03/03", + "rule_name": "Setgid Bit Set via chmod", + "stack_version": "7.13" + }, + "3efee4f0-182a-40a8-a835-102c68a4175d": { + "deprecation_date": "2025/01/17", + "rule_name": "Deprecated - Potential Password Spraying of Microsoft 365 User Accounts", + "stack_version": "8.12" + }, + "43303fd4-4839-4e48-b2b2-803ab060758d": { + "deprecation_date": "2022/09/13", + "rule_name": "Web Application Suspicious Activity: No User Agent", + "stack_version": "8.5" + }, + "47f09343-8d1f-4bb5-8bb0-00c9d18f5010": { + "deprecation_date": "2021/03/17", + "rule_name": "Execution via Regsvcs/Regasm", + "stack_version": "7.14.0" + }, + "4973e46b-a663-41b8-a875-ced16dda2bb0": { + "deprecation_date": "2023/09/25", + "rule_name": "Deprecated - Potential Process Injection via LD_PRELOAD Environment Variable", + "stack_version": "8.6" + }, + "4aa58ac6-4dc0-4d18-b713-f58bf8bd015c": { + "deprecation_date": "2025/03/04", + "rule_name": "Potential Cross Site Scripting (XSS)", + "stack_version": "8.12" + }, + "4b1a807a-4e7b-414e-8cea-24bf580f6fc5": { + "deprecation_date": "2023/11/02", + "rule_name": "Deprecated - Potential Reverse Shell via Suspicious Parent Process", + "stack_version": "8.3" + }, + "521fbe5c-a78d-4b6b-a323-f978b0e4c4c0": { + "deprecation_date": "2026/02/04", + "rule_name": "Deprecated - Potential Successful Linux RDP Brute Force Attack Detected", + "stack_version": "8.19" + }, + "573f6e7a-7acf-4bcd-ad42-c4969124d3c0": { + "deprecation_date": "2025/07/09", + "rule_name": "Deprecated - Azure Virtual Network Device Modified or Deleted", + "stack_version": "8.18" + }, + "5c50ffa6-07f4-4cce-a1b7-c16928a2ed52": { + "deprecation_date": "2026/02/04", + "rule_name": "Deprecated - SSH Process Launched From Inside A Container via Elastic Defend", + "stack_version": "8.19" + }, + "5e87f165-45c2-4b80-bfa5-52822552c997": { + "deprecation_date": "2022/03/16", + "rule_name": "Potential PrintNightmare File Modification", + "stack_version": "7.13" + }, + "61c31c14-507f-4627-8c31-072556b89a9c": { + "deprecation_date": "2021/04/15", + "rule_name": "Mknod Process Activity", + "stack_version": "7.14.0" + }, + "62b68eb2-1e47-4da7-85b6-8f478db5b272": { + "deprecation_date": "2026/02/04", + "rule_name": "Deprecated - Potential Non-Standard Port HTTP/HTTPS connection", + "stack_version": "8.19" + }, + "6506c9fd-229e-4722-8f0f-69be759afd2a": { + "deprecation_date": "2022/03/16", + "rule_name": "Potential PrintNightmare Exploit Registry Modification", + "stack_version": "7.13" + }, + "66712812-e7f2-4a1d-bbda-dd0b5cf20c5d": { + "deprecation_date": "2026/02/04", + "rule_name": "Deprecated - Potential Successful Linux FTP Brute Force Attack Detected", + "stack_version": "8.19" + }, + "67a9beba-830d-4035-bfe8-40b7e28f8ac4": { + "deprecation_date": "2021/04/15", + "rule_name": "SMTP to the Internet", + "stack_version": "7.14.0" + }, + "68113fdc-3105-4cdd-85bb-e643c416ef0b": { + "deprecation_date": "2021/04/15", + "rule_name": "Query Registry via reg.exe", + "stack_version": "7.14.0" + }, + "699e9fdb-b77c-4c01-995c-1c15019b9c43": { + "deprecation_date": "2023/07/03", + "rule_name": "Deprecated - Threat Intel Filebeat Module (v8.x) Indicator Match", + "stack_version": "8.5" + }, + "6ea71ff0-9e95-475b-9506-2580d1ce6154": { + "deprecation_date": "2022/08/02", + "rule_name": "DNS Activity to the Internet", + "stack_version": "7.16" + }, + "6f1500bc-62d7-4eb9-8601-7485e87da2f4": { + "deprecation_date": "2021/04/15", + "rule_name": "SSH (Secure Shell) to the Internet", + "stack_version": "7.14.0" + }, + "6f683345-bb10-47a7-86a7-71e9c24fb358": { + "deprecation_date": "2022/05/09", + "rule_name": "Linux Restricted Shell Breakout via the find command", + "stack_version": "7.16" + }, + "72d33577-f155-457d-aad3-379f9b750c97": { + "deprecation_date": "2022/05/09", + "rule_name": "Linux Restricted Shell Breakout via env Shell Evasion", + "stack_version": "7.16" + }, + "7a137d76-ce3d-48e2-947d-2747796a78c0": { + "deprecation_date": "2021/04/15", + "rule_name": "Network Sniffing via Tcpdump", + "stack_version": "7.14.0" + }, + "7b08314d-47a0-4b71-ae4e-16544176924f": { + "deprecation_date": "2022/08/02", + "rule_name": "File and Directory Discovery", + "stack_version": "7.16" + }, + "7b3da11a-60a2-412e-8aa7-011e1eb9ed47": { + "deprecation_date": "2026/01/16", + "rule_name": "Deprecated - AWS ElastiCache Security Group Created", + "stack_version": "8.19" + }, + "7d2c38d7-ede7-4bdf-b140-445906e6c540": { + "deprecation_date": "2021/04/15", + "rule_name": "Tor Activity to the Internet", + "stack_version": "7.14.0" + }, + "81cc58f5-8062-49a2-ba84-5cc4b4d31c40": { + "deprecation_date": "2021/04/15", + "rule_name": "Persistence via Kernel Module Modification", + "stack_version": "7.14.0" + }, + "83b2c6e5-e0b2-42d7-8542-8f3af86a1acb": { + "deprecation_date": "2022/05/09", + "rule_name": "Linux Restricted Shell Breakout via the mysql command", + "stack_version": "7.16" + }, + "863cdf31-7fd3-41cf-a185-681237ea277b": { + "deprecation_date": "2026/01/16", + "rule_name": "Deprecated - AWS RDS Security Group Deletion", + "stack_version": "8.19" + }, + "86c3157c-a951-4a4f-989b-2f0d0f1f9518": { + "deprecation_date": "2024/02/22", + "rule_name": "Potential Linux Reverse Connection through Port Knocking", + "stack_version": "8.3" + }, + "87ec6396-9ac4-4706-bcf0-2ebb22002f43": { + "deprecation_date": "2021/04/15", + "rule_name": "FTP (File Transfer Protocol) Activity to the Internet", + "stack_version": "7.14.0" + }, + "89583d1b-3c2e-4606-8b74-0a9fd2248e88": { + "deprecation_date": "2022/05/09", + "rule_name": "Linux Restricted Shell Breakout via the vi command", + "stack_version": "7.16" + }, + "8acb7614-1d92-4359-bfcf-478b6d9de150": { + "deprecation_date": "2025/01/17", + "rule_name": "Deprecated - Suspicious JAVA Child Process", + "stack_version": "8.12" + }, + "8fed8450-847e-43bd-874c-3bbf0cd425f3": { + "deprecation_date": "2022/05/09", + "rule_name": "Linux Restricted Shell Breakout via apt/apt-get Changelog Escape", + "stack_version": "7.16" + }, + "90e28af7-1d96-4582-bf11-9a1eff21d0e5": { + "deprecation_date": "2022/07/25", + "rule_name": "Auditd Login Attempt at Forbidden Time", + "stack_version": "7.16" + }, + "93f47b6f-5728-4004-ba00-625083b3dcb0": { + "deprecation_date": "2026/02/04", + "rule_name": "Deprecated - Modification of Standard Authentication Module or Configuration", + "stack_version": "8.19" + }, + "947827c6-9ed6-4dec-903e-c856c86e72f3": { + "deprecation_date": "2026/02/04", + "rule_name": "Deprecated - Creation of Kernel Module", + "stack_version": "8.19" + }, + "97da359b-2b61-4a40-b2e4-8fc48cf7a294": { + "deprecation_date": "2022/05/09", + "rule_name": "Linux Restricted Shell Breakout via the SSH command", + "stack_version": "7.16" + }, + "97f22dab-84e8-409d-955e-dacd1d31670b": { + "deprecation_date": "2021/04/15", + "rule_name": "Base64 Encoding/Decoding Activity", + "stack_version": "7.14.0" + }, + "98fd7407-0bd5-5817-cda0-3fcc33113a56": { + "deprecation_date": "2025/07/16", + "rule_name": "Deprecated - AWS EC2 Snapshot Activity", + "stack_version": "8.18" + }, + "9cf7a0ae-2404-11ed-ae7d-f661ea17fbce": { + "deprecation_date": "2023/02/16", + "rule_name": "Google Workspace User Group Access Modified to Allow External Access", + "stack_version": "8.4" + }, + "9d110cb3-5f4b-4c9a-b9f5-53f0a1707ae1": { + "deprecation_date": "2021/04/15", + "rule_name": "Trusted Developer Application Usage", + "stack_version": "7.14.0" + }, + "9d19ece6-c20e-481a-90c5-ccca596537de": { + "deprecation_date": "2026/02/04", + "rule_name": "Deprecated - LaunchDaemon Creation or Modification and Immediate Loading", + "stack_version": "8.19" + }, + "a4ec1382-4557-452b-89ba-e413b22ed4b8": { + "deprecation_date": "2020/10/30", + "rule_name": "Network Connection via Mshta", + "stack_version": "7.10.0" + }, + "a577e524-c2ee-47bd-9c5b-e917d01d3276": { + "deprecation_date": "2026/02/04", + "rule_name": "Deprecated - CAP_SYS_ADMIN Assigned to Binary", + "stack_version": "8.19" + }, + "a5f0d057-d540-44f5-924d-c6a2ae92f045": { + "deprecation_date": "2023/06/22", + "rule_name": "Potential SSH Brute Force Detected on Privileged Account", + "stack_version": "8.3" + }, + "a9198571-b135-4a76-b055-e3e5a476fd83": { + "deprecation_date": "2021/04/15", + "rule_name": "Hex Encoding/Decoding Activity", + "stack_version": "7.14.0" + }, + "ac8805f6-1e08-406c-962e-3937057fa86f": { + "deprecation_date": "2026/02/04", + "rule_name": "Deprecated - Potential Protocol Tunneling via Chisel Server", + "stack_version": "8.19" + }, + "ad0e5e75-dd89-4875-8d0a-dfdc1828b5f3": { + "deprecation_date": "2021/04/15", + "rule_name": "Proxy Port Activity to the Internet", + "stack_version": "7.14.0" + }, + "b1c14366-f4f8-49a0-bcbb-51d2de8b0bb8": { + "deprecation_date": "2021/04/15", + "rule_name": "Potential Persistence via Cron Job", + "stack_version": "7.14.0" + }, + "bc0c6f0d-dab0-47a3-b135-0925f0a333bc": { + "deprecation_date": "2025/11/21", + "rule_name": "Deprecated - AWS Root Login Without MFA", + "stack_version": "8.19" + }, + "bc8ca7e0-92fd-4b7c-b11e-ee0266b8d9c9": { + "deprecation_date": "2026/02/04", + "rule_name": "Deprecated - Potential Non-Standard Port SSH connection", + "stack_version": "8.19" + }, + "bdb04043-f0e3-4efa-bdee-7d9d13fa9edc": { + "deprecation_date": "2026/02/04", + "rule_name": "Deprecated - Potential Pspy Process Monitoring Detected", + "stack_version": "8.19" + }, + "c125e48f-6783-41f0-b100-c3bf1b114d16": { + "deprecation_date": "2026/02/04", + "rule_name": "Deprecated - Suspicious Renaming of ESXI index.html File", + "stack_version": "8.19" + }, + "c6474c34-4953-447a-903e-9fcb7b6661aa": { + "deprecation_date": "2021/04/15", + "rule_name": "IRC (Internet Relay Chat) Protocol Activity to the Internet", + "stack_version": "7.14.0" + }, + "c6655282-6c79-11ef-bbb5-f661ea17fbcc": { + "deprecation_date": "2025/07/16", + "rule_name": "Deprecated - Azure Entra Sign-in Brute Force Microsoft 365 Accounts by Repeat Source", + "stack_version": "8.18" + }, + "c87fca17-b3a9-4e83-b545-f30746c53920": { + "deprecation_date": "2021/04/15", + "rule_name": "Nmap Process Activity", + "stack_version": "7.14.0" + }, + "cab4f01c-793f-4a54-a03e-e5d85b96d7af": { + "deprecation_date": "2022/07/25", + "rule_name": "Auditd Login from Forbidden Location", + "stack_version": "7.16" + }, + "cc16f774-59f9-462d-8b98-d27ccd4519ec": { + "deprecation_date": "2021/04/15", + "rule_name": "Process Discovery via Tasklist", + "stack_version": "7.14.0" + }, + "ccc55af4-9882-4c67-87b4-449a7ae8079c": { + "deprecation_date": "2023/12/15", + "rule_name": "Potential Process Herpaderping Attempt", + "stack_version": "8.3" + }, + "cd4d5754-07e1-41d4-b9a5-ef4ea6a0a126": { + "deprecation_date": "2021/04/15", + "rule_name": "Socat Process Activity", + "stack_version": "7.14.0" + }, + "d2053495-8fe7-4168-b3df-dad844046be3": { + "deprecation_date": "2021/04/15", + "rule_name": "PPTP (Point to Point Tunneling Protocol) Activity", + "stack_version": "7.14.0" + }, + "d55436a8-719c-445f-92c4-c113ff2f9ba5": { + "deprecation_date": "2026/02/04", + "rule_name": "Deprecated - Potential Privilege Escalation via UID INT_MAX Bug Detected", + "stack_version": "8.19" + }, + "d6450d4e-81c6-46a3-bd94-079886318ed5": { + "deprecation_date": "2022/07/28", + "rule_name": "Strace Process Activity", + "stack_version": "7.16" + }, + "da986d2c-ffbf-4fd6-af96-a88dbf68f386": { + "deprecation_date": "2022/05/09", + "rule_name": "Linux Restricted Shell Breakout via the gcc command", + "stack_version": "7.16" + }, + "dc672cb7-d5df-4d1f-a6d7-0841b1caafb9": { + "deprecation_date": "2022/01/12", + "rule_name": "Threat Intel Filebeat Module (v7.x) Indicator Match", + "stack_version": "8.0" + }, + "dd7f1524-643e-11ed-9e35-f661ea17fbcd": { + "deprecation_date": "2023/07/04", + "rule_name": "Reverse Shell Created via Named Pipe", + "stack_version": "8.3" + }, + "df959768-b0c9-4d45-988c-5606a2be8e5a": { + "deprecation_date": "2022/07/25", + "rule_name": "Unusual Process Execution - Temp", + "stack_version": "7.16" + }, + "e0dacebe-4311-4d50-9387-b17e89c2e7fd": { + "deprecation_date": "2022/08/02", + "rule_name": "Whitespace Padding in Process Command Line", + "stack_version": "7.16" + }, + "e14c5fd7-fdd7-49c2-9e5b-ec49d817bc8d": { + "deprecation_date": "2026/01/16", + "rule_name": "Deprecated - AWS RDS Cluster Creation", + "stack_version": "8.19" + }, + "e56993d2-759c-4120-984c-9ec9bb940fd5": { + "deprecation_date": "2021/04/15", + "rule_name": "RDP (Remote Desktop Protocol) to the Internet", + "stack_version": "7.14.0" + }, + "e919611d-6b6f-493b-8314-7ed6ac2e413b": { + "deprecation_date": "2026/01/16", + "rule_name": "Deprecated - AWS EC2 VM Export Failure", + "stack_version": "8.19" + }, + "e9b4a3c7-24fc-49fd-a00f-9c938031eef1": { + "deprecation_date": "2022/05/09", + "rule_name": "Linux Restricted Shell Breakout via busybox Shell Evasion", + "stack_version": "7.16" + }, + "ea0784f0-a4d7-4fea-ae86-4baaf27a6f17": { + "deprecation_date": "2021/04/15", + "rule_name": "SSH (Secure Shell) from the Internet", + "stack_version": "7.14.0" + }, + "eb6a3790-d52d-11ec-8ce9-f661ea17fbce": { + "deprecation_date": "2023/07/31", + "rule_name": "Suspicious Network Connection Attempt by Root", + "stack_version": "8.3" + }, + "ecf2b32c-e221-4bd4-aa3b-c7d59b3bc01d": { + "deprecation_date": "2026/01/16", + "rule_name": "Deprecated - AWS RDS Instance/Cluster Stoppage", + "stack_version": "8.19" + }, + "ee619805-54d7-4c56-ba6f-7717282ddd73": { + "deprecation_date": "2022/05/09", + "rule_name": "Linux Restricted Shell Breakout via crash Shell evasion", + "stack_version": "7.16" + }, + "f30f3443-4fbb-4c27-ab89-c3ad49d62315": { + "deprecation_date": "2026/01/16", + "rule_name": "Deprecated - AWS RDS Instance Creation", + "stack_version": "8.19" + }, + "f41296b4-9975-44d6-9486-514c6f635b2d": { + "deprecation_date": "2026/02/04", + "rule_name": "Deprecated - Potential curl CVE-2023-38545 Exploitation", + "stack_version": "8.19" + }, + "f52362cd-baf1-4b6d-84be-064efc826461": { + "deprecation_date": "2022/05/09", + "rule_name": "Linux Restricted Shell Breakout via flock Shell evasion", + "stack_version": "7.16" + }, + "f5488ac1-099e-4008-a6cb-fb638a0f0828": { + "deprecation_date": "2025/03/14", + "rule_name": "Deprecated - SSH Connection Established Inside A Running Container", + "stack_version": "8.14" + }, + "fb9937ce-7e21-46bf-831d-1ad96eac674d": { + "deprecation_date": "2022/07/25", + "rule_name": "Auditd Max Failed Login Attempts", + "stack_version": "7.16" + }, + "fd3fc25e-7c7c-4613-8209-97942ac609f6": { + "deprecation_date": "2022/05/09", + "rule_name": "Linux Restricted Shell Breakout via the expect command", + "stack_version": "7.16" + } +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/0136b315-b566-482f-866c-1d8e2477ba16_212.json b/packages/security_detection_engine/kibana/security_rule/0136b315-b566-482f-866c-1d8e2477ba16_212.json new file mode 100644 index 00000000000..f25ccfc1de8 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/0136b315-b566-482f-866c-1d8e2477ba16_212.json @@ -0,0 +1,85 @@ +{ + "attributes": { + "author": [ + "Austin Songer" + ], + "description": "Identifies when a user has been restricted from sending email due to exceeding sending limits of the service policies per the Security Compliance Center.", + "false_positives": [ + "A user sending emails using personal distribution folders may trigger the event." + ], + "from": "now-9m", + "index": [ + "logs-o365.audit-*", + "filebeat-*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "Deprecated - M365 Security Compliance User Restricted from Sending Email", + "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 - M365 Security Compliance User Restricted from Sending Email\n\nMicrosoft 365 enforces email sending limits to prevent abuse and ensure service integrity. Adversaries may exploit compromised accounts to send spam or phishing emails, triggering these limits. The detection rule monitors audit logs for successful restrictions by the Security Compliance Center, indicating potential misuse of valid accounts, aligning with MITRE ATT&CK's Initial Access tactic.\n\n### Possible investigation steps\n\n- Review the audit logs in Microsoft 365 to confirm the event details, focusing on entries with event.dataset:o365.audit and event.provider:SecurityComplianceCenter to ensure the restriction was logged correctly.\n- Identify the user account that was restricted by examining the event.action:\"User restricted from sending email\" and event.outcome:success fields to understand which account triggered the alert.\n- Investigate the recent email activity of the restricted user account to determine if there was any unusual or suspicious behavior, such as a high volume of outbound emails or patterns consistent with spam or phishing.\n- Check for any recent changes in account permissions or configurations that might indicate unauthorized access or compromise, aligning with the MITRE ATT&CK technique T1078 for Valid Accounts.\n- Assess whether there are any other related alerts or incidents involving the same user or similar patterns, which could indicate a broader security issue or coordinated attack.\n\n### False positive analysis\n\n- High-volume legitimate email campaigns by marketing or communication teams can trigger sending limits. Coordinate with these teams to understand their schedules and create exceptions for known campaigns.\n- Automated systems or applications using Microsoft 365 accounts for sending notifications or alerts may exceed limits. Identify these accounts and consider using service accounts with appropriate permissions and limits.\n- Users with delegated access to multiple mailboxes might inadvertently trigger restrictions. Review and adjust permissions or create exceptions for these users if their activity is verified as legitimate.\n- Temporary spikes in email activity due to business needs, such as end-of-quarter communications, can cause false positives. Monitor these periods and adjust thresholds or create temporary exceptions as needed.\n- Misconfigured email clients or scripts that repeatedly attempt to send emails can appear as suspicious activity. Ensure proper configuration and monitor for any unusual patterns that may need exceptions.\n\n### Response and remediation\n\n- Immediately disable the compromised user account to prevent further unauthorized email activity and potential spread of phishing or spam.\n- Conduct a password reset for the affected account and enforce multi-factor authentication (MFA) to enhance security and prevent future unauthorized access.\n- Review the audit logs for any additional suspicious activities associated with the compromised account, such as unusual login locations or times, and investigate any anomalies.\n- Notify the affected user and relevant stakeholders about the incident, providing guidance on recognizing phishing attempts and securing their accounts.\n- Escalate the incident to the security operations team for further analysis and to determine if other accounts or systems have been compromised.\n- Implement additional email filtering rules to block similar phishing or spam patterns identified in the incident to prevent recurrence.\n- Update and enhance detection rules and monitoring to quickly identify and respond to similar threats in the future, leveraging insights from the current incident.", + "query": "event.dataset:o365.audit and event.provider:SecurityComplianceCenter and event.category:web and event.action:\"User restricted from sending email\" and event.outcome:success\n", + "references": [ + "https://docs.microsoft.com/en-us/cloud-app-security/anomaly-detection-policy", + "https://docs.microsoft.com/en-us/cloud-app-security/policy-template-reference" + ], + "related_integrations": [ + { + "package": "o365", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.category", + "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": "0136b315-b566-482f-866c-1d8e2477ba16", + "setup": "The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Data Source: Microsoft 365", + "Use Case: Configuration Audit", + "Tactic: Impact", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0040", + "name": "Impact", + "reference": "https://attack.mitre.org/tactics/TA0040/" + }, + "technique": [] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 212 + }, + "id": "0136b315-b566-482f-866c-1d8e2477ba16_212", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/0678bc9c-b71a-433b-87e6-2f664b6b3131_8.json b/packages/security_detection_engine/kibana/security_rule/0678bc9c-b71a-433b-87e6-2f664b6b3131_8.json new file mode 100644 index 00000000000..86b1ff4e409 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/0678bc9c-b71a-433b-87e6-2f664b6b3131_8.json @@ -0,0 +1,63 @@ +{ + "attributes": { + "anomaly_threshold": 70, + "author": [ + "Elastic" + ], + "description": "A machine learning job has detected an unusually high file size shared by a remote host indicating potential lateral movement activity. One of the primary goals of attackers after gaining access to a network is to locate and exfiltrate valuable information. Instead of multiple small transfers that can raise alarms, attackers might choose to bundle data into a single large file transfer.", + "from": "now-90m", + "interval": "15m", + "license": "Elastic License v2", + "machine_learning_job_id": "lmd_high_file_size_remote_file_transfer", + "name": "Unusual Remote File Size", + "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 Remote File Size\nMachine learning models in security environments analyze file transfer patterns to identify anomalies, such as unusually large files shared remotely. Adversaries exploit this by aggregating data into large files to avoid detection during lateral movement. The 'Unusual Remote File Size' rule leverages ML to flag these anomalies, aiding in early detection of potential data exfiltration activities.\n\n### Possible investigation steps\n\n- Review the alert details to identify the specific remote host and file size involved in the anomaly.\n- Check the historical file transfer patterns of the identified remote host to determine if this large file size is truly unusual.\n- Investigate the contents and purpose of the large file, if accessible, to assess whether it contains sensitive or valuable information.\n- Analyze network logs to trace the origin and destination of the file transfer, looking for any unauthorized or suspicious connections.\n- Correlate the event with other security alerts or logs to identify any concurrent suspicious activities that might indicate lateral movement or data exfiltration.\n- Verify the user account associated with the file transfer to ensure it has not been compromised or misused.\n\n### False positive analysis\n\n- Large file transfers related to legitimate business operations, such as backups or data migrations, can trigger false positives. Users should identify and whitelist these routine activities to prevent unnecessary alerts.\n- Software updates or patches distributed across the network may also appear as unusually large file transfers. Establishing a baseline for expected file sizes during these updates can help in distinguishing them from potential threats.\n- Remote file sharing services used for collaboration might generate alerts if large files are shared frequently. Monitoring and excluding these services from the rule can reduce false positives.\n- Automated data processing tasks that involve transferring large datasets between systems should be documented and excluded from the rule to avoid false alarms.\n- Regularly review and update the list of known safe hosts and services that are permitted to transfer large files, ensuring that only legitimate activities are excluded from detection.\n\n### Response and remediation\n\n- Isolate the affected host immediately to prevent further lateral movement and potential data exfiltration. Disconnect it from the network to contain the threat.\n- Conduct a thorough analysis of the large file transfer to determine its contents and origin. Verify if sensitive data was included and assess the potential impact.\n- Review and terminate any unauthorized remote sessions or connections identified during the investigation to prevent further exploitation.\n- Reset credentials and review access permissions for the affected host and any associated accounts to mitigate the risk of compromised credentials being used for further attacks.\n- Implement network segmentation to limit the ability of attackers to move laterally within the network, reducing the risk of similar incidents 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 actions are taken.\n- Enhance monitoring and logging for unusual file transfer activities and remote access attempts to improve early detection of similar threats in the future.", + "references": [ + "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html", + "https://docs.elastic.co/en/integrations/lmd", + "https://www.elastic.co/blog/detecting-lateral-movement-activity-a-new-kibana-integration", + "https://www.elastic.co/blog/remote-desktop-protocol-connections-elastic-security" + ], + "related_integrations": [ + { + "package": "lmd", + "version": "^2.0.0" + }, + { + "package": "endpoint", + "version": "^8.2.0" + } + ], + "risk_score": 21, + "rule_id": "0678bc9c-b71a-433b-87e6-2f664b6b3131", + "setup": "## Setup\n\nThis rule requires the `host.ip` field to be populated.\nFor **Elastic Defend** events on versions **8.18 and above**, this field is **disabled by default**.\n\nIf you are using **Elastic Defend**, ensure host IP collection is enabled by following the configuration steps in the\n[helper guide](https://www.elastic.co/docs/solutions/security/configure-elastic-defend/configure-data-volume-for-elastic-endpoint#host-fields).\n\nThe rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration.\n\n### Lateral Movement Detection Setup\nThe Lateral Movement Detection integration detects lateral movement activity by identifying abnormalities in file and Windows RDP events. Anomalies are detected using Elastic's Anomaly Detection feature.\n\n#### Prerequisite Requirements:\n- Fleet is required for Lateral Movement Detection.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n- File events collected by the [Elastic Defend](https://docs.elastic.co/en/integrations/endpoint) integration.\n- To install Elastic Defend, refer to the [documentation](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n\n#### The following steps should be executed to install assets associated with the Lateral Movement Detection integration:\n- Go to the Kibana homepage. Under Management, click Integrations.\n- In the query bar, search for Lateral Movement Detection and select the integration to see more details about it.\n- Follow the instructions under the **Installation** section.\n- For this rule to work, complete the instructions through **Add preconfigured anomaly detection jobs**.\n", + "severity": "low", + "tags": [ + "Use Case: Lateral Movement Detection", + "Rule Type: ML", + "Rule Type: Machine Learning", + "Tactic: Lateral Movement", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0008", + "name": "Lateral Movement", + "reference": "https://attack.mitre.org/tactics/TA0008/" + }, + "technique": [ + { + "id": "T1210", + "name": "Exploitation of Remote Services", + "reference": "https://attack.mitre.org/techniques/T1210/" + } + ] + } + ], + "type": "machine_learning", + "version": 8 + }, + "id": "0678bc9c-b71a-433b-87e6-2f664b6b3131_8", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/083383af-b9a4-42b7-a463-29c40efe7797_4.json b/packages/security_detection_engine/kibana/security_rule/083383af-b9a4-42b7-a463-29c40efe7797_4.json deleted file mode 100644 index 93030a72017..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/083383af-b9a4-42b7-a463-29c40efe7797_4.json +++ /dev/null @@ -1,143 +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", - "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Potential PowerShell Obfuscation via Concatenated Dynamic Command Invocation\n\nPowerShell is a powerful scripting language used for task automation and configuration management in Windows environments. Adversaries exploit its capabilities by obfuscating commands to evade detection, often using concatenated strings in dynamic invocations. This detection rule identifies such obfuscation by analyzing script patterns, specifically looking for concatenated strings within dynamic command invocations, which are indicative of attempts to bypass security measures like AMSI. By counting these patterns, the rule effectively flags suspicious scripts, aiding in the identification of potential threats.\n\n### Possible investigation steps\n\n- Review the `powershell.file.script_block_text` field to understand the content and purpose of the script, focusing on the concatenated strings and dynamic command invocations.\n- Check the `host.name` and `user.id` fields to identify the machine and user account associated with the execution of the suspicious script, which can help determine if the activity is expected or anomalous.\n- Analyze the `file.path` field to locate the script's source or storage location, which may provide additional context or indicate if the script is part of a known application or process.\n- Investigate the `powershell.file.script_block_id` and `powershell.sequence` fields to trace the execution sequence and correlate it with other related PowerShell activities, which might reveal a broader pattern of behavior.\n- Assess the `agent.id` field to determine the specific endpoint agent involved, which can assist in further endpoint-specific investigations or actions.\n\n### False positive analysis\n\n- Scripts with legitimate concatenated strings for dynamic command execution may trigger the rule. Review the script context to determine if the concatenation serves a valid administrative purpose.\n- Automated scripts from trusted sources that use concatenation for modularity or readability might be flagged. Consider adding these scripts to an allowlist if they are verified as safe.\n- Development or testing environments where PowerShell scripts are frequently modified and tested could generate false positives. Implement exceptions for known development hosts or user accounts.\n- Security tools or monitoring solutions that use PowerShell for legitimate operations may inadvertently match the pattern. Identify these tools and exclude their operations from the rule.\n- Regularly review and update the exclusion list to ensure it reflects the current environment and does not inadvertently allow malicious activity.\n\n### Response and remediation\n\n- Isolate the affected host immediately to prevent further execution of potentially malicious scripts and limit lateral movement within the network.\n- Terminate any suspicious PowerShell processes identified by the alert to halt the execution of obfuscated commands.\n- Conduct a thorough review of the script block text and associated script block ID to understand the intent and potential impact of the obfuscated commands.\n- Remove any unauthorized or malicious scripts from the affected system and ensure that all legitimate scripts are verified and signed.\n- Restore the affected system from a known good backup if any malicious activity is confirmed, ensuring that all data integrity checks are performed.\n- Escalate the incident to the security operations team for further analysis and to determine if additional systems have been compromised.\n- Update endpoint protection and monitoring tools to enhance detection capabilities for similar obfuscation techniques, leveraging insights from the MITRE ATT&CK framework.\n", - "query": "from logs-windows.powershell_operational* metadata _id, _version, _index\n| where event.code == \"4104\" and powershell.file.script_block_text like \"*+*\"\n\n// replace the patterns we are looking for with the \ud83d\udd25 emoji to enable counting them\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| eval Esql.script_block_tmp = replace(\n powershell.file.script_block_text,\n \"\"\"[.&]\\(\\s*(['\"][A-Za-z0-9.-]+['\"]\\s*\\+\\s*)+['\"][A-Za-z0-9.-]+['\"]\\s*\\)\"\"\",\n \"\ud83d\udd25\"\n)\n\n// count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| eval Esql.script_block_pattern_count = length(Esql.script_block_tmp) - length(replace(Esql.script_block_tmp, \"\ud83d\udd25\", \"\"))\n\n// keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| keep\n Esql.script_block_pattern_count,\n Esql.script_block_tmp,\n powershell.file.script_block_text,\n powershell.file.script_block_id,\n file.path,\n powershell.sequence,\n powershell.total,\n _id,\n _index,\n host.name,\n agent.id,\n user.id\n\n// Filter for scripts that match the pattern at least once\n| where Esql.script_block_pattern_count >= 1\n", - "related_integrations": [ - { - "package": "windows", - "version": "^3.0.0" - } - ], - "required_fields": [ - { - "ecs": false, - "name": "Esql.script_block_pattern_count", - "type": "integer" - }, - { - "ecs": false, - "name": "Esql.script_block_tmp", - "type": "keyword" - }, - { - "ecs": false, - "name": "_id", - "type": "keyword" - }, - { - "ecs": false, - "name": "_index", - "type": "keyword" - }, - { - "ecs": true, - "name": "agent.id", - "type": "keyword" - }, - { - "ecs": true, - "name": "file.path", - "type": "keyword" - }, - { - "ecs": true, - "name": "host.name", - "type": "keyword" - }, - { - "ecs": false, - "name": "powershell.file.script_block_id", - "type": "keyword" - }, - { - "ecs": false, - "name": "powershell.file.script_block_text", - "type": "text" - }, - { - "ecs": false, - "name": "powershell.sequence", - "type": "long" - }, - { - "ecs": false, - "name": "powershell.total", - "type": "long" - }, - { - "ecs": true, - "name": "user.id", - "type": "keyword" - } - ], - "risk_score": 21, - "rule_id": "083383af-b9a4-42b7-a463-29c40efe7797", - "setup": "## Setup\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nAdministrative Templates >\nWindows PowerShell >\nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n", - "severity": "low", - "tags": [ - "Domain: Endpoint", - "OS: Windows", - "Use Case: Threat Detection", - "Tactic: Defense Evasion", - "Data Source: PowerShell Logs", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0005", - "name": "Defense Evasion", - "reference": "https://attack.mitre.org/tactics/TA0005/" - }, - "technique": [ - { - "id": "T1027", - "name": "Obfuscated Files or Information", - "reference": "https://attack.mitre.org/techniques/T1027/" - }, - { - "id": "T1140", - "name": "Deobfuscate/Decode Files or Information", - "reference": "https://attack.mitre.org/techniques/T1140/" - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0002", - "name": "Execution", - "reference": "https://attack.mitre.org/tactics/TA0002/" - }, - "technique": [ - { - "id": "T1059", - "name": "Command and Scripting Interpreter", - "reference": "https://attack.mitre.org/techniques/T1059/", - "subtechnique": [ - { - "id": "T1059.001", - "name": "PowerShell", - "reference": "https://attack.mitre.org/techniques/T1059/001/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 4 - }, - "id": "083383af-b9a4-42b7-a463-29c40efe7797_4", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/083383af-b9a4-42b7-a463-29c40efe7797_8.json b/packages/security_detection_engine/kibana/security_rule/083383af-b9a4-42b7-a463-29c40efe7797_8.json new file mode 100644 index 00000000000..1c58f152d5c --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/083383af-b9a4-42b7-a463-29c40efe7797_8.json @@ -0,0 +1,202 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects PowerShell scripts that builds commands from concatenated string literals inside dynamic invocation constructs like &() or .(). Attackers use concatenated dynamic invocation to obscure execution intent, bypass keyword-based detections, and evade AMSI.", + "from": "now-9m", + "investigation_fields": { + "field_names": [ + "@timestamp", + "user.name", + "user.id", + "user.domain", + "powershell.file.script_block_text", + "powershell.file.script_block_id", + "powershell.sequence", + "powershell.total", + "file.path", + "file.directory", + "file.name", + "process.pid", + "host.name", + "host.id", + "powershell.file.script_block_length" + ] + }, + "language": "esql", + "license": "Elastic License v2", + "name": "Potential PowerShell Obfuscation via Concatenated Dynamic Command Invocation", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This guide was created by humans with the assistance of generative AI. While its contents have been manually curated to include the most valuable information, always validate assumptions and adjust procedures to match your internal runbooks and incident triage and response policies.\n\n### Investigating Potential PowerShell Obfuscation via Concatenated Dynamic Command Invocation\n\nThis rule identifies PowerShell script block content where a command is built from concatenated string literals and executed through dynamic invocation using the call operator (&) or dot invocation (.). This technique can hide the true command name (for example, splitting cmdlet, function, alias, or script names into fragments) and is often paired with additional obfuscation to hinder quick review.\n\n#### Key alert fields to review\n\n- `user.name`, `user.domain`, `user.id`: Account execution context for correlation, prioritization, and scoping.\n- `host.name`, `host.id`: Host execution context for correlation, prioritization, and scoping.\n- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file.\n- `powershell.file.script_block_text`: Script block content that matched the detection logic.\n- `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`: Script block metadata to pivot to other fragments or reconstruct full script content when split across multiple events.\n- `Esql.script_block_tmp`: Transformed script block where detection patterns replace original content with a marker to support scoring/counting and quickly spot match locations.\n- `Esql.script_block_pattern_count`: Count of matches for the detection pattern(s) observed in the script block content.\n- `powershell.file.script_block_entropy_bits`: Shannon entropy of the script block. Higher values may indicate obfuscation.\n- `powershell.file.script_block_surprisal_stdev`: Standard deviation of surprisal across the script block. Low values indicate uniform randomness. High values indicate mixed patterns and variability.\n- `powershell.file.script_block_unique_symbols`: Count of distinct characters present in the script block.\n- `powershell.file.script_block_length`: Script block length (size) context.\n\n#### Possible investigation steps\n\n- Establish scope and execution context:\n - Review `host.name` and `host.id` to understand where the script ran, and identify whether the host is an admin workstation, server, or user endpoint.\n - Review `user.name`, `user.domain`, and `user.id` to understand who initiated the activity and whether PowerShell use is expected for that identity.\n - Use the alert timestamp to bound the activity window for correlation and scoping.\n\n- Reconstruct the dynamically invoked command(s):\n - Review `powershell.file.script_block_text` and use `Esql.script_block_tmp` to quickly locate the dynamic invocation expression(s) inside the script block.\n - Identify each invocation using `&(...)` or `.(...)` where multiple quoted strings are joined with `+`.\n - Concatenate the quoted string fragments in their observed order to derive the effective command/function/script name being invoked.\n - Use `Esql.script_block_pattern_count` to prioritize review; multiple dynamic concatenation invocations in the same script block generally indicate stronger intent to obscure execution.\n\n- Determine whether the operator changes execution semantics:\n - For `&(...)` (call operator), focus on the command being executed and any arguments passed immediately before/after the invocation.\n - For `.(...)` (dot invocation), assess whether the script is intended to run in the current scope (for example, to define or modify functions/variables) and whether that scope change is expected for the host and user context.\n\n- Reassemble full script content when fragmented:\n - Pivot on `powershell.file.script_block_id` to locate other fragments of the same script block.\n - If `powershell.total` indicates the content is split across multiple events, use `powershell.sequence` and `powershell.total` to reconstruct the full script block in order before making a determination.\n\n- Identify script origin and persistence opportunities:\n - If `file.path`, `file.directory`, or `file.name` are present, determine whether the script block is associated with an on-disk script and whether its location aligns with approved administrative tooling or known automation paths.\n - Treat unusual user-writable or temporary locations as higher risk, especially when paired with high `Esql.script_block_pattern_count`.\n\n- Evaluate obfuscation characteristics and intent:\n - Use `powershell.file.script_block_entropy_bits`, `powershell.file.script_block_surprisal_stdev`, `powershell.file.script_block_unique_symbols`, and `powershell.file.script_block_length` to assess how atypical the content is compared to known-good scripts in your environment.\n - Review surrounding logic in `powershell.file.script_block_text` for additional obfuscation patterns (for example, layered string operations, indirect invocation, or hidden payload material) that may not be captured by this specific match.\n\n- Correlate with adjacent endpoint activity (if available):\n - Pivot using `host.id` and the alert time window to identify the PowerShell host process, its parent process, and any child processes that indicate follow-on execution.\n - Review network, file, and registry activity on `host.id` around the same time for signs of payload retrieval, on-disk staging, persistence, or system configuration changes.\n - Review authentication activity associated with `user.id` around the same time window for anomalous logons, new session sources, or unusual access patterns.\n - Pivot on `user.id` to identify similar activity across other hosts, which may indicate shared automation, credential reuse, or lateral movement.\n\n- Capture and operationalize investigation artifacts:\n - Document the reconstructed command strings, notable script fragments, and any referenced file locations (`file.path`) for escalation and threat hunting.\n - Use those artifacts to search for additional occurrences across the environment, focusing on the same `user.id`, `host.id`, and similar `powershell.file.script_block_text` patterns.\n\n### False positive analysis\n\n- Administrative scripts, modules, or internal frameworks that dynamically assemble short command names (cmdlets, functions, aliases) via string concatenation before invoking them for indirection or compatibility.\n- Legitimate automation that uses dot invocation to load or execute helper logic in the current scope, including scripts that intentionally reduce readability for code protection.\n\n### Response and remediation\n\n- If the activity is confirmed or strongly suspected to be malicious or unauthorized:\n - Contain the affected host identified by `host.id` to prevent further execution and potential lateral movement.\n - Preserve evidence, including the full reconstructed `powershell.file.script_block_text` (using `powershell.sequence`/`powershell.total` if needed) and any associated on-disk script referenced by `file.path`.\n\n- If an on-disk script is involved (`file.path` present):\n - Acquire the referenced script file for analysis and validate its provenance.\n - Remove or quarantine the script if it is unauthorized, and assess for additional copies using the same `file.name` or `file.path` patterns across hosts.\n\n- If account misuse is suspected:\n - Scope recent activity for the implicated `user.id` across hosts, prioritize investigation for privileged accounts, and reset credentials per policy.\n - Review and reduce unnecessary privileges associated with the account, especially if PowerShell access is not required.\n\n- Eradication and recovery:\n - Identify and remediate follow-on artifacts discovered during scoping (for example, dropped scripts/binaries or persistence mechanisms) using established response procedures.\n - Increase monitoring for recurrence by hunting for similar dynamic concatenation patterns (high `Esql.script_block_pattern_count`) on the same `host.id` and `user.id`.\n\n- Post-incident hardening:\n - Ensure PowerShell Script Block Logging coverage is consistently enabled and centrally collected for systems where PowerShell use is permitted.\n - Limit PowerShell use to approved users and hosts, and review controls that reduce the impact of dynamic invocation and obfuscation in your environment.\n", + "query": "from logs-windows.powershell_operational* metadata _id, _version, _index\n| where event.code == \"4104\" and powershell.file.script_block_text like \"*+*\"\n\n// replace the patterns we are looking for with the \ud83d\udd25 emoji to enable counting them\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| eval Esql.script_block_tmp = replace(\n powershell.file.script_block_text,\n \"\"\"[.&]\\(\\s*(['\"][A-Za-z0-9.-]+['\"]\\s*\\+\\s*)+['\"][A-Za-z0-9.-]+['\"]\\s*\\)\"\"\",\n \"\ud83d\udd25\"\n)\n\n// count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| eval Esql.script_block_pattern_count = length(Esql.script_block_tmp) - length(replace(Esql.script_block_tmp, \"\ud83d\udd25\", \"\"))\n\n// keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| keep\n Esql.script_block_pattern_count,\n Esql.script_block_tmp,\n powershell.file.*,\n file.path,\n powershell.sequence,\n powershell.total,\n _id,\n _version,\n _index,\n host.name,\n host.id,\n agent.id,\n user.id\n\n// Filter for scripts that match the pattern at least once\n| where Esql.script_block_pattern_count >= 1\n", + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.script_block_pattern_count", + "type": "integer" + }, + { + "ecs": false, + "name": "Esql.script_block_tmp", + "type": "keyword" + }, + { + "ecs": false, + "name": "_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "_index", + "type": "keyword" + }, + { + "ecs": false, + "name": "_version", + "type": "long" + }, + { + "ecs": true, + "name": "agent.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.path", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.name", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_entropy_bits", + "type": "double" + }, + { + "ecs": false, + "name": "powershell.file.script_block_entropy_normalized", + "type": "double" + }, + { + "ecs": false, + "name": "powershell.file.script_block_hash", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_length", + "type": "long" + }, + { + "ecs": false, + "name": "powershell.file.script_block_surprisal_stdev", + "type": "double" + }, + { + "ecs": false, + "name": "powershell.file.script_block_text", + "type": "text" + }, + { + "ecs": false, + "name": "powershell.file.script_block_unique_symbols", + "type": "long" + }, + { + "ecs": false, + "name": "powershell.sequence", + "type": "long" + }, + { + "ecs": false, + "name": "powershell.total", + "type": "long" + }, + { + "ecs": true, + "name": "user.id", + "type": "keyword" + } + ], + "risk_score": 73, + "rule_id": "083383af-b9a4-42b7-a463-29c40efe7797", + "setup": "## Setup\n\nPowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104).\nSetup instructions: https://ela.st/powershell-logging-setup\n", + "severity": "high", + "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": 8 + }, + "id": "083383af-b9a4-42b7-a463-29c40efe7797_8", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/08933236-b27a-49f6-b04a-a616983f04b9_2.json b/packages/security_detection_engine/kibana/security_rule/08933236-b27a-49f6-b04a-a616983f04b9_2.json new file mode 100644 index 00000000000..98d1b754e07 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/08933236-b27a-49f6-b04a-a616983f04b9_2.json @@ -0,0 +1,105 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule uses alert data to determine when multiple alerts from different integrations with unique event categories and involving the same destination.ip are triggered. Analysts can use this to prioritize triage and response, as these IP address is more likely to be related to a compromise.", + "from": "now-60m", + "interval": "30m", + "language": "esql", + "license": "Elastic License v2", + "name": "Alerts From Multiple Integrations by Destination Address", + "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 From Multiple Integrations by Destination Address\n\nThe detection rule uses alert data to determine when multiple alerts from different integrations involving the same destination.ip are triggered.\n\n### Possible investigation steps\n\n- Review the alert details to identify the specific host involved and the different modules and rules that triggered the alert.\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.*\n\n// any alerts excluding low severity, threat_match and machine_learning rules \n| where kibana.alert.rule.name is not null and destination.ip is not null and kibana.alert.risk_score > 21 and not kibana.alert.rule.type in (\"threat_match\", \"machine_learning\") and\n not KQL(\"\"\"kibana.alert.rule.tags : \"Rule Type: Higher-Order Rule\" \"\"\")\n\n// group alerts by destination.ip and extract values of interest for alert triage\n| stats Esql.event_module_distinct_count = COUNT_DISTINCT(event.module),\n Esql.rule_name_distinct_count = COUNT_DISTINCT(kibana.alert.rule.name),\n Esql.event_category_distinct_count = COUNT_DISTINCT(event.category),\n Esql.rule_risk_score_distinct_count = COUNT_DISTINCT(kibana.alert.risk_score),\n Esql.event_module_values = VALUES(event.module),\n Esql.rule_name_values = VALUES(kibana.alert.rule.name),\n Esql.message_values = VALUES(message),\n Esql.event_category_values = VALUES(event.category),\n Esql.event_action_values = VALUES(event.action),\n Esql.source_ip_values = VALUES(source.ip),\n Esql.host_id_values = VALUES(host.id),\n Esql.agent_id_values = VALUES(agent.id),\n Esql.user_name_values = VALUES(user.name),\n Esql.rule_severity_values = VALUES(kibana.alert.risk_score) by destination.ip\n\n// filter for alerts from same destination.ip reported by different integrations with unique categories and with different severity levels or presence of high severity alerts\n| where Esql.event_module_distinct_count >= 2 and Esql.event_category_distinct_count >= 2 and (Esql.rule_risk_score_distinct_count >= 2 or Esql.rule_severity_values == 73 or Esql.rule_severity_values == 99)\n| keep destination.ip, Esql.*\n", + "required_fields": [ + { + "ecs": false, + "name": "Esql.agent_id_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.event_action_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.event_category_distinct_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.event_category_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.event_module_distinct_count", + "type": "long" + }, + { + "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_distinct_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.rule_name_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.rule_risk_score_distinct_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.rule_severity_values", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.source_ip_values", + "type": "ip" + }, + { + "ecs": false, + "name": "Esql.user_name_values", + "type": "keyword" + }, + { + "ecs": true, + "name": "destination.ip", + "type": "ip" + } + ], + "risk_score": 73, + "rule_id": "08933236-b27a-49f6-b04a-a616983f04b9", + "severity": "high", + "tags": [ + "Use Case: Threat Detection", + "Rule Type: Higher-Order Rule", + "Resources: Investigation Guide" + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 2 + }, + "id": "08933236-b27a-49f6-b04a-a616983f04b9_2", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/0abf0c5b-62dd-48d2-ac4e-6b43fe3a6e83_212.json b/packages/security_detection_engine/kibana/security_rule/0abf0c5b-62dd-48d2-ac4e-6b43fe3a6e83_212.json new file mode 100644 index 00000000000..b9d7e30164a --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/0abf0c5b-62dd-48d2-ac4e-6b43fe3a6e83_212.json @@ -0,0 +1,162 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "building_block_type": "default", + "description": "Identifies the use of Cmdlets and methods related to remote execution activities using WinRM. Attackers can abuse WinRM to perform lateral movement using built-in tools.", + "filters": [ + { + "meta": { + "negate": true + }, + "query": { + "wildcard": { + "file.path": { + "case_insensitive": true, + "value": "?:\\\\Program Files\\\\WindowsPowerShell\\\\Modules\\\\dbatools\\\\*\\\\allcommands.ps1" + } + } + } + }, + { + "meta": { + "negate": true + }, + "query": { + "wildcard": { + "file.directory": { + "case_insensitive": true, + "value": "?:\\\\Program Files\\\\Microsoft\\\\Exchange Server\\\\*\\\\bin" + } + } + } + }, + { + "meta": { + "negate": true + }, + "query": { + "wildcard": { + "file.directory": { + "case_insensitive": true, + "value": "?:\\\\ExchangeServer\\\\bin*" + } + } + } + } + ], + "from": "now-119m", + "index": [ + "winlogbeat-*", + "logs-windows.powershell*" + ], + "interval": "60m", + "language": "kuery", + "license": "Elastic License v2", + "name": "Deprecated - PowerShell Script with Remote Execution Capabilities via WinRM", + "query": "event.category:process and host.os.type:windows and\n powershell.file.script_block_text : (\n (\"Invoke-WmiMethod\" or \"Invoke-Command\" or \"Enter-PSSession\") and \"ComputerName\"\n ) and\n not user.id : \"S-1-5-18\" and\n not file.directory : (\n \"C:\\\\Program Files\\\\LogicMonitor\\\\Agent\\\\tmp\" or\n \"C:\\\\Program Files\\\\WindowsPowerShell\\\\Modules\\\\icinga-powershell-framework\\\\cache\" or\n \"C:\\\\Program Files\\\\WindowsPowerShell\\\\Modules\\\\SmartCardTools\\\\1.2.2\"\n ) and not\n powershell.file.script_block_text : (\n \"Export-ModuleMember -Function @('Invoke-Expression''Invoke-Command')\" and\n \"function Invoke-Command {\"\n )\n", + "references": [ + "https://attack.mitre.org/techniques/T1021/006/", + "https://github.com/cobbr/SharpSploit/blob/master/SharpSploit/LateralMovement/PowerShellRemoting.cs", + "https://github.com/BC-SECURITY/Empire/blob/main/empire/server/modules/powershell/lateral_movement/invoke_psremoting.py" + ], + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.category", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.directory", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_text", + "type": "unknown" + }, + { + "ecs": true, + "name": "user.id", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "0abf0c5b-62dd-48d2-ac4e-6b43fe3a6e83", + "setup": "## Setup\n\nPowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104).\nSetup instructions: https://ela.st/powershell-logging-setup\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Lateral Movement", + "Tactic: Execution", + "Data Source: PowerShell Logs", + "Rule Type: BBR" + ], + "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.006", + "name": "Windows Remote Management", + "reference": "https://attack.mitre.org/techniques/T1021/006/" + } + ] + } + ] + }, + { + "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": "query", + "version": 212 + }, + "id": "0abf0c5b-62dd-48d2-ac4e-6b43fe3a6e83_212", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/0bca7e73-e1b5-4fb2-801b-9b5f5be20dfe_5.json b/packages/security_detection_engine/kibana/security_rule/0bca7e73-e1b5-4fb2-801b-9b5f5be20dfe_5.json new file mode 100644 index 00000000000..3d2e8b4df7c --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/0bca7e73-e1b5-4fb2-801b-9b5f5be20dfe_5.json @@ -0,0 +1,142 @@ +{ + "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\", \"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.message_values_distinct_count = COUNT_DISTINCT(message),\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.process_hash_sha256_values = VALUES(process.hash.sha256),\n Esql.process_cmdline_values = VALUES(process.command_line),\n Esql.file_path_values = VALUES(file.path),\n Esql.file_hash_sha256_values = VALUES(file.hash.sha256),\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 AND Esql.message_values_distinct_count >= 2\n| eval concat_module_values = MV_CONCAT(Esql.event_module_values, \",\")\n// Make sure an endpoint alert is present along one of the network ones\n| where concat_module_values like \"*endpoint*\"\n\n// Move single values to their corresponding ECS fields for alerts exclusion\n| eval source.ip = mv_min(Esql.source_ip),\n host.id = mv_min(Esql.host_id_values),\n user.name = mv_min(Esql.user_name_values)\n\n| keep source.ip, host.id, user.name, Esql.*\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_action_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.event_module_distinct_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.event_module_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.host_id_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.message_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.message_values_distinct_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.process_cmdline_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.source_ip", + "type": "ip" + }, + { + "ecs": false, + "name": "Esql.user_name_values", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.ip", + "type": "ip" + }, + { + "ecs": true, + "name": "user.name", + "type": "keyword" + } + ], + "risk_score": 73, + "rule_id": "0bca7e73-e1b5-4fb2-801b-9b5f5be20dfe", + "setup": "## Setup\n\nThis rule requires the `host.ip` field to be populated.\nFor **Elastic Defend** events on versions **8.18 and above**, this field is **disabled by default**.\n\nIf you are using **Elastic Defend**, ensure host IP collection is enabled by following the configuration steps in the\n[helper guide](https://www.elastic.co/docs/solutions/security/configure-elastic-defend/configure-data-volume-for-elastic-endpoint#host-fields).\n", + "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": 5 + }, + "id": "0bca7e73-e1b5-4fb2-801b-9b5f5be20dfe_5", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/0d160033-fab7-4e72-85a3-3a9d80c8bff7_6.json b/packages/security_detection_engine/kibana/security_rule/0d160033-fab7-4e72-85a3-3a9d80c8bff7_6.json new file mode 100644 index 00000000000..a28b0a567bb --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/0d160033-fab7-4e72-85a3-3a9d80c8bff7_6.json @@ -0,0 +1,100 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule uses alert data to determine when multiple different alerts involving the same user are triggered. Analysts can use this to prioritize triage and response, as these users are more likely to be compromised.", + "from": "now-4h", + "interval": "1h", + "language": "esql", + "license": "Elastic License v2", + "name": "Multiple Alerts Involving a User", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Multiple Alerts Involving a User\n\nIn security environments, monitoring user activity is crucial as adversaries often exploit user accounts to gain unauthorized access. Attackers may trigger multiple alerts by performing suspicious actions under a compromised user account. The detection rule identifies such patterns by correlating diverse alerts linked to the same user, excluding known system accounts, thus prioritizing potential threats for analysts.\n\n### Possible investigation steps\n\n- Review the alert details to identify the specific user account involved, focusing on the user.name field to gather initial context about the user.\n- Examine the timeline and sequence of the triggered alerts to understand the pattern of activity associated with the user, noting any unusual or unexpected actions.\n- Cross-reference the user activity with known legitimate activities or scheduled tasks to rule out false positives, ensuring that the actions are not part of normal operations.\n- Investigate the source and destination IP addresses associated with the alerts to identify any suspicious or unauthorized access points.\n- Check for any recent changes in user permissions or group memberships that could indicate privilege escalation attempts.\n- Look into any recent login attempts or authentication failures for the user account to detect potential brute force or credential stuffing attacks.\n- Collaborate with the user or their manager to verify if the activities were authorized or if the account might be compromised.\n\n### False positive analysis\n\n- Alerts triggered by automated system processes or scripts that mimic user behavior can be false positives. To manage these, identify and exclude known benign scripts or processes from the rule.\n- Frequent alerts from users in roles that inherently require access to multiple systems or sensitive data, such as IT administrators, may not indicate compromise. Implement role-based exceptions to reduce noise.\n- Alerts generated by legitimate software updates or maintenance activities can be mistaken for suspicious behavior. Schedule these activities during known maintenance windows and exclude them from the rule during these times.\n- Users involved in testing or development environments may trigger multiple alerts due to their work nature. Create exceptions for these environments to prevent unnecessary alerts.\n- High-volume users, such as those in customer support or sales, may naturally generate more alerts. Monitor these users separately and adjust the rule to focus on unusual patterns rather than volume alone.\n\n### Response and remediation\n\n- Isolate the affected user account immediately to prevent further unauthorized access. Disable the account or change the password to stop any ongoing malicious activity.\n- Conduct a thorough review of the affected user's recent activities and access logs to identify any unauthorized actions or data access. This will help in understanding the scope of the compromise.\n- Remove any malicious software or unauthorized tools that may have been installed on the user's system. Use endpoint detection and response (EDR) tools to scan and clean the system.\n- Restore any altered or deleted data from backups, ensuring that the restored data is free from any malicious modifications.\n- Notify relevant stakeholders, including IT security teams and management, about the incident and the steps being taken to address it. This ensures that everyone is aware and can provide support if needed.\n- Implement additional monitoring on the affected user account and related systems to detect any further suspicious activities. This includes setting up alerts for unusual login attempts or data access patterns.\n- Review and update access controls and permissions for the affected user and similar accounts to prevent future incidents. Ensure that least privilege principles are applied.", + "query": "from .alerts-security.*\n| where kibana.alert.rule.name is not null and user.id is not null and\n // Exclude low severity alerts\n kibana.alert.risk_score > 21 and\n not KQL(\"\"\"kibana.alert.rule.tags : \"Rule Type: Higher-Order Rule\" \"\"\")\n| stats\n Esql.rule_name_distinct_count = COUNT_DISTINCT(kibana.alert.rule.name), \n Esql.rule_id_distinct_count = COUNT_DISTINCT(kibana.alert.rule.rule_id),\n Esql.host_id_distinct_count = COUNT_DISTINCT(host.id),\n Esql.risk_score_distinct_count = COUNT_DISTINCT(kibana.alert.risk_score),\n Esql.event_dataset_distinct_count = COUNT_DISTINCT(event.dataset),\n Esql.rule_name_values = VALUES(kibana.alert.rule.name), \n Esql.risk_score_values = VALUES(kibana.alert.risk_score), \n Esql.event_dataset_values = VALUES(event.dataset), \n Esql.event_module_values = VALUES(event.module), \n Esql.process_command_line = VALUES(process.command_line), \n Esql.host_id_values = VALUES(host.id), \n Esql.source_ip_values = VALUES(source.ip), \n Esql.destination_ip_values = VALUES(destination.ip) by user.id\n\n| where Esql.rule_name_distinct_count >= 4 AND Esql.rule_id_distinct_count >= 2 and\n // Exclude known system accounts with matches in more than one host\n not (\n (length(TO_STRING(user.id)) <= 4 or user.id IN (\"S-1-5-18\", \"S-1-5-19\", \"S-1-5-20\", \"0\")) and\n (Esql.host_id_distinct_count >= 2 or Esql.host_id_distinct_count == 0)\n )\n\n| keep user.id, Esql.*\n", + "required_fields": [ + { + "ecs": false, + "name": "Esql.destination_ip_values", + "type": "ip" + }, + { + "ecs": false, + "name": "Esql.event_dataset_distinct_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.event_dataset_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.event_module_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.host_id_distinct_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.host_id_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.process_command_line", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.risk_score_distinct_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.risk_score_values", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.rule_id_distinct_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.rule_name_distinct_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.rule_name_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.source_ip_values", + "type": "ip" + }, + { + "ecs": true, + "name": "user.id", + "type": "keyword" + } + ], + "risk_score": 73, + "rule_id": "0d160033-fab7-4e72-85a3-3a9d80c8bff7", + "severity": "high", + "tags": [ + "Use Case: Threat Detection", + "Rule Type: Higher-Order Rule", + "Resources: Investigation Guide" + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 6 + }, + "id": "0d160033-fab7-4e72-85a3-3a9d80c8bff7_6", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/0e67f4f1-f683-43c0-8d45-c3293cf31e5d_2.json b/packages/security_detection_engine/kibana/security_rule/0e67f4f1-f683-43c0-8d45-c3293cf31e5d_2.json new file mode 100644 index 00000000000..13bc793ef28 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/0e67f4f1-f683-43c0-8d45-c3293cf31e5d_2.json @@ -0,0 +1,111 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects source IPs that triggered their first lateral movement alert within the last 10 minutes (i.e., newly observed), while also triggering at least 2 distinct lateral movement detection rules. This surfaces new potentially malicious IPs exhibiting immediate lateral movement behavior.", + "from": "now-7200m", + "interval": "10m", + "language": "esql", + "license": "Elastic License v2", + "name": "Lateral Movement Alerts from a Newly Observed Source Address", + "note": "## Triage and analysis\n\n### Investigating Lateral Movement Alerts from a Newly Observed Source Address\n\nThis rule surfaces newly observed, low-frequency source address triggering multiple lateral movement alerts.\n\nBecause the alert has not been seen previously for this rule and host, it should be prioritized for validation to determine\nwhether it represents a true compromise or rare benign activity.\n\n### Investigation Steps\n\n- Identify the source address, affected host, user and review the associated rule name to understand the behavior that triggered the alert.\n- Validate the source address and user context under which the activity occurred and assess whether it aligns with normal behavior for that address.\n- Refer to the specific rule investigation guide for further actions.\n\n### False Positive Considerations\n\n- Administrative scripts or automation tools can trigger behavior-based detections when first introduced.\n- Security tooling, IT management agents, or EDR integrations may generate new behavior alerts during updates or configuration changes.\n- Development or testing environments may produce one-off behaviors that resemble malicious techniques.\n\n### Response and Remediation\n\n- If the activity is confirmed malicious, isolate the affected host to prevent further execution or lateral movement.\n- Terminate malicious processes and remove any dropped files or persistence mechanisms.\n- Collect forensic artifacts to understand initial access and execution flow.\n- Patch or remediate any vulnerabilities or misconfigurations that enabled the behavior.\n- If benign, document the finding and consider tuning or exception handling to reduce future noise.\n- Continue monitoring the host and environment for recurrence of the behavior or related alerts.", + "query": "FROM .alerts-security.* METADATA _index\n\n// Lateral Movement related rules with fields of interest\n| where kibana.alert.rule.threat.tactic.name is not null and\n source.ip IS NOT NULL and destination.ip is not null and\n host.id is not null and KQL(\"\"\"kibana.alert.rule.threat.tactic.name : \"Lateral Movement\" and not kibana.alert.rule.tags : \"Rule Type: Higher-Order Rule\" \"\"\")\n\n// aggregate stats by source.ip\n| stats Esql.first_time_seen = MIN(@timestamp),\n Esql.alerts_count = count(*),\n Esql.unique_rules_count = COUNT_DISTINCT(kibana.alert.rule.name),\n Esql.unique_count_host_id = COUNT_DISTINCT(host.id),\n Esql.rule_name_values = VALUES(kibana.alert.rule.name),\n Esql.user_name_values = VALUES(user.name),\n Esql.host_id_values = VALUES(host.id),\n Esql.host_ip_values = VALUES(host.ip),\n Esql.tactic_name_values = VALUES(kibana.alert.rule.threat.tactic.name) by source.ip\n\n// values we will need for next filter\n| eval isLocal = locate(MV_CONCAT(to_string(Esql.host_ip_values), \",\"), to_string(source.ip)),\n Esql.date_diff = DATE_DIFF(\"minute\", Esql.first_time_seen, now())\n\n// at least 2 unique rules from same source.ip and that was first seen in last 5 days\n| where Esql.unique_rules_count >= 2 and\n // matches are within 10m of the rule execution time to avoid alert duplicates\n Esql.date_diff <= 10 and\n // make sure source.ip is not equal to host.ip\n not isLocal > 0 and\n // reduce noise from SCCM, Nessus and alike\n Esql.unique_count_host_id <= 3 and Esql.alerts_count <= 20\n| eval host.id = MV_FIRST(Esql.host_id_values), user.name = MV_FIRST(Esql.user_name_values)\n| KEEP Esql.*, source.ip, host.id, user.name\n", + "references": [ + "https://www.elastic.co/docs/solutions/security/detect-and-alert/about-detection-rules" + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.alerts_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.date_diff", + "type": "integer" + }, + { + "ecs": false, + "name": "Esql.first_time_seen", + "type": "date" + }, + { + "ecs": false, + "name": "Esql.host_id_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.host_ip_values", + "type": "ip" + }, + { + "ecs": false, + "name": "Esql.rule_name_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.tactic_name_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.unique_count_host_id", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.unique_rules_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.user_name_values", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.ip", + "type": "ip" + }, + { + "ecs": true, + "name": "user.name", + "type": "keyword" + } + ], + "risk_score": 73, + "rule_id": "0e67f4f1-f683-43c0-8d45-c3293cf31e5d", + "setup": "## Setup\n\nThis rule requires the `host.ip` field to be populated.\nFor **Elastic Defend** events on versions **8.18 and above**, this field is **disabled by default**.\n\nIf you are using **Elastic Defend**, ensure host IP collection is enabled by following the configuration steps in the\n[helper guide](https://www.elastic.co/docs/solutions/security/configure-elastic-defend/configure-data-volume-for-elastic-endpoint#host-fields).\n", + "severity": "high", + "tags": [ + "Use Case: Threat Detection", + "Rule Type: Higher-Order Rule", + "Tactic: Lateral Movement", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0008", + "name": "Lateral Movement", + "reference": "https://attack.mitre.org/tactics/TA0008/" + }, + "technique": [] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 2 + }, + "id": "0e67f4f1-f683-43c0-8d45-c3293cf31e5d_2", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/1004ad5b-6900-4d28-ab5b-472f02e1fdfb_1.json b/packages/security_detection_engine/kibana/security_rule/1004ad5b-6900-4d28-ab5b-472f02e1fdfb_1.json new file mode 100644 index 00000000000..ca1894d4047 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/1004ad5b-6900-4d28-ab5b-472f02e1fdfb_1.json @@ -0,0 +1,125 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects the rare occurrence of a user or role accessing AWS Systems Manager (SSM) inventory APIs or running the AWS-GatherSoftwareInventory job. These APIs reveal detailed information about managed EC2 instances including installed software, patch compliance status, and command execution history. Adversaries may use these calls to collect software inventory while blending in with legitimate AWS operations. This is a New Terms rule that detects when a user accesses these reconnaissance APIs for the first time.", + "false_positives": [ + "Legitimate administrators or automation tools may access SSM inventory APIs for asset management or compliance purposes. Verify whether the user identity should be using these APIs. If known behavior is causing false positives, add exceptions." + ], + "from": "now-6m", + "history_window_start": "now-10d", + "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 SSM Inventory Reconnaissance by Rare User", + "new_terms_fields": [ + "cloud.account.id", + "user.name" + ], + "note": "## Triage and analysis\n\n### Investigating AWS SSM Inventory Reconnaissance by Rare User\n\nAWS Systems Manager (SSM) Inventory provides detailed information about managed EC2 instances, including installed \napplications, network configurations, OS details, and patch compliance status. Threat actors, including Scattered \nSpider (LUCR-3), leverage these APIs to discover targets for lateral movement.\n\nThis rule detects the first time a specific user (identified by `cloud.account.id` and `user.name`) accesses SSM \ninventory reconnaissance APIs or runs inventory collection commands. These APIs are typically used by automation \nsystems, not interactively by humans.\n\n### Possible investigation steps\n\n- **Verify User Identity**: Check `aws.cloudtrail.user_identity.arn` or `user.name` to determine who performed the action.\n - Is this a service account, automation role, or human user?\n - Does this user typically interact with SSM or EC2 infrastructure?\n- **Review Source Context**: Examine `source.ip` and `source.geo` to determine where the request originated.\n - Does the source IP match expected locations for this user?\n - Is the source IP from an EC2 instance (potentially compromised) or an external location?\n- **Analyze User Agent**: Check `user_agent.original` for suspicious values.\n - AWS CLI, SDK, or CloudShell usage from unexpected users is suspicious.\n - Custom or unusual user agents may indicate attacker tooling.\n- **Correlate with Other Events**: Look for other reconnaissance or lateral movement activity from the same user.\n - Check for `StartSession`, `SendCommand`, or other SSM execution APIs.\n - Look for `GetCallerIdentity` calls which often precede reconnaissance.\n- **Review Timeline**: Investigate activity 30 minutes before and after this event.\n - Was there an initial access event (e.g., console login, `AssumeRole`)?\n - Did the user proceed to access secrets or attempt lateral movement?\n\n### False positive analysis\n\n- Automation and Monitoring: Legitimate monitoring tools, asset management systems, or compliance scanners may query SSM inventory regularly. These should use dedicated service accounts.\n- Administrator Activity: Cloud administrators may occasionally query inventory for troubleshooting. Verify with the user whether this was intentional.\n- CI/CD Pipelines: Deployment pipelines may check patch compliance before deployments.\n- SSM Associations: The `AWS-GatherSoftwareInventory` document is normally deployed via IaC tools (Terraform, CloudFormation) or the AWS Console during initial setup. Interactive `CreateAssociation` calls outside of these contexts warrant investigation.\n\n### Response and remediation\n\n- Immediate Verification: Contact the user to verify whether they performed this action intentionally.\n- Review Permissions: If unauthorized, review and restrict the user's IAM permissions following least privilege.\n- Investigate Credential Compromise: If the user did not perform this action, treat their credentials as compromised.\n - Rotate access keys and session tokens.\n - Review recent activity for data exfiltration or privilege escalation.\n- Enhanced Monitoring: Add the user or role to enhanced monitoring if suspicious activity is confirmed.\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- **[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: \"ssm.amazonaws.com\"\n and (\n event.action: (\"GetInventory\" or \"GetInventorySchema\" or \"ListInventoryEntries\" or \"DescribeInstancePatches\" or \"ListCommands\")\n or (event.action: \"CreateAssociation\"\n and aws.cloudtrail.request_parameters: *AWS-GatherSoftwareInventory*)\n )\n and not aws.cloudtrail.user_identity.type : \"AWSService\" \n and event.outcome: \"success\"\n", + "references": [ + "https://permiso.io/blog/lucr-3-scattered-spider-getting-saas-y-in-the-cloud", + "https://www.cisa.gov/sites/default/files/2023-11/aa23-320a_scattered_spider_0.pdf", + "https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-inventory.html" + ], + "related_integrations": [ + { + "integration": "cloudtrail", + "package": "aws", + "version": "^4.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "aws.cloudtrail.request_parameters", + "type": "keyword" + }, + { + "ecs": false, + "name": "aws.cloudtrail.user_identity.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.outcome", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.provider", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "1004ad5b-6900-4d28-ab5b-472f02e1fdfb", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Data Source: AWS SSM", + "Use Case: Threat Detection", + "Tactic: Discovery", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0007", + "name": "Discovery", + "reference": "https://attack.mitre.org/tactics/TA0007/" + }, + "technique": [ + { + "id": "T1538", + "name": "Cloud Service Dashboard", + "reference": "https://attack.mitre.org/techniques/T1538/" + }, + { + "id": "T1580", + "name": "Cloud Infrastructure Discovery", + "reference": "https://attack.mitre.org/techniques/T1580/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "new_terms", + "version": 1 + }, + "id": "1004ad5b-6900-4d28-ab5b-472f02e1fdfb_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/11dd9713-0ec6-4110-9707-32daae1ee68c_118.json b/packages/security_detection_engine/kibana/security_rule/11dd9713-0ec6-4110-9707-32daae1ee68c_118.json new file mode 100644 index 00000000000..9e7274d574a --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/11dd9713-0ec6-4110-9707-32daae1ee68c_118.json @@ -0,0 +1,149 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects PowerShell scripts that references token manipulation and impersonation APIs such as CreateProcessWithTokenW, DuplicateToken/ImpersonateLoggedOnUser, or AdjustTokenPrivileges (SeDebugPrivilege). Attackers abuse token impersonation to elevate privileges and bypass access controls.", + "from": "now-9m", + "index": [ + "winlogbeat-*", + "logs-windows.powershell*" + ], + "investigation_fields": { + "field_names": [ + "@timestamp", + "user.name", + "user.id", + "user.domain", + "powershell.file.script_block_text", + "powershell.file.script_block_id", + "powershell.sequence", + "powershell.total", + "file.path", + "file.directory", + "file.name", + "process.pid", + "host.name", + "host.id", + "powershell.file.script_block_length" + ] + }, + "language": "kuery", + "license": "Elastic License v2", + "name": "PowerShell Script with Token Impersonation Capabilities", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This guide was created by humans with the assistance of generative AI. While its contents have been manually curated to include the most valuable information, always validate assumptions and adjust procedures to match your internal runbooks and incident triage and response policies.\n\n### Investigating PowerShell Script with Token Impersonation Capabilities\n\nThis rule Detects PowerShell scripts that includes token manipulation and impersonation primitives. Such functionality can be used to execute follow-on actions under a different security context, including elevated or alternate user tokens. The primary investigation goals are to (1) reconstruct and understand the script intent, (2) validate whether the activity is authorized, and (3) identify any resulting privileged execution on the host.\n\n#### Key alert fields to review\n\n- `user.name`, `user.domain`, `user.id`: Account execution context for correlation, prioritization, and scoping.\n- `host.name`, `host.id`: Host execution context for correlation, prioritization, and scoping.\n- `powershell.file.script_block_text`: Script block content that matched the detection logic.\n- `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`: Script block metadata to pivot to other fragments or reconstruct full script content when split across multiple events.\n- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file.\n- `powershell.file.script_block_length`: Script block length (size) context.\n\n#### Possible investigation steps\n\n- Preserve and reconstruct the full script block content:\n - Capture `powershell.file.script_block_text` from the alert for analysis and evidence retention.\n - If the script is logged in multiple fragments, pivot on `powershell.file.script_block_id` and reassemble in order using `powershell.sequence`. Use `powershell.total` to confirm you have the complete set of fragments.\n - Use `powershell.file.script_block_length` to help gauge completeness and identify unusually large blocks that may contain reusable libraries or modules.\n\n- Identify which token technique is present and what outcome the script is attempting:\n - Review the reconstructed content for indicators of:\n - Token duplication and impersonation (for example: `DuplicateToken`, `DuplicateTokenEx`, `SetThreadToken`, `ImpersonateLoggedOnUser`, `NtImpersonateThread`).\n - Named pipe impersonation (`ImpersonateNamedPipeClient`).\n - Privilege enablement (`AdjustTokenPrivileges` with `SeDebugPrivilege`).\n - Token-based process creation (for example: `CreateProcessWithTokenW`, `CreateProcessAsUserW`, `CreateProcessAsUserA`) and related extended startup attributes (`STARTUPINFOEX`, `UpdateProcThreadAttribute`).\n - Higher-level wrappers commonly associated with token manipulation (for example: `Invoke-TokenManipulation`).\n - Determine whether the script only defines helper functions/types versus actively invoking them. Content that both defines and calls token APIs within the same execution window is higher risk.\n - Note any embedded targeting details in the script content (for example: intended user context, target process identifiers, or follow-on payload references), and preserve them for scoping and hunting.\n\n- Validate execution context and expectedness:\n - Use `host.name` and `host.id` to understand where the activity occurred and whether the system role typically requires privileged PowerShell usage.\n - Use `user.name`, `user.domain`, and `user.id` to identify the executing account and determine whether this user is expected to run scripts that manipulate access tokens on this host.\n - Prioritize alerts involving unexpected users, unusual hosts (for example, servers with limited admin access), or repeated/recurrent script blocks indicating persistence or automation.\n\n- Assess script provenance when file context is present:\n - If `file.path` is populated, determine whether the script came from a known module or an on-disk script file, and whether the location and naming are consistent with approved tooling.\n - If only `file.directory` and `file.name` are populated, use them to pivot to related script blocks and identify other executions from the same origin.\n - If the origin appears unfamiliar or user-writable, treat the artifact as suspicious and prioritize collecting the referenced file (and any adjacent module content) for deeper analysis.\n\n- Correlate with surrounding host activity to determine impact:\n - Pivot on `host.name` and the alert `@timestamp` into adjacent telemetry to identify the PowerShell host process and its initiating parent/source (interactive session, remote management, scheduled execution, or another process).\n - Look for follow-on activity shortly after the alert time that would indicate successful impersonation or privilege escalation, such as:\n - New process execution under a different user context than `user.name`.\n - Privileged actions that require elevated rights (for example, service/task changes, registry modifications, or access to protected resources).\n - If multiple script blocks occur close together for the same `user.id` and `host.id`, review them as a single activity chain to understand staging, execution, and any post-escalation behavior.\n\n- Scope and hunt for related activity:\n - Search for additional occurrences of distinctive substrings from `powershell.file.script_block_text` (function names, API names, unique strings) across other users and hosts to identify reuse.\n - Review whether the same `user.id` is associated with similar script blocks on other `host.id` values, which can indicate broad automation or a compromised account used across systems.\n - If `file.path` is present, check for the same path and file name across the environment, and identify unexpected hosts where the artifact appears.\n\n### False positive analysis\n\n- Legitimate administrative automation may use token impersonation to run tasks under alternate credentials, perform controlled privilege transitions, or integrate with management workflows.\n- Development and troubleshooting scripts may contain token API references as reusable helpers without being used for malicious outcomes.\n\nTo reduce false positives, focus on provenance and behavior: scripts from known, approved sources and executed by expected administrative identities on expected hosts are more likely benign, while ad-hoc or newly introduced scripts, unfamiliar file origins, and follow-on privileged execution increase concern.\n\n### Response and remediation\n\n- If the activity is unauthorized or suspicious:\n - Contain the host to prevent further privileged execution and limit lateral movement according to your incident response procedures.\n - Preserve evidence: the reconstructed script block content, associated `powershell.file.script_block_id` fragments, and any referenced on-disk artifacts from `file.path` (or `file.directory`/`file.name`).\n - Investigate and remediate outcomes of token impersonation, including processes started under unexpected security contexts and any privileged system changes occurring after the alert time.\n\n- Reduce attacker access and recurrence:\n - Review the executing account identified in `user.id`; reset credentials and invalidate active sessions as appropriate.\n - Review privileged access assignments for the involved accounts and hosts, and remove unauthorized privilege grants where identified.\n - If the script enabled sensitive privileges (for example, `SeDebugPrivilege`), assess for additional post-exploitation activity that could leverage enhanced access to protected processes and resources.\n\n- Eradicate and recover:\n - Remove unauthorized scripts/modules and any secondary artifacts or persistence mechanisms discovered during investigation.\n - Monitor for repeat executions by hunting for the same token manipulation indicators observed in `powershell.file.script_block_text` across the environment.\n - Ensure PowerShell script block logging is enabled and retained on systems where PowerShell is permitted so future activity can be reconstructed and scoped effectively.\n", + "query": "event.category:process and host.os.type:windows and\n powershell.file.script_block_text:(\n \"Invoke-TokenManipulation\" or\n \"ImpersonateNamedPipeClient\" or\n \"NtImpersonateThread\" or\n (\n \"STARTUPINFOEX\" and\n \"UpdateProcThreadAttribute\"\n ) or\n (\n \"AdjustTokenPrivileges\" and\n \"SeDebugPrivilege\"\n ) or\n (\n (\"DuplicateToken\" or\n \"DuplicateTokenEx\") and\n (\"SetThreadToken\" or\n \"ImpersonateLoggedOnUser\" or\n \"CreateProcessWithTokenW\" or\n \"CreatePRocessAsUserW\" or\n \"CreateProcessAsUserA\")\n ) \n ) and\n not (\n user.id:(\"S-1-5-18\" or \"S-1-5-19\" or \"S-1-5-20\") and\n file.directory: \"C:\\\\ProgramData\\\\Microsoft\\\\Windows Defender Advanced Threat Protection\\\\Downloads\"\n ) and\n not powershell.file.script_block_text : (\n \"sentinelbreakpoints\" and \"Set-PSBreakpoint\" and \"PowerSploitIndicators\"\n ) and\n not (\n powershell.file.script_block_text : \"New-HPPrivateToastNotificationLogo\" and\n file.path : \"C:\\Program Files\\HPConnect\\hp-cmsl-wl\\modules\\HP.Notifications\\HP.Notifications.psm1\"\n )\n", + "references": [ + "https://github.com/decoder-it/psgetsystem", + "https://github.com/PowerShellMafia/PowerSploit/blob/master/Privesc/Get-System.ps1", + "https://github.com/EmpireProject/Empire/blob/master/data/module_source/privesc/Invoke-MS16032.ps1", + "https://github.com/atc-project/atc-data/blob/master/docs/Logging_Policies/LP_0109_windows_powershell_script_block_log.md" + ], + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.category", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.directory", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.path", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_text", + "type": "unknown" + }, + { + "ecs": true, + "name": "user.id", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "11dd9713-0ec6-4110-9707-32daae1ee68c", + "setup": "## Setup\n\nPowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104).\nSetup instructions: https://ela.st/powershell-logging-setup\n", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Privilege Escalation", + "Data Source: PowerShell 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.001", + "name": "Token Impersonation/Theft", + "reference": "https://attack.mitre.org/techniques/T1134/001/" + } + ] + } + ] + }, + { + "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": "T1106", + "name": "Native API", + "reference": "https://attack.mitre.org/techniques/T1106/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 118 + }, + "id": "11dd9713-0ec6-4110-9707-32daae1ee68c_118", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/12a2f15d-597e-4334-88ff-38a02cb1330b_205.json b/packages/security_detection_engine/kibana/security_rule/12a2f15d-597e-4334-88ff-38a02cb1330b_205.json deleted file mode 100644 index 4d2b7a7ef79..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/12a2f15d-597e-4334-88ff-38a02cb1330b_205.json +++ /dev/null @@ -1,93 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "This rule detects when a service account or node attempts to enumerate their own permissions via the selfsubjectaccessreview or selfsubjectrulesreview APIs. This is highly unusual behavior for non-human identities like service accounts and nodes. An adversary may have gained access to credentials/tokens and this could be an attempt to determine what privileges they have to facilitate further movement or execution within the cluster.", - "false_positives": [ - "An administrator may submit this request as an \"impersonatedUser\" to determine what privileges a particular service account has been granted. However, an adversary may utilize the same technique as a means to determine the privileges of another token other than that of the compromised account." - ], - "index": [ - "logs-kubernetes.*" - ], - "language": "kuery", - "license": "Elastic License v2", - "name": "Kubernetes Suspicious Self-Subject Review", - "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 Kubernetes Suspicious Self-Subject Review\n\nKubernetes uses APIs like selfsubjectaccessreview and selfsubjectrulesreview to allow entities to check their own permissions. While useful for debugging, adversaries can exploit these APIs to assess their access level after compromising service accounts or nodes. The detection rule identifies unusual API calls by non-human identities, flagging potential unauthorized privilege enumeration attempts.\n\n### Possible investigation steps\n\n- Review the Kubernetes audit logs to identify the specific service account or node that triggered the alert by examining the kubernetes.audit.user.username or kubernetes.audit.impersonatedUser.username fields.\n- Check the context of the API call by analyzing the kubernetes.audit.objectRef.resource field to confirm whether it involved selfsubjectaccessreviews or selfsubjectrulesreviews.\n- Investigate the source of the API request by looking at the IP address and user agent in the audit logs to determine if the request originated from a known or expected source.\n- Assess the recent activity of the implicated service account or node to identify any unusual patterns or deviations from normal behavior.\n- Verify if there have been any recent changes to the permissions or roles associated with the service account or node to understand if the access level has been altered.\n- Cross-reference the alert with any other security events or alerts in the environment to determine if this is part of a broader attack or compromise.\n\n### False positive analysis\n\n- Service accounts used for automated tasks may trigger this rule if they are programmed to check permissions as part of their routine operations. To handle this, identify these accounts and create exceptions for their specific API calls.\n- Nodes performing legitimate self-assessment for compliance or security checks might be flagged. Review the node's purpose and, if necessary, whitelist these actions in the detection rule.\n- Development or testing environments where permissions are frequently checked by service accounts can generate false positives. Consider excluding these environments from the rule or adjusting the rule's sensitivity for these specific contexts.\n- Regularly scheduled jobs or scripts that include permission checks as part of their execution may cause alerts. Document these jobs and adjust the rule to ignore these specific, non-threatening behaviors.\n\n### Response and remediation\n\n- Immediately isolate the compromised service account or node by revoking its access tokens and credentials to prevent further unauthorized actions within the cluster.\n- Conduct a thorough review of the audit logs to identify any other suspicious activities or access patterns associated with the compromised identity, focusing on any lateral movement or privilege escalation attempts.\n- Rotate credentials and tokens for all service accounts and nodes that may have been exposed or compromised, ensuring that new credentials are distributed securely.\n- Implement network segmentation and access controls to limit the ability of compromised identities to interact with sensitive resources or other parts of the cluster.\n- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data have been affected.\n- Enhance monitoring and alerting for similar suspicious activities by tuning detection systems to recognize patterns of unauthorized privilege enumeration attempts.\n- Review and update Kubernetes role-based access control (RBAC) policies to ensure that service accounts and nodes have the minimum necessary permissions, reducing the risk of privilege abuse.", - "query": "event.dataset : \"kubernetes.audit_logs\"\n and kubernetes.audit.annotations.authorization_k8s_io/decision:\"allow\"\n and kubernetes.audit.verb:\"create\"\n and kubernetes.audit.objectRef.resource:(\"selfsubjectaccessreviews\" or \"selfsubjectrulesreviews\")\n and (kubernetes.audit.user.username:(system\\:serviceaccount\\:* or system\\:node\\:*)\n or kubernetes.audit.impersonatedUser.username:(system\\:serviceaccount\\:* or system\\:node\\:*))\n", - "references": [ - "https://www.paloaltonetworks.com/apps/pan/public/downloadResource?pagePath=/content/pan/en_US/resources/whitepapers/kubernetes-privilege-escalation-excessive-permissions-in-popular-platforms", - "https://kubernetes.io/docs/reference/access-authn-authz/authorization/#checking-api-access", - "https://techcommunity.microsoft.com/t5/microsoft-defender-for-cloud/detecting-identity-attacks-in-kubernetes/ba-p/3232340" - ], - "related_integrations": [ - { - "package": "kubernetes", - "version": "^1.80.0" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "event.dataset", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.annotations.authorization_k8s_io/decision", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.impersonatedUser.username", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.objectRef.resource", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.user.username", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.verb", - "type": "keyword" - } - ], - "risk_score": 47, - "rule_id": "12a2f15d-597e-4334-88ff-38a02cb1330b", - "setup": "The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule.", - "severity": "medium", - "tags": [ - "Data Source: Kubernetes", - "Tactic: Discovery", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0007", - "name": "Discovery", - "reference": "https://attack.mitre.org/tactics/TA0007/" - }, - "technique": [ - { - "id": "T1613", - "name": "Container and Resource Discovery", - "reference": "https://attack.mitre.org/techniques/T1613/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "query", - "version": 205 - }, - "id": "12a2f15d-597e-4334-88ff-38a02cb1330b_205", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/12cbf709-69e8-4055-94f9-24314385c27e_206.json b/packages/security_detection_engine/kibana/security_rule/12cbf709-69e8-4055-94f9-24314385c27e_206.json deleted file mode 100644 index 5ae6f62010b..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/12cbf709-69e8-4055-94f9-24314385c27e_206.json +++ /dev/null @@ -1,109 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "This rules detects an attempt to create or modify a pod attached to the host network. HostNetwork allows a pod to use the node network namespace. Doing so gives the pod access to any service running on localhost of the host. An attacker could use this access to snoop on network activity of other pods on the same node or bypass restrictive network policies applied to its given namespace.", - "false_positives": [ - "An administrator or developer may want to use a pod that runs as root and shares the hosts IPC, Network, and PID namespaces for debugging purposes. If something is going wrong in the cluster and there is no easy way to SSH onto the host nodes directly, a privileged pod of this nature can be useful for viewing things like iptable rules and network namespaces from the host's perspective. Add exceptions for trusted container images using the query field \"kubernetes.audit.requestObject.spec.container.image\"" - ], - "index": [ - "logs-kubernetes.*" - ], - "language": "kuery", - "license": "Elastic License v2", - "name": "Kubernetes Pod Created With HostNetwork", - "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 Kubernetes Pod Created With HostNetwork\n\nKubernetes allows pods to connect to the host's network namespace using HostNetwork, granting them direct access to the node's network interfaces. This capability can be exploited by attackers to monitor or intercept network traffic, potentially bypassing network policies. The detection rule identifies suspicious pod creation or modification events with HostNetwork enabled, excluding known benign images, to flag potential privilege escalation attempts.\n\n### Possible investigation steps\n\n- Review the Kubernetes audit logs to identify the source of the pod creation or modification event, focusing on the user or service account associated with the action.\n- Examine the pod's configuration details, especially the containers' images, to determine if any unauthorized or suspicious images are being used, excluding known benign images like \"docker.elastic.co/beats/elastic-agent:8.4.0\".\n- Investigate the network activity of the node where the pod is running to identify any unusual traffic patterns or potential data exfiltration attempts.\n- Check the Kubernetes RBAC (Role-Based Access Control) settings to ensure that the user or service account has appropriate permissions and is not overly privileged.\n- Assess the necessity of using HostNetwork for the pod in question and determine if it can be reconfigured to operate without this setting to reduce potential security risks.\n\n### False positive analysis\n\n- Pods used for monitoring or logging may require HostNetwork access to gather network data across nodes. Users can exclude these by adding their specific container images to the exception list in the detection rule.\n- Certain system-level services or infrastructure components might need HostNetwork for legitimate reasons, such as network plugins or ingress controllers. Identify these services and update the rule to exclude their specific images or namespaces.\n- Development or testing environments might frequently create pods with HostNetwork for debugging purposes. Consider creating a separate rule or environment-specific exceptions to avoid alert fatigue in these scenarios.\n- Pods that are part of a known and trusted deployment process, which require HostNetwork for valid operational reasons, should be documented and excluded from the rule to prevent unnecessary alerts.\n\n### Response and remediation\n\n- Immediately isolate the affected pod by cordoning the node to prevent new pods from being scheduled and draining existing pods to other nodes, except the suspicious one.\n- Terminate the suspicious pod to stop any potential malicious activity and prevent further network access.\n- Review and revoke any unnecessary permissions or roles associated with the service account used by the pod to limit privilege escalation opportunities.\n- Conduct a thorough audit of network policies to ensure they are correctly configured to prevent unauthorized access to the host network.\n- Escalate the incident to the security operations team for further investigation and to determine if any data was accessed or exfiltrated.\n- Implement additional monitoring and alerting for any future pod creations with HostNetwork enabled to quickly detect similar threats.\n- Review and update Kubernetes RBAC policies to enforce the principle of least privilege, ensuring only trusted entities can create pods with HostNetwork enabled.", - "query": "event.dataset : \"kubernetes.audit_logs\"\n and kubernetes.audit.annotations.authorization_k8s_io/decision:\"allow\"\n and kubernetes.audit.objectRef.resource:\"pods\"\n and kubernetes.audit.verb:(\"create\" or \"update\" or \"patch\")\n and kubernetes.audit.requestObject.spec.hostNetwork:true\n and not kubernetes.audit.requestObject.spec.containers.image: (\"docker.elastic.co/beats/elastic-agent:8.4.0\")\n", - "references": [ - "https://research.nccgroup.com/2021/11/10/detection-engineering-for-kubernetes-clusters/#part3-kubernetes-detections", - "https://kubernetes.io/docs/concepts/security/pod-security-policy/#host-namespaces", - "https://bishopfox.com/blog/kubernetes-pod-privilege-escalation" - ], - "related_integrations": [ - { - "package": "kubernetes", - "version": "^1.80.0" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "event.dataset", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.annotations.authorization_k8s_io/decision", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.objectRef.resource", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.requestObject.spec.containers.image", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.requestObject.spec.hostNetwork", - "type": "boolean" - }, - { - "ecs": false, - "name": "kubernetes.audit.verb", - "type": "keyword" - } - ], - "risk_score": 47, - "rule_id": "12cbf709-69e8-4055-94f9-24314385c27e", - "setup": "The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule.", - "severity": "medium", - "tags": [ - "Data Source: Kubernetes", - "Tactic: Execution", - "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": "T1611", - "name": "Escape to Host", - "reference": "https://attack.mitre.org/techniques/T1611/" - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0002", - "name": "Execution", - "reference": "https://attack.mitre.org/tactics/TA0002/" - }, - "technique": [ - { - "id": "T1610", - "name": "Deploy Container", - "reference": "https://attack.mitre.org/techniques/T1610/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "query", - "version": 206 - }, - "id": "12cbf709-69e8-4055-94f9-24314385c27e_206", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/14de811c-d60f-11ec-9fd7-f661ea17fbce_207.json b/packages/security_detection_engine/kibana/security_rule/14de811c-d60f-11ec-9fd7-f661ea17fbce_207.json deleted file mode 100644 index 8669d2e3405..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/14de811c-d60f-11ec-9fd7-f661ea17fbce_207.json +++ /dev/null @@ -1,92 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "This rule detects a user attempt to establish a shell session into a pod using the 'exec' command. Using the 'exec' command in a pod allows a user to establish a temporary shell session and execute any process/commands in the pod. An adversary may call bash to gain a persistent interactive shell which will allow access to any data the pod has permissions to, including secrets.", - "false_positives": [ - "An administrator may need to exec into a pod for a legitimate reason like debugging purposes. Containers built from Linux and Windows OS images, tend to include debugging utilities. In this case, an admin may choose to run commands inside a specific container with kubectl exec ${POD_NAME} -c ${CONTAINER_NAME} -- ${CMD} ${ARG1} ${ARG2} ... ${ARGN}. For example, the following command can be used to look at logs from a running Cassandra pod: kubectl exec cassandra --cat /var/log/cassandra/system.log . Additionally, the -i and -t arguments might be used to run a shell connected to the terminal: kubectl exec -i -t cassandra -- sh" - ], - "index": [ - "logs-kubernetes.*" - ], - "language": "eql", - "license": "Elastic License v2", - "name": "Kubernetes User Exec into Pod", - "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 Kubernetes User Exec into Pod\n\nKubernetes allows users to execute commands within a pod using the 'exec' command, facilitating temporary shell sessions for legitimate management tasks. However, adversaries can exploit this to gain unauthorized access, potentially exposing sensitive data. The detection rule identifies such misuse by monitoring audit logs for specific patterns, such as allowed 'exec' actions on pods, indicating possible malicious activity.\n\n### Possible investigation steps\n\n- Review the Kubernetes audit logs to identify the user who executed the 'exec' command by examining the event.dataset field for \"kubernetes.audit_logs\".\n- Check the kubernetes.audit.annotations.authorization_k8s_io/decision field to confirm that the action was allowed and determine if the user had legitimate access.\n- Investigate the kubernetes.audit.objectRef.resource and kubernetes.audit.objectRef.subresource fields to verify that the action involved a pod and the 'exec' subresource.\n- Analyze the context of the pod involved, including its purpose and the data it has access to, to assess the potential impact of the unauthorized access.\n- Correlate the event with other logs or alerts to identify any suspicious patterns or repeated unauthorized access attempts by the same user or IP address.\n- Review the user's activity history to determine if there are other instances of unusual or unauthorized access attempts within the Kubernetes environment.\n\n### False positive analysis\n\n- Routine administrative tasks by DevOps teams can trigger the rule when they use 'exec' for legitimate management purposes. To handle this, create exceptions for specific user accounts or roles that are known to perform these tasks regularly.\n- Automated scripts or tools that use 'exec' for monitoring or maintenance can also cause false positives. Identify these scripts and whitelist their associated service accounts or IP addresses.\n- Scheduled jobs or cron tasks that require 'exec' to perform updates or checks within pods may be flagged. Exclude these by setting up time-based exceptions for known maintenance windows.\n- Development environments where frequent testing and debugging occur using 'exec' can lead to alerts. Implement environment-specific exclusions to reduce noise from non-production clusters.\n\n### Response and remediation\n\n- Immediately isolate the affected pod to prevent further unauthorized access or data exposure. This can be done by applying network policies or temporarily scaling down the pod.\n- Review the audit logs to identify the user or service account responsible for the 'exec' command and assess whether the access was legitimate or unauthorized.\n- Revoke or adjust permissions for the identified user or service account to prevent further unauthorized 'exec' actions. Ensure that only necessary permissions are granted following the principle of least privilege.\n- Conduct a thorough investigation of the pod's environment to identify any potential data exposure or tampering. Check for unauthorized changes to configurations, secrets, or data within the pod.\n- If unauthorized access is confirmed, rotate any exposed secrets or credentials that the pod had access to, and update any affected systems or services.\n- Escalate the incident to the security operations team for further analysis and to determine if additional systems or pods have been compromised.\n- Enhance monitoring and alerting for similar 'exec' actions in the future by ensuring that audit logs are continuously reviewed and that alerts are configured to notify the security team of any suspicious activity.", - "query": "any where host.os.type == \"linux\" and event.dataset == \"kubernetes.audit_logs\" and\nkubernetes.audit.verb in (\"get\", \"create\") and kubernetes.audit.objectRef.subresource == \"exec\" and\nkubernetes.audit.stage == \"ResponseComplete\" and `kubernetes.audit.annotations.authorization_k8s_io/decision` == \"allow\"\n", - "references": [ - "https://kubernetes.io/docs/tasks/debug/debug-application/debug-running-pod/", - "https://kubernetes.io/docs/tasks/debug/debug-application/get-shell-running-container/" - ], - "related_integrations": [ - { - "package": "kubernetes", - "version": "^1.4.1" - } - ], - "required_fields": [ - { - "ecs": false, - "name": "`kubernetes.audit.annotations.authorization_k8s_io/decision`", - "type": "unknown" - }, - { - "ecs": true, - "name": "event.dataset", - "type": "keyword" - }, - { - "ecs": true, - "name": "host.os.type", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.objectRef.subresource", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.stage", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.verb", - "type": "keyword" - } - ], - "risk_score": 47, - "rule_id": "14de811c-d60f-11ec-9fd7-f661ea17fbce", - "setup": "The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule.", - "severity": "medium", - "tags": [ - "Data Source: Kubernetes", - "Tactic: Execution", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0002", - "name": "Execution", - "reference": "https://attack.mitre.org/tactics/TA0002/" - }, - "technique": [ - { - "id": "T1609", - "name": "Container Administration Command", - "reference": "https://attack.mitre.org/techniques/T1609/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "eql", - "version": 207 - }, - "id": "14de811c-d60f-11ec-9fd7-f661ea17fbce_207", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/166727ab-6768-4e26-b80c-948b228ffc06_110.json b/packages/security_detection_engine/kibana/security_rule/166727ab-6768-4e26-b80c-948b228ffc06_110.json new file mode 100644 index 00000000000..1278c48994b --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/166727ab-6768-4e26-b80c-948b228ffc06_110.json @@ -0,0 +1,116 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies the modification of a file creation time for executable files in sensitive system directories. Adversaries may modify file time attributes to blend malicious executables with legitimate system files. Timestomping is a technique that modifies the timestamps of a file often to mimic files that are in trusted directories.", + "from": "now-9m", + "index": [ + "winlogbeat-*", + "logs-windows.sysmon_operational-*" + ], + "investigation_fields": { + "field_names": [ + "@timestamp", + "user.name", + "user.domain", + "file.path", + "file.name", + "host.name", + "host.id", + "process.executable", + "winlog.event_data.CreationUtcTime", + "winlog.event_data.PreviousCreationUtcTime" + ] + }, + "language": "eql", + "license": "Elastic License v2", + "name": "Potential Timestomp in Executable Files", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This guide was created by humans with the assistance of generative AI. While its contents have been manually curated to include the most valuable information, always validate assumptions and adjust procedures to match your internal runbooks and incident triage and response policies.\n\n### Investigating Potential Timestomp in Executable Files\n\nThis alert indicates that a process modified the creation timestamp of a file with an executable extension in a sensitive Windows directory or a common persistence location. Timestomping can be used to make recently created or modified files appear older and blend in with legitimate system content.\n\n#### Possible investigation steps\n- Establish scope and validate context:\n - Identify the affected endpoint using `host.name` and `host.id`, and determine whether similar alerts or related file-timestamp changes are occurring on the same host.\n - Review `user.name`, `user.domain`, and `user.id` to understand whether the account typically performs administrative or software management activities on this endpoint.\n - Use `@timestamp` to bound a focused time window for pivots (for example, shortly before and after the change).\n\n- Assess the timestamp change behavior:\n - Compare `winlog.event_data.PreviousCreationUtcTime` to `winlog.event_data.CreationUtcTime` and note whether the timestamp was backdated, forward-dated, or aligned to an apparent baseline.\n - Identify whether multiple files were modified in the same window by searching for additional events on the same `host.id` and `process.entity_id`.\n\n- Evaluate the target file:\n - Review `file.path`, `file.directory`, `file.name`, and `file.extension` to determine whether the target is expected in that location and whether the name resembles a legitimate component for the directory.\n - If the file is in a Startup location, treat it as a potential persistence artifact and prioritize determining whether it later executed on the host.\n - If the file is in a system directory, assess whether the host role and recent maintenance activity could reasonably explain changes to that specific file.\n\n- Investigate the process responsible for the change:\n - Review `process.executable` and `process.name` for signs of an unusual execution location, unexpected binary name, or a process that does not normally manage files in the target directory.\n - Pivot using `process.entity_id` (or `process.pid` within a narrow time range) to reconstruct process ancestry and command context using your available process telemetry.\n - Look for additional activity by the same process in the same time window, such as other file modifications involving the same `file.path` or other executable files in similar directories.\n\n- Check for follow-on execution and related activity:\n - Search for subsequent activity on the same `host.id` where `process.executable` matches the alerted `file.path`, which can indicate the modified file was executed after timestomping.\n - If the target is a shortcut (`file.extension` such as `lnk`), look for later execution on the host that aligns with user logon activity for `user.id` and the alert timeline.\n - Identify whether the same `file.name` and `file.path` appear on other endpoints, which may indicate propagation, a shared deployment mechanism, or a broader intrusion set.\n\n### False positive analysis\n- Enterprise software deployment, patching, and self-update mechanisms can rewrite binaries and adjust file metadata as part of normal operations.\n- Backup, restore, profile reset, and file synchronization workflows can preserve or reapply timestamps when placing executables into directories.\n- Administrative troubleshooting or recovery activities (for example, repairing installations or restoring components) may result in unexpected timestamp changes for legitimate files.\n\n### Response and remediation\n- If the activity is unexpected or suspicious:\n - Contain the host to limit further tampering and reduce the risk of execution or persistence.\n - Preserve evidence for the alert by capturing the values of `file.path`, `process.executable`, `process.entity_id`, `user.id`, and the before/after timestamps, and collect related events on the same `host.id` in the surrounding window.\n - Determine whether the affected file executed after the change by correlating activity on the same `host.id` and comparing `process.executable` to the alerted `file.path`.\n - Acquire and analyze the target file and the modifying process binary using your standard tooling to assess reputation, integrity, and suspected origin.\n - Remove or quarantine malicious files and remediate unauthorized persistence, especially for items placed in Startup locations.\n - Scope across the environment for the same `file.path`, `file.name`, and `process.executable`, and apply containment actions to additional affected hosts as needed.\n - If compromise is suspected, review access associated with `user.id` and follow incident response procedures for account containment and recovery.\n\n- If the activity is confirmed benign:\n - Document the legitimate software or workflow responsible for the timestamp change, including the expected `process.executable` and target paths, to support consistent triage and future tuning.\n", + "query": "file where host.os.type == \"windows\" and\n event.provider == \"Microsoft-Windows-Sysmon\" and event.code == \"2\" and\n file.extension : (\n \"exe\", \"dll\", \"sys\", \"msi\", \"scr\", \"pif\", \"lnk\"\n ) and\n file.path : (\n \"?:\\\\Windows\\\\System32\\\\*\",\n \"?:\\\\Windows\\\\SysWOW64\\\\*\",\n \"?:\\\\ProgramData\\\\*\",\n \"?:\\\\Users\\\\Public\\\\*\",\n \"?:\\\\Users\\\\*\\\\AppData\\\\Roaming\\\\Microsoft\\\\Windows\\\\Start Menu\\\\Programs\\\\Startup\\\\*\",\n \"?:\\\\ProgramData\\\\Microsoft\\\\Windows\\\\Start Menu\\\\Programs\\\\Startup\\\\*\"\n ) and\n not process.executable : (\n \"?:\\\\Program Files\\\\*\",\n \"?:\\\\Program Files (x86)\\\\*\",\n \"?:\\\\Windows\\\\system32\\\\cleanmgr.exe\",\n \"?:\\\\Windows\\\\system32\\\\msiexec.exe\",\n \"?:\\\\Windows\\\\syswow64\\\\msiexec.exe\",\n \"?:\\\\Windows\\\\system32\\\\svchost.exe\",\n \"?:\\\\Windows\\\\System32\\\\Robocopy.exe\",\n \"?:\\\\Windows\\\\SysWOW64\\\\Robocopy.exe\"\n ) and\n not (process.executable : \"?:\\\\Windows\\\\System32\\\\spoolsv.exe\" and file.path : \"?:\\\\Windows\\\\System32\\\\spool\\\\*\") and\n not user.name : (\"SYSTEM\", \"Local Service\", \"Network Service\")\n", + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.code", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.provider", + "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": "process.executable", + "type": "keyword" + }, + { + "ecs": true, + "name": "user.name", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "166727ab-6768-4e26-b80c-948b228ffc06", + "setup": "## Setup\n\nSysmon must be installed and configured to generate the events used by this rule (Event ID 2).\nSetup instructions: https://ela.st/sysmon-event-2-setup\n", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: Sysmon", + "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/", + "subtechnique": [ + { + "id": "T1070.006", + "name": "Timestomp", + "reference": "https://attack.mitre.org/techniques/T1070/006/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 110 + }, + "id": "166727ab-6768-4e26-b80c-948b228ffc06_110", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/16904215-2c95-4ac8-bf5c-12354e047192_107.json b/packages/security_detection_engine/kibana/security_rule/16904215-2c95-4ac8-bf5c-12354e047192_107.json deleted file mode 100644 index 0154e6c7c6f..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/16904215-2c95-4ac8-bf5c-12354e047192_107.json +++ /dev/null @@ -1,112 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies use of Bifrost, a known macOS Kerberos pentesting tool, which can be used to dump cached Kerberos tickets or attempt unauthorized authentication techniques such as pass-the-ticket/hash and kerberoasting.", - "from": "now-9m", - "index": [ - "logs-endpoint.events.*" - ], - "language": "kuery", - "license": "Elastic License v2", - "name": "Potential Kerberos Attack via Bifrost", - "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 Attack via Bifrost\n\nKerberos is a network authentication protocol designed to provide secure identity verification for users and services. Adversaries exploit tools like Bifrost on macOS to extract Kerberos tickets or perform unauthorized authentications, such as pass-the-ticket attacks. The detection rule identifies suspicious process activities linked to Bifrost's known attack methods, focusing on specific command-line arguments indicative of credential access and lateral movement attempts.\n\n### Possible investigation steps\n\n- Review the process start event details to identify the specific command-line arguments used, focusing on those that match the suspicious patterns such as \"-action\", \"-kerberoast\", \"askhash\", \"asktgs\", \"asktgt\", \"s4u\", \"-ticket ptt\", or \"dump tickets/keytab\".\n- Correlate the process execution with user activity logs to determine if the process was initiated by a legitimate user or an unauthorized account.\n- Check for any recent changes in user permissions or group memberships that could indicate privilege escalation attempts.\n- Investigate the source and destination of any network connections made by the process to identify potential lateral movement or data exfiltration.\n- Analyze historical data for similar process executions or patterns to assess if this is an isolated incident or part of a broader attack campaign.\n- Review endpoint security logs for any additional indicators of compromise or related suspicious activities around the time of the alert.\n\n### False positive analysis\n\n- Legitimate administrative tasks on macOS systems may trigger the rule if they involve Kerberos ticket management. To handle this, identify and document routine administrative processes that use similar command-line arguments and create exceptions for these specific activities.\n- Security tools or scripts designed for Kerberos ticket management or testing may mimic Bifrost's behavior. Review and whitelist these tools if they are part of authorized security assessments or IT operations.\n- Automated system processes that interact with Kerberos for legitimate authentication purposes might be flagged. Monitor these processes and exclude them from the rule if they are verified as non-threatening and essential for system operations.\n- Developers or IT personnel testing Kerberos configurations in a controlled environment could inadvertently trigger the rule. Ensure that such environments are well-documented and excluded from monitoring to prevent false positives.\n\n### Response and remediation\n\n- Immediately isolate the affected macOS host from the network to prevent further unauthorized access or lateral movement.\n- Terminate any suspicious processes identified by the detection rule, particularly those involving Bifrost command-line arguments.\n- Conduct a thorough review of Kerberos ticket logs and authentication attempts to identify any unauthorized access or anomalies.\n- Revoke and reissue Kerberos tickets for affected users and services to ensure no compromised tickets are in use.\n- Update and patch the macOS system and any related software to mitigate vulnerabilities that may have been exploited.\n- Implement enhanced monitoring for Kerberos-related activities, focusing on unusual patterns or command-line arguments similar to those used by Bifrost.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised.", - "query": "event.category:process and host.os.type:macos and event.type:start and\n process.args:(\"-action\" and (\"-kerberoast\" or askhash or asktgs or asktgt or s4u or (\"-ticket\" and ptt) or (dump and (tickets or keytab))))\n", - "references": [ - "https://github.com/its-a-feature/bifrost" - ], - "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" - } - ], - "risk_score": 73, - "rule_id": "16904215-2c95-4ac8-bf5c-12354e047192", - "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 macOS 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, for MacOS it is recommended to select \"Traditional Endpoints\".\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/current/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: macOS", - "Use Case: Threat Detection", - "Tactic: Credential Access", - "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": "T1550", - "name": "Use Alternate Authentication Material", - "reference": "https://attack.mitre.org/techniques/T1550/", - "subtechnique": [ - { - "id": "T1550.003", - "name": "Pass the Ticket", - "reference": "https://attack.mitre.org/techniques/T1550/003/" - } - ] - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0006", - "name": "Credential Access", - "reference": "https://attack.mitre.org/tactics/TA0006/" - }, - "technique": [ - { - "id": "T1558", - "name": "Steal or Forge Kerberos Tickets", - "reference": "https://attack.mitre.org/techniques/T1558/", - "subtechnique": [ - { - "id": "T1558.003", - "name": "Kerberoasting", - "reference": "https://attack.mitre.org/techniques/T1558/003/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "query", - "version": 107 - }, - "id": "16904215-2c95-4ac8-bf5c-12354e047192_107", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/16a52c14-7883-47af-8745-9357803f0d4c_115.json b/packages/security_detection_engine/kibana/security_rule/16a52c14-7883-47af-8745-9357803f0d4c_115.json deleted file mode 100644 index 6c299f361c3..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/16a52c14-7883-47af-8745-9357803f0d4c_115.json +++ /dev/null @@ -1,154 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies Component Object Model (COM) hijacking via registry modification. Adversaries may establish persistence by executing malicious content triggered by hijacked references to COM objects.", - "from": "now-9m", - "index": [ - "logs-endpoint.events.registry-*" - ], - "language": "eql", - "license": "Elastic License v2", - "name": "Component Object Model Hijacking", - "note": "## Triage and analysis\n\n### Investigating Component Object Model Hijacking\n\nAdversaries can insert malicious code that can be executed in place of legitimate software through hijacking the COM references and relationships as a means of persistence.\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- Identify the user account that performed the action and whether it should perform this kind of action.\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- Retrieve the file referenced in the registry and determine if it is malicious:\n - Use a private sandboxed malware analysis system to perform analysis.\n - Observe and collect information about the following activities:\n - Attempts to contact external domains and addresses.\n - File and registry access, modification, and creation activities.\n - Service creation and launch activities.\n - Scheduled task creation.\n - Use the PowerShell Get-FileHash cmdlet to get the files' SHA-256 hash values.\n - Search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.\n\n### False positive analysis\n\n- Some Microsoft executables will reference the LocalServer32 registry key value for the location of external COM objects.\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- 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": "registry where host.os.type == \"windows\" and event.type == \"change\" and\n /* not necessary but good for filtering privileged installations */\n user.domain != \"NT AUTHORITY\" and process.executable != null and \n (\n (\n registry.path : \"HK*\\\\InprocServer32\\\\\" and\n registry.data.strings: (\"scrobj.dll\", \"?:\\\\*\\\\scrobj.dll\") and\n not registry.path : \"*\\\\{06290BD*-48AA-11D2-8432-006008C3FBFC}\\\\*\"\n ) or\n\n (\n registry.path : \"HKLM\\\\*\\\\InProcServer32\\\\*\" and\n registry.data.strings : (\"*\\\\Users\\\\*\", \"*\\\\ProgramData\\\\*\")\n ) or\n\n /* in general COM Registry changes on Users Hive is less noisy and worth alerting */\n (\n registry.path : (\n \"HKEY_USERS\\\\*\\\\InprocServer32\\\\\",\n \"HKEY_USERS\\\\*\\\\LocalServer32\\\\\",\n \"HKEY_USERS\\\\*\\\\DelegateExecute\",\n \"HKEY_USERS\\\\*\\\\TreatAs\\\\\",\n \"HKEY_USERS\\\\*\\\\ScriptletURL*\"\n ) \n )\n ) and \n\n not (\n process.code_signature.trusted == true and\n process.code_signature.subject_name in \n (\"Island Technology Inc.\", \"Google LLC\", \"Grammarly, Inc.\", \"Dropbox, Inc\", \"REFINITIV US LLC\", \"HP Inc.\",\n \"Citrix Systems, Inc.\", \"Adobe Inc.\", \"Veeam Software Group GmbH\", \"Zhuhai Kingsoft Office Software Co., Ltd.\",\n \"Oracle America, Inc.\")\n ) and \n\n /* excludes Microsoft signed noisy processes */\n not\n (\n process.name : (\"OneDrive.exe\", \"OneDriveSetup.exe\", \"FileSyncConfig.exe\", \"Teams.exe\", \"MicrosoftEdgeUpdate.exe\", \"msrdcw.exe\", \"MicrosoftEdgeUpdateComRegisterShell64.exe\") and\n process.code_signature.trusted == true and process.code_signature.subject_name in (\"Microsoft Windows\", \"Microsoft Corporation\")\n ) and\n \n not process.executable : \n (\"?:\\\\Program Files (x86)\\\\*.exe\", \n \"?:\\\\Program Files\\\\*.exe\",\n \"?:\\\\Windows\\\\System32\\\\svchost.exe\", \n \"?:\\\\Windows\\\\System32\\\\msiexec.exe\", \n \"?:\\\\Windows\\\\SysWOW64\\\\regsvr32.exe\",\n \"?:\\\\Windows\\\\System32\\\\regsvr32.exe\",\n \"?:\\\\Windows\\\\System32\\\\DriverStore\\\\FileRepository\\\\*.exe\", \n \"?:\\\\ProgramData\\\\Microsoft\\\\Windows Defender\\\\Platform\\\\*\\\\MsMpEng.exe\")\n", - "references": [ - "https://bohops.com/2018/08/18/abusing-the-com-registry-structure-part-2-loading-techniques-for-evasion-and-persistence/" - ], - "related_integrations": [ - { - "package": "endpoint", - "version": "^9.0.0" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "event.type", - "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": "registry.data.strings", - "type": "wildcard" - }, - { - "ecs": true, - "name": "registry.path", - "type": "keyword" - }, - { - "ecs": true, - "name": "user.domain", - "type": "keyword" - } - ], - "risk_score": 47, - "rule_id": "16a52c14-7883-47af-8745-9357803f0d4c", - "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: Windows", - "Use Case: Threat Detection", - "Tactic: Persistence", - "Tactic: Defense Evasion", - "Tactic: Privilege Escalation", - "Resources: Investigation Guide", - "Data Source: Elastic Endgame", - "Data Source: Elastic Defend" - ], - "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.015", - "name": "Component Object Model Hijacking", - "reference": "https://attack.mitre.org/techniques/T1546/015/" - } - ] - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0004", - "name": "Privilege Escalation", - "reference": "https://attack.mitre.org/tactics/TA0004/" - }, - "technique": [ - { - "id": "T1546", - "name": "Event Triggered Execution", - "reference": "https://attack.mitre.org/techniques/T1546/", - "subtechnique": [ - { - "id": "T1546.015", - "name": "Component Object Model Hijacking", - "reference": "https://attack.mitre.org/techniques/T1546/015/" - } - ] - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0005", - "name": "Defense Evasion", - "reference": "https://attack.mitre.org/tactics/TA0005/" - }, - "technique": [ - { - "id": "T1112", - "name": "Modify Registry", - "reference": "https://attack.mitre.org/techniques/T1112/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "eql", - "version": 115 - }, - "id": "16a52c14-7883-47af-8745-9357803f0d4c_115", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/171a4981-9c1a-4a03-9028-21cff4b27b38_3.json b/packages/security_detection_engine/kibana/security_rule/171a4981-9c1a-4a03-9028-21cff4b27b38_3.json new file mode 100644 index 00000000000..5009d9f6a06 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/171a4981-9c1a-4a03-9028-21cff4b27b38_3.json @@ -0,0 +1,126 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects potential lateral movement or post-compromise activity by correlating alerts where the host.ip of one alert matches the source.ip of a subsequent alert. This behavior may indicate a compromised host being used to authenticate to another system or resource, including cloud services.", + "from": "now-30m", + "interval": "29m", + "language": "esql", + "license": "Elastic License v2", + "name": "Suspected Lateral Movement 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 Suspected Lateral Movement from Compromised Host\n\nThe detection rule uses alert data to determine when multiple alerts from different integrations involving the same user.name are triggered.\n\n### Possible investigation steps\n\n- Review the alert details to identify the specific host involved and the different modules and rules that triggered the alert.\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- Vulnerability scanners.\n- Jump hosts, NAT gateways and proxies.\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.*\n\n// any alerts excluding deprecated, low severity and threat_match rules\n| where kibana.alert.rule.name is not null and kibana.alert.risk_score > 21 and\n kibana.alert.rule.type != \"threat_match\" and\n not kibana.alert.rule.name like \"Deprecated - *\" and\n not KQL(\"\"\"kibana.alert.rule.tags : \"Rule Type: Higher-Order Rule\" \"\"\") and\n not kibana.alert.rule.name in (\"Abnormally Large DNS Response\", \"Web Application Suspicious Activity: No User Agent\")\n\n// alerts with existing source.ip or host.ip\n| eval alert_source_ip = CASE(source.ip is not null, source.ip, null),\n alert_host_ip = CASE(host.ip is not null and source.ip is null, host.ip, null)\n\n| eval Esql.source_ip = COALESCE(alert_source_ip, alert_host_ip)\n| where Esql.source_ip is not null and Esql.source_ip != \"127.0.0.1\" and Esql.source_ip != \"::1\"\n\n| stats Esql.alerts_count = COUNT(*),\n Esql.event_module_distinct_count = COUNT_DISTINCT(event.module),\n Esql.host_id_distinct_count = COUNT_DISTINCT(host.id),\n Esql.rule_name_distinct_count = COUNT_DISTINCT(kibana.alert.rule.name),\n Esql.event_module_values = VALUES(event.module),\n Esql.message_values = VALUES(message),\n Esql.rule_name = VALUES(kibana.alert.rule.name),\n Esql.event_action_values = VALUES(event.action),\n Esql.event_category_values = VALUES(event.category),\n Esql.process_executable_values = VALUES(process.executable),\n Esql.process_cmdline_values = VALUES(process.command_line),\n Esql.file_path_values = VALUES(file.path),\n Esql.host_id_values = VALUES(host.id),\n Esql.host_ip_values = VALUES(host.ip),\n Esql.destination_ip_values = VALUES(destination.ip),\n Esql.user_name_values = VALUES(user.name),\n SRC_IP = VALUES(source.ip)\n by Esql.source_ip\n\n// filter for different alerts from multiple hosts and where the host.ip of one alert matches the source.ip of the other alert\n| eval concat_ip_values = MV_CONCAT(TO_STRING(Esql.host_ip_values), \",\")\n| eval host_ip_equal_to_source_ip =LOCATE(concat_ip_values, TO_STRING(Esql.source_ip))\n| where Esql.rule_name_distinct_count >= 2 and Esql.host_id_distinct_count >= 2 and host_ip_equal_to_source_ip > 0 and SRC_IP is not null and Esql.alerts_count <= 100\n\n// Move single values to their corresponding ECS fields for alerts exclusion\n| eval source.ip = mv_min(Esql.source_ip),\n host.id = mv_min(Esql.host_id_values)\n| KEEP Esql.*, source.ip, host.id\n", + "required_fields": [ + { + "ecs": false, + "name": "Esql.alerts_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.destination_ip_values", + "type": "ip" + }, + { + "ecs": false, + "name": "Esql.event_action_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.event_category_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.event_module_distinct_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.event_module_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.file_path_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.host_id_distinct_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.host_id_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.host_ip_values", + "type": "ip" + }, + { + "ecs": false, + "name": "Esql.message_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.process_cmdline_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.process_executable_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.rule_name", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.rule_name_distinct_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.source_ip", + "type": "ip" + }, + { + "ecs": false, + "name": "Esql.user_name_values", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.ip", + "type": "ip" + } + ], + "risk_score": 73, + "rule_id": "171a4981-9c1a-4a03-9028-21cff4b27b38", + "setup": "## Setup\n\nThis rule requires the `host.ip` field to be populated.\nFor **Elastic Defend** events on versions **8.18 and above**, this field is **disabled by default**.\n\nIf you are using **Elastic Defend**, ensure host IP collection is enabled by following the configuration steps in the\n[helper guide](https://www.elastic.co/docs/solutions/security/configure-elastic-defend/configure-data-volume-for-elastic-endpoint#host-fields).\n", + "severity": "high", + "tags": [ + "Use Case: Threat Detection", + "Rule Type: Higher-Order Rule", + "Resources: Investigation Guide" + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 3 + }, + "id": "171a4981-9c1a-4a03-9028-21cff4b27b38_3", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/18a5dd9a-e3fa-4996-99b1-ae533b8f27fc_8.json b/packages/security_detection_engine/kibana/security_rule/18a5dd9a-e3fa-4996-99b1-ae533b8f27fc_8.json new file mode 100644 index 00000000000..f1af612019c --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/18a5dd9a-e3fa-4996-99b1-ae533b8f27fc_8.json @@ -0,0 +1,63 @@ +{ + "attributes": { + "anomaly_threshold": 70, + "author": [ + "Elastic" + ], + "description": "A machine learning job has detected a high count of source IPs establishing an RDP connection with a single destination IP. Attackers might use multiple compromised systems to attack a target to ensure redundancy in case a source IP gets detected and blocked.", + "from": "now-12h", + "interval": "15m", + "license": "Elastic License v2", + "machine_learning_job_id": "lmd_high_rdp_distinct_count_source_ip_for_destination", + "name": "Spike in Number of Connections Made to a Destination IP", + "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 Spike in Number of Connections Made to a Destination IP\n\nRemote Desktop Protocol (RDP) is crucial for remote management and troubleshooting in IT environments. However, adversaries exploit RDP by using multiple compromised IPs to overwhelm a target, ensuring persistence even if some IPs are blocked. The detection rule leverages machine learning to identify unusual spikes in RDP connections to a single IP, signaling potential lateral movement attempts by attackers.\n\n### Possible investigation steps\n\n- Review the list of source IPs that have established RDP connections to the destination IP to identify any known malicious or suspicious IP addresses.\n- Check historical data for the destination IP to determine if it has been targeted in previous attacks or if it is a high-value asset within the network.\n- Analyze the timing and frequency of the RDP connections to identify any unusual patterns or spikes that could indicate coordinated activity.\n- Investigate the user accounts associated with the RDP connections to ensure they are legitimate and have not been compromised.\n- Correlate the detected activity with any other security alerts or logs to identify potential lateral movement or further exploitation attempts within the network.\n\n### False positive analysis\n\n- Routine administrative tasks may trigger false positives if multiple IT staff connect to a server for maintenance. Consider creating exceptions for known administrative IPs.\n- Automated scripts or monitoring tools that frequently connect to servers for health checks can cause spikes. Identify and exclude these IPs from the rule.\n- Load balancers or proxy servers that aggregate connections from multiple clients might appear as a spike. Exclude these devices from the detection rule.\n- Scheduled software updates or deployments that require multiple connections to a server can be mistaken for an attack. Whitelist the IPs involved in these processes.\n- Internal network scans or vulnerability assessments conducted by security teams can generate high connection counts. Ensure these activities are recognized and excluded.\n\n### Response and remediation\n\n- Immediately isolate the affected destination IP from the network to prevent further unauthorized RDP connections and potential lateral movement.\n- Conduct a thorough review of the logs and network traffic associated with the destination IP to identify all source IPs involved in the spike and assess the scope of the compromise.\n- Block all identified malicious source IPs at the firewall or network perimeter to prevent further connections to the destination IP.\n- Reset credentials and enforce multi-factor authentication for accounts that were accessed via RDP to mitigate unauthorized access.\n- Perform a security assessment of the affected systems to identify any signs of compromise or unauthorized changes, and restore systems from clean backups if necessary.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems or networks are affected.\n- Update and enhance monitoring rules to detect similar patterns of unusual RDP connection spikes in the future, ensuring quick identification and response to potential threats.", + "references": [ + "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html", + "https://docs.elastic.co/en/integrations/lmd", + "https://www.elastic.co/blog/detecting-lateral-movement-activity-a-new-kibana-integration", + "https://www.elastic.co/blog/remote-desktop-protocol-connections-elastic-security" + ], + "related_integrations": [ + { + "package": "lmd", + "version": "^2.0.0" + }, + { + "package": "endpoint", + "version": "^8.2.0" + } + ], + "risk_score": 21, + "rule_id": "18a5dd9a-e3fa-4996-99b1-ae533b8f27fc", + "setup": "## Setup\n\nThis rule requires the `host.ip` field to be populated.\nFor **Elastic Defend** events on versions **8.18 and above**, this field is **disabled by default**.\n\nIf you are using **Elastic Defend**, ensure host IP collection is enabled by following the configuration steps in the\n[helper guide](https://www.elastic.co/docs/solutions/security/configure-elastic-defend/configure-data-volume-for-elastic-endpoint#host-fields).\n\nThe rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration.\n\n### Lateral Movement Detection Setup\nThe Lateral Movement Detection integration detects lateral movement activity by identifying abnormalities in file and Windows RDP events. Anomalies are detected using Elastic's Anomaly Detection feature.\n\n#### Prerequisite Requirements:\n- Fleet is required for Lateral Movement Detection.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n- Windows RDP process events collected by the [Elastic Defend](https://docs.elastic.co/en/integrations/endpoint) integration.\n- To install Elastic Defend, refer to the [documentation](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n\n#### The following steps should be executed to install assets associated with the Lateral Movement Detection integration:\n- Go to the Kibana homepage. Under Management, click Integrations.\n- In the query bar, search for Lateral Movement Detection and select the integration to see more details about it.\n- Follow the instructions under the **Installation** section.\n- For this rule to work, complete the instructions through **Add preconfigured anomaly detection jobs**.\n", + "severity": "low", + "tags": [ + "Use Case: Lateral Movement Detection", + "Rule Type: ML", + "Rule Type: Machine Learning", + "Tactic: Lateral Movement", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0008", + "name": "Lateral Movement", + "reference": "https://attack.mitre.org/tactics/TA0008/" + }, + "technique": [ + { + "id": "T1210", + "name": "Exploitation of Remote Services", + "reference": "https://attack.mitre.org/techniques/T1210/" + } + ] + } + ], + "type": "machine_learning", + "version": 8 + }, + "id": "18a5dd9a-e3fa-4996-99b1-ae533b8f27fc_8", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/19e9daf3-f5c5-4bc2-a9af-6b1e97098f03_8.json b/packages/security_detection_engine/kibana/security_rule/19e9daf3-f5c5-4bc2-a9af-6b1e97098f03_8.json new file mode 100644 index 00000000000..3a50c491c00 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/19e9daf3-f5c5-4bc2-a9af-6b1e97098f03_8.json @@ -0,0 +1,63 @@ +{ + "attributes": { + "anomaly_threshold": 70, + "author": [ + "Elastic" + ], + "description": "A machine learning job has detected unusually high number of processes started in a single RDP session. Executing a large number of processes remotely on other machines can be an indicator of lateral movement activity.", + "from": "now-12h", + "interval": "15m", + "license": "Elastic License v2", + "machine_learning_job_id": "lmd_high_sum_rdp_number_of_processes", + "name": "Spike in Number of Processes in an RDP Session", + "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 Spike in Number of Processes in an RDP Session\n\nRemote Desktop Protocol (RDP) allows users to connect to other computers over a network, facilitating remote work and administration. However, adversaries can exploit RDP for lateral movement by executing numerous processes on a target machine. The detection rule leverages machine learning to identify anomalies in process activity during RDP sessions, flagging potential exploitation attempts indicative of lateral movement tactics.\n\n### Possible investigation steps\n\n- Review the specific RDP session details, including the source and destination IP addresses, to identify the involved machines and users.\n- Analyze the list of processes that were started during the RDP session to identify any unusual or suspicious processes that are not typically associated with legitimate remote work activities.\n- Check the user account associated with the RDP session for any signs of compromise, such as recent password changes or unusual login times.\n- Correlate the detected spike in processes with other security events or logs, such as firewall logs or intrusion detection system alerts, to identify any related suspicious activities.\n- Investigate the network traffic between the source and destination machines during the RDP session to detect any anomalies or unauthorized data transfers.\n- Review historical data for the involved user and machines to determine if similar spikes in process activity have occurred in the past, which could indicate a pattern of malicious behavior.\n\n### False positive analysis\n\n- High-volume automated tasks or scripts executed during RDP sessions can trigger false positives. Identify and document these tasks, then create exceptions in the detection rule to exclude them from analysis.\n- Routine administrative activities, such as software updates or system maintenance, may result in a spike in processes. Regularly review and whitelist these activities to prevent unnecessary alerts.\n- Scheduled batch jobs or data processing tasks that run during RDP sessions can be mistaken for lateral movement. Ensure these are logged and excluded from the rule's scope by setting up appropriate filters.\n- Development or testing environments where multiple processes are frequently started as part of normal operations can lead to false positives. Clearly define these environments and adjust the rule to ignore such sessions.\n\n### Response and remediation\n\n- Isolate the affected machine from the network to prevent further lateral movement and contain the threat.\n- Terminate any suspicious or unauthorized processes identified during the RDP session to halt potential malicious activity.\n- Conduct a thorough review of the affected machine's security logs to identify any additional indicators of compromise or related suspicious activity.\n- Reset credentials for any accounts that were used during the suspicious RDP session to prevent unauthorized access.\n- Apply security patches and updates to the affected machine and any other vulnerable systems to mitigate exploitation of known vulnerabilities.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised.\n- Enhance monitoring and detection capabilities for RDP sessions by implementing stricter access controls and logging to detect similar anomalies in the future.", + "references": [ + "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html", + "https://docs.elastic.co/en/integrations/lmd", + "https://www.elastic.co/blog/detecting-lateral-movement-activity-a-new-kibana-integration", + "https://www.elastic.co/blog/remote-desktop-protocol-connections-elastic-security" + ], + "related_integrations": [ + { + "package": "lmd", + "version": "^2.0.0" + }, + { + "package": "endpoint", + "version": "^8.2.0" + } + ], + "risk_score": 21, + "rule_id": "19e9daf3-f5c5-4bc2-a9af-6b1e97098f03", + "setup": "## Setup\n\nThis rule requires the `host.ip` field to be populated.\nFor **Elastic Defend** events on versions **8.18 and above**, this field is **disabled by default**.\n\nIf you are using **Elastic Defend**, ensure host IP collection is enabled by following the configuration steps in the\n[helper guide](https://www.elastic.co/docs/solutions/security/configure-elastic-defend/configure-data-volume-for-elastic-endpoint#host-fields).\n\nThe rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration.\n\n### Lateral Movement Detection Setup\nThe Lateral Movement Detection integration detects lateral movement activity by identifying abnormalities in file and Windows RDP events. Anomalies are detected using Elastic's Anomaly Detection feature.\n\n#### Prerequisite Requirements:\n- Fleet is required for Lateral Movement Detection.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n- Windows RDP process events collected by the [Elastic Defend](https://docs.elastic.co/en/integrations/endpoint) integration.\n- To install Elastic Defend, refer to the [documentation](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n\n#### The following steps should be executed to install assets associated with the Lateral Movement Detection integration:\n- Go to the Kibana homepage. Under Management, click Integrations.\n- In the query bar, search for Lateral Movement Detection and select the integration to see more details about it.\n- Follow the instructions under the **Installation** section.\n- For this rule to work, complete the instructions through **Add preconfigured anomaly detection jobs**.\n", + "severity": "low", + "tags": [ + "Use Case: Lateral Movement Detection", + "Rule Type: ML", + "Rule Type: Machine Learning", + "Tactic: Lateral Movement", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0008", + "name": "Lateral Movement", + "reference": "https://attack.mitre.org/tactics/TA0008/" + }, + "technique": [ + { + "id": "T1210", + "name": "Exploitation of Remote Services", + "reference": "https://attack.mitre.org/techniques/T1210/" + } + ] + } + ], + "type": "machine_learning", + "version": 8 + }, + "id": "19e9daf3-f5c5-4bc2-a9af-6b1e97098f03_8", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/1a3d5b36-b995-4ace-9b85-8a0af429ccf6_3.json b/packages/security_detection_engine/kibana/security_rule/1a3d5b36-b995-4ace-9b85-8a0af429ccf6_3.json new file mode 100644 index 00000000000..3d805b92da8 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/1a3d5b36-b995-4ace-9b85-8a0af429ccf6_3.json @@ -0,0 +1,128 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects Elastic SIEM high severity detection alerts that are observed for the first time in the previous 5 days of alert history. It highlights low-volume, newly observed alerts tied to a specific detection rule, analysts can use this to prioritize triage and response.", + "from": "now-7205m", + "interval": "5m", + "language": "esql", + "license": "Elastic License v2", + "name": "Newly Observed High Severity Detection Alert", + "note": "## Triage and analysis\n\n### Investigating Newly Observed High Severity Detection Alert\n\nThis rule surfaces newly observed, low-frequency behavior high severity alerts affecting a single agent within the current day.\n\nBecause the alert has not been seen previously for this rule and host, it should be prioritized for validation to determine\nwhether it represents a true compromise or rare benign activity.\n\n### Investigation Steps\n\n- Identify the affected host, user and review the associated rule name to understand the behavior that triggered the alert.\n- Validate the user context under which the activity occurred and assess whether it aligns with normal behavior for that account.\n- Refer to the specific rule investiguation guide for further actions.\n\n### False Positive Considerations\n\n- Newly deployed or updated software may introduce behavior not previously observed on the host.\n- Administrative scripts or automation tools can trigger behavior-based detections when first introduced.\n- Security tooling, IT management agents, or EDR integrations may generate new behavior alerts during updates or configuration changes.\n- Development or testing environments may produce one-off behaviors that resemble malicious techniques.\n\n### Response and Remediation\n\n- If the activity is confirmed malicious, isolate the affected host to prevent further execution or lateral movement.\n- Terminate malicious processes and remove any dropped files or persistence mechanisms.\n- Collect forensic artifacts to understand initial access and execution flow.\n- Patch or remediate any vulnerabilities or misconfigurations that enabled the behavior.\n- If benign, document the finding and consider tuning or exception handling to reduce future noise.\n- Continue monitoring the host and environment for recurrence of the behavior or related alerts.", + "query": "FROM .alerts-security.*\n| where kibana.alert.rule.name is not null and kibana.alert.risk_score >= 73 and\n not kibana.alert.rule.type in (\"threat_match\", \"machine_learning\", \"new_terms\") and\n not kibana.alert.rule.name like \"Deprecated - *\" and kibana.alert.rule.name != \"My First Rule\" and\n // covered by 7306ce7d-5c90-4f42-aa6c-12b0dc2fe3b8\n event.dataset != \"endpoint.alerts\" and\n not KQL(\"\"\"kibana.alert.rule.tags : \"Rule Type: Higher-Order Rule\" \"\"\")\n| STATS Esql.alerts_count = count(*),\n Esql.first_time_seen = MIN(@timestamp),\n Esql.last_time_seen = MAX(@timestamp),\n Esql.process_executable = VALUES(process.executable),\n Esql.cmd_line = VALUES(process.command_line),\n Esql.parent_executable = VALUES(process.parent.executable),\n Esql.file_path_values = VALUES(file.path),\n Esql.file_path_values = VALUES(file.path),\n Esql.dll_path_values = VALUES(dll.path),\n Esql.user_id_values = VALUES(user.id),\n Esql.user_name_values = VALUES(user.name),\n Esql.agent_id_values = VALUES(agent.id),\n Esql.host_id_values = VALUES(host.id),\n Esql.event_module_values = VALUES(event.module),\n Esql.source_ip_values = VALUES(source.ip), \n Esql.rule_name_values = VALUES(kibana.alert.rule.name),\n Esql.agents_distinct_count = COUNT_DISTINCT(agent.id) by kibana.alert.rule.name\n// fist time seen in the last 5 days - defined in the rule schedule Additional look-back time\n| eval Esql.recent = DATE_DIFF(\"minute\", Esql.first_time_seen, now())\n// first time seen is within 10m of the rule execution time\n| where Esql.recent <= 10 and Esql.agents_distinct_count == 1 and Esql.alerts_count <= 10 and (Esql.last_time_seen == Esql.first_time_seen)\n\n// Move single values to their corresponding ECS fields for alerts exclusion\n| eval host.id = mv_min(Esql.host_id_values)\n\n| keep host.id, kibana.alert.rule.name, Esql.*\n", + "references": [ + "https://www.elastic.co/docs/solutions/security/detect-and-alert/about-detection-rules" + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.agent_id_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.agents_distinct_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.alerts_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.cmd_line", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.dll_path_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.event_module_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.file_path_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.first_time_seen", + "type": "date" + }, + { + "ecs": false, + "name": "Esql.host_id_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.last_time_seen", + "type": "date" + }, + { + "ecs": false, + "name": "Esql.parent_executable", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.process_executable", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.recent", + "type": "integer" + }, + { + "ecs": false, + "name": "Esql.rule_name_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.source_ip_values", + "type": "ip" + }, + { + "ecs": false, + "name": "Esql.user_id_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.user_name_values", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.id", + "type": "keyword" + }, + { + "ecs": false, + "name": "kibana.alert.rule.name", + "type": "keyword" + } + ], + "risk_score": 73, + "rule_id": "1a3d5b36-b995-4ace-9b85-8a0af429ccf6", + "severity": "high", + "tags": [ + "Use Case: Threat Detection", + "Rule Type: Higher-Order Rule", + "Resources: Investigation Guide" + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 3 + }, + "id": "1a3d5b36-b995-4ace-9b85-8a0af429ccf6_3", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/1b65429e-bd92-44c0-aff8-e8065869d860_1.json b/packages/security_detection_engine/kibana/security_rule/1b65429e-bd92-44c0-aff8-e8065869d860_1.json new file mode 100644 index 00000000000..526cdf5adaf --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/1b65429e-bd92-44c0-aff8-e8065869d860_1.json @@ -0,0 +1,122 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects execution of bpftool commands used to detach eBPF programs or links, or to delete or modify eBPF maps. These actions can disable, alter, or interfere with kernel-level instrumentation and enforcement mechanisms implemented through eBPF. In environments relying on eBPF-based networking, observability, or security controls, unexpected use of these operations may indicate defense evasion or runtime tampering.", + "from": "now-9m", + "index": [ + "auditbeat-*", + "endgame-*", + "logs-auditd_manager.auditd-*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", + "logs-crowdstrike.fdr*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "BPF Program Tampering via bpftool", + "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 BPF Program Tampering via bpftool\n\nThis rule detects bpftool executions that detach eBPF programs/links or delete/update eBPF maps, actions that can silently disable kernel-level visibility and enforcement built on eBPF. Attackers use these operations to evade detection or weaken runtime controls by removing loaded probes or rewriting map contents that drive policy decisions. A common pattern is running bpftool to detach a program from a hook or detach a link shortly before other suspicious activity.\n\n### Possible investigation steps\n\n- Pull the full bpftool command line and correlate it with the invoking user, session (TTY/SSH), parent process chain, and any preceding privilege escalation to determine whether it was interactive admin work or automated tampering. \n- Capture current eBPF state (`bpftool prog show`, `bpftool link show`, `bpftool map show -j`) and compare with recent snapshots/logs to identify which program/link/map changed and what controls (sensor, CNI, LSM, XDP/TC) may have been impacted. \n- Identify the affected attachment point by mapping the detached program/link ID to its hook (e.g., tc/xdp/cgroup/tracepoint/kprobe) and validate operational impact by checking for missing telemetry, policy gaps, or network behavior changes around the event time. \n- Review audit/system logs and package history for installation or recent execution of bpftool, kernel/debug tooling, or custom eBPF loaders, and look for nearby suspicious binaries/scripts that could be orchestrating repeated detach/update actions. \n- If malicious activity is suspected, preserve artifacts by exporting bpftool JSON output and relevant `/sys/fs/bpf` entries, then hunt for follow-on persistence or rootkit-like behavior (new eBPF loads, altered maps, hidden processes, unexpected kernel module activity) on the host.\n\n### False positive analysis\n\n- A system administrator or SRE running bpftool during incident response or troubleshooting may detach a program/link or update/delete a map to temporarily disable an eBPF hook and validate whether it is causing network drops, performance regressions, or incorrect enforcement.\n- A maintenance workflow during kernel, CNI, or eBPF policy rollouts may use bpftool to detach and replace existing attachments or refresh map entries as part of a controlled upgrade/rollback, especially when reloading pinned objects under `/sys/fs/bpf`.\n\n### Response and remediation\n\n- Contain by isolating the host from the network or restricting outbound access while preserving access for forensics if bpftool detach/map operations are unexpected or coincide with loss of eBPF-based enforcement/telemetry. \n- Eradicate by stopping and removing the controlling process/script (inspect the bpftool parent chain and cron/systemd units), revoking the initiating account\u2019s sudo/root access, and deleting any unauthorized pinned objects under `/sys/fs/bpf` after exporting them for evidence. \n- Recover by reloading the approved eBPF components (agent/CNI/LSM/XDP/TC) from trusted packages or images, reattaching required programs/links, and restoring known-good map contents from backups or redeploying policy to repopulate maps. \n- Escalate to incident response and platform owners immediately if repeated bpftool tampering persists after containment, you find unknown pinned maps/programs with suspicious names/owners, or multiple hosts show simultaneous detach/update activity. \n- Harden by limiting bpftool availability (remove from production images where not needed), enforcing least-privilege on CAP_BPF/CAP_SYS_ADMIN and sudoers, and adding immutable monitoring of `/usr/sbin/bpftool` and `/sys/fs/bpf` plus periodic snapshots of `bpftool prog/link/map show` for drift detection.", + "query": "process where host.os.type == \"linux\" and event.type == \"start\" and\nevent.action in (\"exec\", \"exec_event\", \"start\", \"ProcessRollup2\", \"executed\", \"process_started\") and\nprocess.name == \"bpftool\" and (\n (process.args == \"prog\" and process.args == \"detach\") or\n (process.args == \"map\" and process.args in (\"delete\", \"update\")) or\n (process.args == \"link\" and process.args == \"detach\")\n)\n", + "references": [ + "https://manpages.ubuntu.com/manpages/jammy/man8/bpftool-prog.8.html", + "https://manpages.ubuntu.com/manpages/noble/man8/bpftool-map.8.html", + "https://man.archlinux.org/man/bpftool-link.8.en" + ], + "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": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.args", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "1b65429e-bd92-44c0-aff8-e8065869d860", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Threat: Rootkit", + "Data Source: Elastic Endgame", + "Data Source: Elastic Defend", + "Data Source: Auditd Manager", + "Data Source: SentinelOne", + "Data Source: Crowdstrike", + "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": "T1014", + "name": "Rootkit", + "reference": "https://attack.mitre.org/techniques/T1014/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 1 + }, + "id": "1b65429e-bd92-44c0-aff8-e8065869d860_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/1bb329a5-2168-4da5-b7b9-d42a51deb6dd_1.json b/packages/security_detection_engine/kibana/security_rule/1bb329a5-2168-4da5-b7b9-d42a51deb6dd_1.json new file mode 100644 index 00000000000..bae86f26af0 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/1bb329a5-2168-4da5-b7b9-d42a51deb6dd_1.json @@ -0,0 +1,138 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule correlates alerts from multiple integrations and event categories that involve different user.name values which may represent the same real-world identity. It uses an LLM-based similarity analysis to evaluate whether multiple user identifiers (e.g. naming variations, formats, aliases, or domain differences) likely belong to the same person.", + "from": "now-60m", + "interval": "30m", + "language": "esql", + "license": "Elastic License v2", + "name": "Correlated Alerts on Similar User Identities", + "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, analysts should validate findings against their environment and identity architecture.\n\n### Investigating Correlated Alerts on Similar User Identities\n\nThis rule identifies alerts from multiple integrations and event categories involving different `user.name` values that may represent the same real-world identity.\nAn LLM is used to assess string similarity and naming patterns to determine whether multiple user identifiers likely belong to the same person, which may indicate account compromise, credential abuse, or identity misuse across systems.\n\n### Possible investigation steps\n\n- Review the correlated `user.name` values and validate whether they represent naming variations, aliases, or identity mappings.\n- Examine the LLM output fields (`verdict`, `confidence`, `summary`) as decision support, not ground truth.\n- Analyze the diversity of alert sources, event categories, and detection rules involved.\n- Reconstruct the alert timeline to identify potential stages such as initial access, lateral movement, privilege escalation, or persistence.\n- Correlate with authentication logs, IAM/SSO telemetry, EDR data, and network logs to identify shared sessions, IPs, devices, or hosts.\n- Validate identities against directory services, identity providers, and federation mappings.\n\n### False positive analysis\n\n- Identity format variations across systems (e.g., `first.last`, `flast`, `user@domain`).\n- Federated identity mappings between on-prem, cloud, and SaaS platforms.\n- Service, automation, and CI/CD accounts with similar naming conventions.\n- Separate admin and standard user accounts for the same individual.\n- Shared credentials or naming templates in development and test environments.\n\n### Response and remediation\n\n- Temporarily disable or suspend correlated accounts if compromise is suspected.\n- Revoke active sessions, tokens, and credentials.\n- Investigate access scope, privileges, and lateral movement paths.\n- Perform endpoint and identity forensics to identify persistence mechanisms.\n- Remediate IAM misconfigurations and federation issues.\n- Enhance monitoring for identity correlation, credential misuse, and cross-platform abuse..", + "query": "from .alerts-security.*\n\n// truncate timestamp to 5-minute window\n| eval Esql.time_window_date_trunc = date_trunc(5 minutes, @timestamp)\n\n// high severity alerts excluding system standard user.ids\n| where kibana.alert.rule.name is not null and user.name is not null and kibana.alert.risk_score >= 73 and kibana.alert.workflow_status == \"open\" and \n not kibana.alert.rule.type in (\"threat_match\", \"machine_learning\") and\n not user.id in (\"S-1-5-18\", \"S-1-5-19\", \"S-1-5-20\", \"0\")\n\n// group alerts by short time window and extract values of interest for alert triage\n| stats Esql.event_module_distinct_count = COUNT_DISTINCT(event.module),\n Esql.user_name_distinct_count = COUNT_DISTINCT(user.name),\n Esql.rule_name_distinct_count = COUNT_DISTINCT(kibana.alert.rule.name),\n Esql.event_category_distinct_count = COUNT_DISTINCT(event.category),\n Esql.rule_risk_score_distinct_count = COUNT_DISTINCT(kibana.alert.risk_score),\n Esql.event_module_values = VALUES(event.module),\n Esql.rule_name_values = VALUES(kibana.alert.rule.name),\n Esql.message_values = VALUES(message),\n Esql.event_category_values = VALUES(event.category),\n Esql.event_action_values = VALUES(event.action),\n Esql.source_ip_values = VALUES(source.ip),\n Esql.destination_ip_values = VALUES(destination.ip),\n Esql.host_id_values = VALUES(host.id),\n Esql.agent_id_values = VALUES(agent.id),\n Esql.rule_severity_values = VALUES(kibana.alert.risk_score),\n Esql.user_name_values = VALUES(user.name) by Esql.time_window_date_trunc\n\n// filter for alerts from different integrations with unique categories\n| where Esql.event_module_distinct_count >= 2 and Esql.user_name_distinct_count >= 2 and Esql.event_category_distinct_count >= 2\n\n// build context for LLM analysis\n| eval users_list = MV_CONCAT(Esql.user_name_values, \",\")\n\n// LLM analysis\n| eval instructions = \"Analyze the provided user names and return a boolean value true if at least 2 of them are similar and they may belong to the same human identify or false if not, do not compare user names that may look like service accounts. If the list of users has more than 2 users and only 2 of them are similar consider this as true. Structure the output as follows: verdict= confidence= summary= without any other response statements on a single line.\"\n| eval prompt = CONCAT(\"User identities extracted from different alerts: \", users_list, instructions)\n| COMPLETION triage_result = prompt WITH { \"inference_id\": \".gp-llm-v2-completion\"}\n\n// parse LLM response\n| DISSECT triage_result \"\"\"verdict=%{Esql.verdict} confidence=%{Esql.confidence} summary=%{Esql.summary}\"\"\"\n\n// filter for similar user values\n| where TO_LOWER(Esql.verdict) == \"true\"\n| keep Esql.*\n", + "references": [ + "https://www.elastic.co/docs/reference/query-languages/esql/esql-commands#esql-completion", + "https://www.elastic.co/security-labs/elastic-advances-llm-security" + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.agent_id_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.confidence", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.destination_ip_values", + "type": "ip" + }, + { + "ecs": false, + "name": "Esql.event_action_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.event_category_distinct_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.event_category_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.event_module_distinct_count", + "type": "long" + }, + { + "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_distinct_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.rule_name_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.rule_risk_score_distinct_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.rule_severity_values", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.source_ip_values", + "type": "ip" + }, + { + "ecs": false, + "name": "Esql.summary", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.time_window_date_trunc", + "type": "date" + }, + { + "ecs": false, + "name": "Esql.user_name_distinct_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.user_name_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.verdict", + "type": "keyword" + } + ], + "risk_score": 73, + "rule_id": "1bb329a5-2168-4da5-b7b9-d42a51deb6dd", + "setup": "## Setup\n\n### LLM Configuration\n\nThis rule uses the ES|QL COMPLETION command with Elastic's managed General Purpose LLM v2 (`.gp-llm-v2-completion`),\nwhich is available out-of-the-box in Elastic Cloud deployments with an appropriate subscription.\n\nTo use a different LLM provider (Azure OpenAI, Amazon Bedrock, OpenAI, or Google Vertex), configure a connector\nfollowing the [LLM connector documentation](https://www.elastic.co/docs/explore-analyze/ai-features/llm-guides/llm-connectors)\nand update the `inference_id` parameter in the query to reference your configured connector.\n", + "severity": "high", + "tags": [ + "Domain: Identity", + "Domain: LLM", + "Use Case: Threat Detection", + "Use Case: Identity and Access Audit", + "Resources: Investigation Guide", + "Rule Type: Higher-Order Rule" + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 1 + }, + "id": "1bb329a5-2168-4da5-b7b9-d42a51deb6dd_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/1d9aeb0b-9549-46f6-a32d-05e2a001b7fd_112.json b/packages/security_detection_engine/kibana/security_rule/1d9aeb0b-9549-46f6-a32d-05e2a001b7fd_112.json new file mode 100644 index 00000000000..9d27333bcd2 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/1d9aeb0b-9549-46f6-a32d-05e2a001b7fd_112.json @@ -0,0 +1,111 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies PowerShell script block content that uses .NET cryptography APIs for file encryption or decryption. Attackers abuse these routines to encrypt data for impact or decrypt staged payloads to evade defenses.", + "false_positives": [ + "Legitimate PowerShell Scripts which makes use of encryption." + ], + "from": "now-9m", + "index": [ + "winlogbeat-*", + "logs-windows.powershell*" + ], + "investigation_fields": { + "field_names": [ + "@timestamp", + "user.name", + "user.id", + "user.domain", + "powershell.file.script_block_text", + "powershell.file.script_block_id", + "powershell.sequence", + "powershell.total", + "file.path", + "file.directory", + "file.name", + "process.pid", + "host.name", + "host.id", + "powershell.file.script_block_length" + ] + }, + "language": "kuery", + "license": "Elastic License v2", + "name": "PowerShell Script with Encryption/Decryption Capabilities", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This guide was created by humans with the assistance of generative AI. While its contents have been manually curated to include the most valuable information, always validate assumptions and adjust procedures to match your internal runbooks and incident triage and response policies.\n\n### Investigating PowerShell Script with Encryption/Decryption Capabilities\n\nThis rule identifies PowerShell script block content that implements cryptographic encryption or decryption using .NET APIs. Matching script blocks commonly include symmetric cryptography classes (for example, AES/Rijndael or the SymmetricAlgorithm base type), key derivation helpers (for example, PasswordDeriveBytes or Rfc2898DeriveBytes), explicit cipher configuration (CipherMode and PaddingMode), and calls that create an encryptor or decryptor.\n\nThis behavior can be legitimate (protecting configuration values, packaging content, or controlled encryption for business workflows). It can also indicate malicious activity such as encrypting local data for impact or decrypting staged content to reduce static visibility before follow-on execution. Prioritize determining what data is being transformed, where outputs are written, and whether the user/host/script origin aligns with expected activity.\n\n#### Key alert fields to review\n\n- `user.name`, `user.domain`, `user.id`: Account execution context for correlation, prioritization, and scoping.\n- `host.name`, `host.id`: Host execution context for correlation, prioritization, and scoping.\n- `powershell.file.script_block_text`: Script block content that matched the detection logic.\n- `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`: Script block metadata to pivot to other fragments or reconstruct full script content when split across multiple events.\n- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file.\n- `powershell.file.script_block_length`: Script block length (size) context.\n\n#### Possible investigation steps\n\n- Review `powershell.file.script_block_text` to understand the cryptographic intent and data flow:\n - Identify whether the logic is primarily encrypting, decrypting, or doing both.\n - Note which cryptographic primitives are used (for example, AES/Rijndael, hashing helpers, and key derivation routines) and how keys/IVs are produced (hard-coded values, derived from passwords, generated randomly, or passed in).\n - Identify the transformed data source and destination:\n - File-oriented operations: look for path construction, directory traversal patterns, repeated read/write loops, file extension changes, renames, or deletion of originals.\n - In-memory operations: look for large embedded blobs, byte arrays, stream usage, or logic that converts decrypted content into executable form or writes it to a new artifact.\n - Extract and preserve any embedded secrets or deterministic derivation parameters (password strings, salts, iteration counts, static IVs, or key material), as these can be critical for impact assessment and recovery.\n\n- Determine whether the alert contains the full implementation or only a fragment:\n - Use `powershell.file.script_block_length` to gauge whether this is a complete routine (larger blocks) versus a wrapper or function invocation (smaller blocks).\n - If the script appears incomplete, pivot on `powershell.file.script_block_id` and use `powershell.sequence` / `powershell.total` to retrieve and order all fragments before concluding intent.\n\n- Validate execution context and provenance:\n - Review `user.name`, `user.domain`, and `user.id` to determine whether this account typically performs encryption/decryption tasks and whether the account scope matches the host role.\n - Review `host.name` and `host.id` to determine asset criticality and whether similar activity is expected on this system (for example, administrative hosts may have more automation than standard endpoints).\n - If `file.path` / `file.name` is present, evaluate whether the script origin is expected:\n - Compare the path and name to approved automation locations and naming conventions.\n - Treat unexpected paths, user-writable directories, or newly observed script locations as higher risk.\n\n- Scope the activity using alert fields:\n - On the same host, search for additional script blocks tied to the same `powershell.file.script_block_id` to find related functions or setup code not visible in the initial alert fragment.\n - Search across hosts for repeating patterns in `powershell.file.script_block_text` and for the same `file.name` to determine whether this is a widely deployed administrative script or isolated activity.\n - Pivot on `user.id` to identify whether similar script blocks appear on multiple hosts, which may indicate coordinated activity.\n\n- Correlate with adjacent telemetry around `@timestamp` for the same `host.id` and `user.id` (if available in your environment):\n - Process execution telemetry to identify the PowerShell host process and what initiated it, helping distinguish interactive use from automation or remotely initiated activity.\n - File activity telemetry to identify bursts of file modifications/creations consistent with bulk encryption/decryption and to determine which directories and file types were affected.\n - Network telemetry to identify connections that could support retrieval of encrypted content, exchange of key material, or staging/downloading of additional payloads.\n - Authentication telemetry to identify unusual logons or session types for the user preceding execution.\n\n- Determine disposition and urgency:\n - Treat as higher severity if the script indicates broad file processing, writes many outputs, modifies user data locations, or includes embedded key material/blobs associated with staged content.\n - Treat as lower severity if the script is clearly tied to approved operations, originates from a known `file.path`, is executed by expected accounts, and shows consistent recurrence patterns with expected scope.\n\n### False positive analysis\n\n- Legitimate PowerShell automation may implement encryption/decryption for secure configuration handling, packaging, data protection, or interoperability with other systems.\n- Benign activity is more likely to have consistent `file.path` / `file.name` values, execute under expected administrative accounts, and recur on appropriate hosts with stable script content.\n- If the script is determined to be benign, document what data it protects, where it is expected to run, which accounts execute it, and what normal recurrence looks like to reduce future triage time.\n\n### Response and remediation\n\n- If the activity is suspicious or malicious:\n - Contain the host to prevent further encryption/decryption activity and reduce the risk of spread or data impact.\n - Preserve evidence from the alert, including the full `powershell.file.script_block_text` and any reconstructed fragments correlated via `powershell.file.script_block_id`.\n - If `file.path` is present, collect the referenced script from disk and preserve it for forensic review and scoping.\n - Identify impacted systems and data:\n - If file-impact is suspected, prioritize backup protection, incident response escalation, and recovery planning.\n - If payload staging is suspected, prioritize identifying the decrypted output or follow-on execution artifacts.\n - Scope and hunt across the environment for related activity using `user.id`, `host.id`, recurring `file.name`, and distinctive fragments of `powershell.file.script_block_text`.\n - Remediate the associated account and access path: validate legitimacy, reset credentials if compromise is suspected, and apply least-privilege controls where appropriate.\n - Remove or block the identified script and any related artifacts discovered during analysis, and monitor for recurrence.\n\n- If the activity is confirmed benign:\n - Record the expected `file.path` / `file.name`, the responsible `user.id`, and normal execution patterns to support consistent future triage and tuning decisions.\n", + "query": "event.category:process and host.os.type:windows and\n powershell.file.script_block_text : (\n (\n \"Cryptography.AESManaged\" or\n \"Cryptography.RijndaelManaged\" or\n \"Cryptography.SHA1Managed\" or\n \"Cryptography.SHA256Managed\" or\n \"Cryptography.SHA384Managed\" or\n \"Cryptography.SHA512Managed\" or\n \"Cryptography.SymmetricAlgorithm\" or\n \"PasswordDeriveBytes\" or\n \"Rfc2898DeriveBytes\"\n ) and\n (\n CipherMode and PaddingMode\n ) and\n (\n \".CreateEncryptor\" or\n \".CreateDecryptor\"\n )\n ) and\n not user.id : \"S-1-5-18\" and\n not (\n file.name : \"Bootstrap.Octopus.FunctionAppenderContext.ps1\" and\n powershell.file.script_block_text : (\"function Decrypt-Variables\" or \"github.com/OctopusDeploy\")\n )\n", + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.category", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_text", + "type": "unknown" + }, + { + "ecs": true, + "name": "user.id", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "1d9aeb0b-9549-46f6-a32d-05e2a001b7fd", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: PowerShell Logs", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1027", + "name": "Obfuscated Files or Information", + "reference": "https://attack.mitre.org/techniques/T1027/" + }, + { + "id": "T1140", + "name": "Deobfuscate/Decode Files or Information", + "reference": "https://attack.mitre.org/techniques/T1140/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 112 + }, + "id": "1d9aeb0b-9549-46f6-a32d-05e2a001b7fd_112", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/1dd99dbf-b98d-4956-876b-f13bc0ce017f_2.json b/packages/security_detection_engine/kibana/security_rule/1dd99dbf-b98d-4956-876b-f13bc0ce017f_2.json new file mode 100644 index 00000000000..99793ad5a88 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/1dd99dbf-b98d-4956-876b-f13bc0ce017f_2.json @@ -0,0 +1,105 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule uses alert data to determine when multiple alerts from different integrations with unique event categories and involving the same user.name are triggered. Analysts can use this to prioritize triage and response, as these users are more likely to be compromised.", + "from": "now-60m", + "interval": "30m", + "language": "esql", + "license": "Elastic License v2", + "name": "Alerts From Multiple Integrations by 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 Alerts From Multiple Integrations by User Name\n\nThe detection rule uses alert data to determine when multiple alerts from different integrations involving the same user.name are triggered.\n\n### Possible investigation steps\n\n- Review the alert details to identify the specific user involved and the different modules and rules that triggered the alert.\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.*\n\n// any alerts excluding low severity and the noisy ones\n| where kibana.alert.rule.name is not null and user.name is not null and kibana.alert.risk_score > 21 and\n not kibana.alert.rule.type in (\"threat_match\", \"machine_learning\") and \n not user.id in (\"S-1-5-18\", \"S-1-5-19\", \"S-1-5-20\", \"0\") and\n not KQL(\"\"\"kibana.alert.rule.tags : \"Rule Type: Higher-Order Rule\" \"\"\") and\n // Top noisy influencing rules\n // Agent Spoofing - Mismatched Agent ID\n // Compression DLL Loaded by Unusual Process\n // Process Termination followed by Deletion \n // Suspicious PrintSpooler Service Executable File Creation\n // Potential PrintNightmare File Modification\n // Multiple Vault Web Credentials Read\n // Machine Learning Detected a Suspicious Windows Event with a High Malicious Probability Score\n not kibana.alert.rule.rule_id in (\"3115bd2c-0baa-4df0-80ea-45e474b5ef93\", \"d197478e-39f0-4347-a22f-ba654718b148\", \"09443c92-46b3-45a4-8f25-383b028b258d\", \"5bb4a95d-5a08-48eb-80db-4c3a63ec78a8\", \"5e87f165-45c2-4b80-bfa5-52822552c997\", \"44fc462c-1159-4fa8-b1b7-9b6296ab4f96\", \"994e40aa-8c85-43de-825e-15f665375ee8\")\n \n// group alerts by user.name and extract values of interest for alert triage\n| stats Esql.event_module_distinct_count = COUNT_DISTINCT(event.module),\n Esql.rule_name_distinct_count = COUNT_DISTINCT(kibana.alert.rule.name),\n Esql.event_category_distinct_count = COUNT_DISTINCT(event.category),\n Esql.rule_risk_score_distinct_count = COUNT_DISTINCT(kibana.alert.risk_score),\n Esql.event_module_values = VALUES(event.module),\n Esql.rule_name_values = VALUES(kibana.alert.rule.name),\n Esql.message_values = VALUES(message),\n Esql.event_category_values = VALUES(event.category),\n Esql.event_action_values = VALUES(event.action),\n Esql.source_ip_values = VALUES(source.ip),\n Esql.destination_ip_values = VALUES(destination.ip),\n Esql.host_id_values = VALUES(host.id),\n Esql.agent_id_values = VALUES(agent.id),\n Esql.rule_severity_values = VALUES(kibana.alert.risk_score) by user.name, user.id\n\n// filter for alerts from same destination.ip reported by different integrations with unique categories and with different severity levels\n| where Esql.event_module_distinct_count >= 2 and Esql.event_category_distinct_count >= 2 and (Esql.rule_risk_score_distinct_count >= 2 or Esql.rule_severity_values == 73 or Esql.rule_severity_values == 99)\n| keep user.name, Esql.*\n", + "required_fields": [ + { + "ecs": false, + "name": "Esql.agent_id_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.destination_ip_values", + "type": "ip" + }, + { + "ecs": false, + "name": "Esql.event_action_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.event_category_distinct_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.event_category_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.event_module_distinct_count", + "type": "long" + }, + { + "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_distinct_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.rule_name_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.rule_risk_score_distinct_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.rule_severity_values", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.source_ip_values", + "type": "ip" + }, + { + "ecs": true, + "name": "user.name", + "type": "keyword" + } + ], + "risk_score": 73, + "rule_id": "1dd99dbf-b98d-4956-876b-f13bc0ce017f", + "severity": "high", + "tags": [ + "Use Case: Threat Detection", + "Rule Type: Higher-Order Rule", + "Resources: Investigation Guide" + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 2 + }, + "id": "1dd99dbf-b98d-4956-876b-f13bc0ce017f_2", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/1e0a3f7c-21e7-4bb1-98c7-2036612fb1be_214.json b/packages/security_detection_engine/kibana/security_rule/1e0a3f7c-21e7-4bb1-98c7-2036612fb1be_214.json new file mode 100644 index 00000000000..abf4c9e788a --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/1e0a3f7c-21e7-4bb1-98c7-2036612fb1be_214.json @@ -0,0 +1,302 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "building_block_type": "default", + "description": "Identifies the use of Cmdlets and methods related to discovery activities. Attackers can use these to perform various situational awareness related activities, like enumerating users, shares, sessions, domain trusts, groups, etc.", + "filters": [ + { + "meta": { + "negate": true + }, + "query": { + "wildcard": { + "file.path": { + "case_insensitive": true, + "value": "?:\\\\Program Files\\\\WindowsPowerShell\\\\Modules\\\\*.ps?1" + } + } + } + }, + { + "meta": { + "negate": true + }, + "query": { + "wildcard": { + "file.path": { + "case_insensitive": true, + "value": "?:\\\\Program Files\\\\Microsoft Azure AD Sync\\\\Extensions\\\\AADConnector.psm1" + } + } + } + }, + { + "meta": { + "negate": true + }, + "query": { + "wildcard": { + "file.path": { + "case_insensitive": true, + "value": "*ServiceNow MID Server*\\\\agent\\\\scripts\\\\PowerShell\\\\*.psm1" + } + } + } + }, + { + "meta": { + "negate": true + }, + "query": { + "wildcard": { + "file.path": { + "case_insensitive": true, + "value": "?:\\\\Windows\\\\IMECache\\\\HealthScripts\\\\*\\\\detect.ps1" + } + } + } + }, + { + "meta": { + "negate": true + }, + "query": { + "wildcard": { + "file.path": { + "case_insensitive": true, + "value": "?:\\\\Windows\\\\TEMP\\\\SDIAG*" + } + } + } + }, + { + "meta": { + "negate": true + }, + "query": { + "wildcard": { + "file.path": { + "case_insensitive": true, + "value": "?:\\\\Temp\\\\SDIAG*" + } + } + } + }, + { + "meta": { + "negate": true + }, + "query": { + "wildcard": { + "file.path": { + "case_insensitive": true, + "value": "?:\\\\Users\\\\*\\\\AppData\\\\Local\\\\Temp\\\\SDIAG*" + } + } + } + }, + { + "meta": { + "negate": true + }, + "query": { + "wildcard": { + "file.path": { + "case_insensitive": true, + "value": "?:\\\\Program Files\\\\Microsoft Monitoring Agent\\\\Agent\\\\Health Service State\\\\Monitoring Host Temporary Files*" + } + } + } + }, + { + "meta": { + "negate": true + }, + "query": { + "wildcard": { + "file.path": { + "case_insensitive": true, + "value": "?:\\\\ProgramData\\\\Microsoft\\\\Windows Defender Advanced Threat Protection\\\\DataCollection\\\\*" + } + } + } + } + ], + "from": "now-119m", + "index": [ + "winlogbeat-*", + "logs-windows.powershell*" + ], + "interval": "60m", + "language": "kuery", + "license": "Elastic License v2", + "name": "Deprecated - PowerShell Script with Discovery Capabilities", + "query": "event.category:process and host.os.type:windows and\n powershell.file.script_block_text : (\n (\n \"Get-ADDefaultDomainPasswordPolicy\" or\n \"Get-ADDomain\" or \"Get-ComputerInfo\" or\n \"Get-Disk\" or \"Get-DnsClientCache\" or\n \"Get-GPOReport\" or \"Get-HotFix\" or\n \"Get-LocalUser\" or \"Get-NetFirewallProfile\" or\n \"get-nettcpconnection\" or \"Get-NetAdapter\" or\n \"Get-PhysicalDisk\" or \"Get-Process\" or\n \"Get-PSDrive\" or \"Get-Service\" or\n \"Get-SmbShare\" or \"Get-WinEvent\"\n ) or\n (\n (\"Get-WmiObject\" or \"gwmi\" or \"Get-CimInstance\" or\n \"gcim\" or \"Management.ManagementObjectSearcher\" or\n \"System.Management.ManagementClass\" or\n \"[WmiClass]\") and\n (\n \"AntiVirusProduct\" or \"CIM_BIOSElement\" or \"CIM_ComputerSystem\" or \"CIM_Product\" or \"CIM_DiskDrive\" or\n \"CIM_LogicalDisk\" or \"CIM_NetworkAdapter\" or \"CIM_StorageVolume\" or \"CIM_OperatingSystem\" or\n \"CIM_Process\" or \"CIM_Service\" or \"MSFT_DNSClientCache\" or \"Win32_BIOS\" or \"Win32_ComputerSystem\" or\n \"Win32_ComputerSystemProduct\" or \"Win32_DiskDrive\" or \"win32_environment\" or \"Win32_Group\" or\n \"Win32_groupuser\" or \"Win32_IP4RouteTable\" or \"Win32_logicaldisk\" or \"Win32_MappedLogicalDisk\" or\n \"Win32_NetworkAdapterConfiguration\" or \"win32_ntdomain\" or \"Win32_OperatingSystem\" or\n \"Win32_PnPEntity\" or \"Win32_Process\" or \"Win32_Product\" or \"Win32_quickfixengineering\" or\n \"win32_service\" or \"Win32_Share\" or \"Win32_UserAccount\"\n )\n ) or\n (\n (\"ADSI\" and \"WinNT\") or\n (\"Get-ChildItem\" and \"sysmondrv.sys\") or\n (\"::GetIPGlobalProperties()\" and \"GetActiveTcpConnections()\") or\n (\"ServiceProcess.ServiceController\" and \"::GetServices\") or\n (\"Diagnostics.Process\" and \"::GetProcesses\") or\n (\"DirectoryServices.Protocols.GroupPolicy\" and \".GetGPOReport()\") or\n (\"DirectoryServices.AccountManagement\" and \"PrincipalSearcher\") or\n (\"NetFwTypeLib.NetFwMgr\" and \"CurrentProfile\") or\n (\"NetworkInformation.NetworkInterface\" and \"GetAllNetworkInterfaces\") or\n (\"Automation.PSDriveInfo\") or\n (\"Microsoft.Win32.RegistryHive\")\n ) or\n (\n \"Get-ItemProperty\" and\n (\n \"\\Control\\SecurityProviders\\WDigest\" or\n \"\\microsoft\\windows\\currentversion\\explorer\\runmru\" or\n \"\\Microsoft\\Windows\\CurrentVersion\\Policies\\System\\Kerberos\\Parameters\" or\n \"\\Microsoft\\Windows\\CurrentVersion\\Uninstall\" or\n \"\\Microsoft\\Windows\\WindowsUpdate\" or\n \"Policies\\Microsoft\\Windows\\Installer\" or\n \"Software\\Microsoft\\Windows\\CurrentVersion\\Policies\" or\n (\"\\Services\\SharedAccess\\Parameters\\FirewallPolicy\" and \"EnableFirewall\") or\n (\"Microsoft\\Windows\\CurrentVersion\\Internet Settings\" and \"proxyEnable\")\n )\n ) or\n (\n (\"Directoryservices.Activedirectory\" or\n \"DirectoryServices.AccountManagement\") and \n (\n \"Domain Admins\" or \"DomainControllers\" or\n \"FindAllGlobalCatalogs\" or \"GetAllTrustRelationships\" or\n \"GetCurrentDomain\" or \"GetCurrentForest\"\n ) or\n \"DirectoryServices.DirectorySearcher\" and\n (\n \"samAccountType=805306368\" or\n \"samAccountType=805306369\" or\n \"objectCategory=group\" or\n \"objectCategory=groupPolicyContainer\" or\n \"objectCategory=site\" or\n \"objectCategory=subnet\" or\n \"objectClass=trustedDomain\"\n )\n ) or\n (\n \"Get-Process\" and\n (\n \"mcshield\" or \"windefend\" or \"savservice\" or\n \"TMCCSF\" or \"symantec antivirus\" or\n \"CSFalcon\" or \"TmPfw\" or \"kvoop\"\n )\n )\n ) and\n not powershell.file.script_block_text : (\n (\n \"__cmdletization_BindCommonParameters\" and\n \"Microsoft.PowerShell.Core\\Export-ModuleMember\" and\n \"Microsoft.PowerShell.Cmdletization.Cim.CimCmdletAdapter\"\n ) or\n \"CmdletsToExport=@(\\\"Add-Content\\\",\" or\n (\"cmdletization\" and \"cdxml-Help.xml\")\n ) and\n not user.id : (\"S-1-5-18\" or \"S-1-5-19\" or \"S-1-5-20\")\n", + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.category", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_text", + "type": "unknown" + }, + { + "ecs": true, + "name": "user.id", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "1e0a3f7c-21e7-4bb1-98c7-2036612fb1be", + "setup": "## Setup\n\nPowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104).\nSetup instructions: https://ela.st/powershell-logging-setup\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Collection", + "Tactic: Discovery", + "Data Source: PowerShell Logs", + "Rule Type: BBR" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0007", + "name": "Discovery", + "reference": "https://attack.mitre.org/tactics/TA0007/" + }, + "technique": [ + { + "id": "T1007", + "name": "System Service Discovery", + "reference": "https://attack.mitre.org/techniques/T1007/" + }, + { + "id": "T1012", + "name": "Query Registry", + "reference": "https://attack.mitre.org/techniques/T1012/" + }, + { + "id": "T1049", + "name": "System Network Connections Discovery", + "reference": "https://attack.mitre.org/techniques/T1049/" + }, + { + "id": "T1057", + "name": "Process Discovery", + "reference": "https://attack.mitre.org/techniques/T1057/" + }, + { + "id": "T1082", + "name": "System Information Discovery", + "reference": "https://attack.mitre.org/techniques/T1082/" + }, + { + "id": "T1082", + "name": "System Information Discovery", + "reference": "https://attack.mitre.org/techniques/T1082/" + }, + { + "id": "T1083", + "name": "File and Directory Discovery", + "reference": "https://attack.mitre.org/techniques/T1083/" + }, + { + "id": "T1087", + "name": "Account Discovery", + "reference": "https://attack.mitre.org/techniques/T1087/", + "subtechnique": [ + { + "id": "T1087.001", + "name": "Local Account", + "reference": "https://attack.mitre.org/techniques/T1087/001/" + }, + { + "id": "T1087.002", + "name": "Domain Account", + "reference": "https://attack.mitre.org/techniques/T1087/002/" + } + ] + }, + { + "id": "T1135", + "name": "Network Share Discovery", + "reference": "https://attack.mitre.org/techniques/T1135/" + }, + { + "id": "T1201", + "name": "Password Policy Discovery", + "reference": "https://attack.mitre.org/techniques/T1201/" + }, + { + "id": "T1482", + "name": "Domain Trust Discovery", + "reference": "https://attack.mitre.org/techniques/T1482/" + }, + { + "id": "T1518", + "name": "Software Discovery", + "reference": "https://attack.mitre.org/techniques/T1518/", + "subtechnique": [ + { + "id": "T1518.001", + "name": "Security Software Discovery", + "reference": "https://attack.mitre.org/techniques/T1518/001/" + } + ] + }, + { + "id": "T1615", + "name": "Group Policy Discovery", + "reference": "https://attack.mitre.org/techniques/T1615/" + } + ] + }, + { + "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": "query", + "version": 214 + }, + "id": "1e0a3f7c-21e7-4bb1-98c7-2036612fb1be_214", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/2339f03c-f53f-40fa-834b-40c5983fc41f_216.json b/packages/security_detection_engine/kibana/security_rule/2339f03c-f53f-40fa-834b-40c5983fc41f_216.json new file mode 100644 index 00000000000..77bb9c7c523 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/2339f03c-f53f-40fa-834b-40c5983fc41f_216.json @@ -0,0 +1,152 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects the use of the insmod binary to load a Linux kernel object file. Threat actors can use this binary, given they have root privileges, to load a rootkit on a system providing them with complete control and the ability to hide from security products. Manually loading a kernel module in this manner should not be at all common and can indicate suspicious or malicious behavior.", + "from": "now-9m", + "index": [ + "auditbeat-*", + "endgame-*", + "logs-auditd_manager.auditd-*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", + "logs-crowdstrike.fdr*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Kernel Module Load via Built-in Utility", + "note": "## Triage and analysis\n\n### Investigating Kernel Module Load via Built-in Utility\n\nThreat actors with root privileges may abuse pre-installed binaries to load loadable kernel modules (LKMs), which are object files that extend the functionality of the kernel. \n\nThreat actors can abuse this utility to load rootkits, granting them full control over the system and the ability to evade security products.\n\nThe detection rule 'Kernel Module Load via Built-in Utility' is designed to identify instances where these binaries are used to load a kernel object file (with a .ko extension) on a Linux system. This activity is uncommon and may indicate suspicious or malicious 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> This investigation guide uses [placeholder fields](https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html) to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run.\n\n### Possible investigation steps\n\n- Investigate the kernel object file that was loaded.\n - !{osquery{\"label\":\"Osquery - Retrieve Running Processes by User\",\"query\":\"SELECT pid, username, name FROM processes p JOIN users u ON u.uid = p.uid ORDER BY username\"}}\n- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence and whether they are located in expected locations.\n - !{osquery{\"label\":\"Osquery - Retrieve Listening Ports\",\"query\":\"SELECT pid, address, port, socket, protocol, path FROM listening_ports\"}}\n- Investigate the kernel ring buffer for any warnings or messages, such as tainted or out-of-tree kernel module loads through `dmesg`.\n- Investigate syslog for any unusual segfaults or other messages. Rootkits may be installed on targets with different architecture as expected, and could potentially cause segmentation faults. \n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Validate the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations.\n- Investigate whether the altered scripts call other malicious scripts elsewhere on the file system. \n - If scripts or executables were dropped, retrieve the files and determine if they are malicious:\n - Use a private sandboxed malware analysis system to perform analysis.\n - Observe and collect information about the following activities:\n - Attempts to contact external domains and addresses.\n - Check if the domain is newly registered or unexpected.\n - Check the reputation of the domain or IP address.\n - File access, modification, and creation activities.\n- Investigate abnormal behaviors by the subject process/user such as network connections, file modifications, and any other spawned child processes.\n - Investigate listening ports and open sockets to look for potential command and control traffic or data exfiltration.\n - !{osquery{\"label\":\"Osquery - Retrieve Open Sockets\",\"query\":\"SELECT pid, family, remote_address, remote_port, socket, state FROM process_open_sockets\"}}\n - !{osquery{\"label\":\"Osquery - Retrieve Information for a Specific User\",\"query\":\"SELECT * FROM users WHERE username = {{user.name}}\"}}\n - Identify the user account that performed the action, analyze it, and check whether it should perform this kind of action.\n - !{osquery{\"label\":\"Osquery - Investigate the Account Authentication Status\",\"query\":\"SELECT * FROM logged_in_users WHERE user = {{user.name}}\"}}\n- Investigate whether the user is currently logged in and active.\n - $osquery_6\n\n### False positive analysis\n\n- If this activity is related to new benign software installation activity, consider adding exceptions \u2014 preferably with a combination of user and command line conditions.\n- If this activity is related to a system administrator who uses cron jobs for administrative purposes, consider adding exceptions for this specific administrator user account. \n- Try to understand the context of the execution by thinking about the user, machine, or business purpose. A small number of endpoints, such as servers with unique software, might appear unusual but satisfy a specific business need.\n\n### Related Rules\n\n- Kernel Driver Load - 3e12a439-d002-4944-bc42-171c0dcb9b96\n- Tainted Out-Of-Tree Kernel Module Load - 51a09737-80f7-4551-a3be-dac8ef5d181a\n- Tainted Kernel Module Load - 05cad2fb-200c-407f-b472-02ea8c9e5e4a\n- Attempt to Clear Kernel Ring Buffer - 2724808c-ba5d-48b2-86d2-0002103df753\n- Enumeration of Kernel Modules via Proc - 80084fa9-8677-4453-8680-b891d3c0c778\n- Suspicious Modprobe File Event - 40ddbcc8-6561-44d9-afc8-eefdbfe0cccd\n- Kernel Module Removal - cd66a5af-e34b-4bb0-8931-57d0a043f2ef\n- Enumeration of Kernel Modules - 2d8043ed-5bda-4caf-801c-c1feb7410504\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- 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- Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).\n", + "query": "process where host.os.type == \"linux\" and event.type == \"start\" and\nevent.action in (\"exec\", \"exec_event\", \"start\", \"ProcessRollup2\", \"executed\", \"process_started\") and (\n (process.name == \"kmod\" and process.args == \"insmod\" and process.args like~ \"*.ko*\") or\n (process.name == \"kmod\" and process.args == \"modprobe\" and not process.args in (\"-r\", \"--remove\")) or\n (process.name == \"insmod\" and process.args like~ \"*.ko*\") or\n (process.name == \"modprobe\" and not process.args in (\"-r\", \"--remove\"))\n) and\nnot (\n ?process.parent.executable like (\"/opt/ds_agent/*\", \"/opt/TrendMicro/vls_agent/*\", \"/opt/intel/oneapi/*\") or\n ?process.working_directory in (\"/opt/vinchin/agent\", \"/var/opt/ds_agent/am\", \"/opt/ds_agent\", \"/var/opt/TrendMicro/vls_agent/am\") or\n ?process.parent.executable in (\n \"/usr/lib/uptrack/ksplice-apply\", \"/opt/commvault/commvault/Base/linux_drv\", \"/opt/cisco/amp/bin/cisco-amp-helper\",\n \"/usr/bin/kcarectl\", \"/usr/share/ksplice/ksplice-apply\", \"/opt/commvault/Base/linux_drv\", \"/usr/sbin/veeamsnap-loader\",\n \"/bin/falcoctl\"\n ) or\n (?process.parent.name like (\"python*\", \"platform-python*\") and ?process.parent.args in (\"--smart-update\", \"--auto-update\"))\n)\n", + "references": [ + "https://decoded.avast.io/davidalvarez/linux-threat-hunting-syslogk-a-kernel-rootkit-found-under-development-in-the-wild/" + ], + "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": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.args", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.args", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.executable", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.working_directory", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "2339f03c-f53f-40fa-834b-40c5983fc41f", + "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: Defense Evasion", + "Threat: Rootkit", + "Data Source: Elastic Endgame", + "Data Source: Elastic Defend", + "Data Source: Auditd Manager", + "Data Source: SentinelOne", + "Data Source: Crowdstrike", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0003", + "name": "Persistence", + "reference": "https://attack.mitre.org/tactics/TA0003/" + }, + "technique": [ + { + "id": "T1547", + "name": "Boot or Logon Autostart Execution", + "reference": "https://attack.mitre.org/techniques/T1547/", + "subtechnique": [ + { + "id": "T1547.006", + "name": "Kernel Modules and Extensions", + "reference": "https://attack.mitre.org/techniques/T1547/006/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1014", + "name": "Rootkit", + "reference": "https://attack.mitre.org/techniques/T1014/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 216 + }, + "id": "2339f03c-f53f-40fa-834b-40c5983fc41f_216", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/23f18264-2d6d-11ef-9413-f661ea17fbce_209.json b/packages/security_detection_engine/kibana/security_rule/23f18264-2d6d-11ef-9413-f661ea17fbce_209.json new file mode 100644 index 00000000000..c7c31cd2faf --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/23f18264-2d6d-11ef-9413-f661ea17fbce_209.json @@ -0,0 +1,180 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects potential brute force attacks against a single Okta user account where excessive unique device token hashes are generated, indicating automated tooling that fails to persist browser cookies between attempts.", + "false_positives": [ + "A user experiencing login issues may generate multiple device tokens through repeated legitimate attempts.", + "Automated testing or monitoring tools that do not persist cookies may trigger this rule." + ], + "from": "now-30m", + "language": "esql", + "license": "Elastic License v2", + "name": "Potential Okta Brute Force (Device Token Rotation)", + "note": "## Triage and analysis\n\n### Investigating Potential Okta Brute Force (Device Token Rotation)\n\nThis rule identifies excessive unique device token hashes generated for a single user account, indicating automated brute force tooling that fails to persist browser cookies between authentication attempts.\n\n#### Possible investigation steps\n- Identify the targeted user account and determine if it has elevated privileges or sensitive access.\n- Review the source IP and check if it belongs to known proxy, VPN, or cloud infrastructure.\n- Examine user agent strings for signs of automation, scripting tools, or inconsistent browser fingerprints.\n- Check if Okta flagged the source as a known threat or proxy.\n- Determine if any authentication attempts succeeded following the failed attempts.\n- Review the user's recent activity for signs of account compromise.\n\n### False positive analysis\n- Users experiencing login issues may generate multiple device tokens through repeated legitimate attempts.\n- Automated testing or monitoring tools that do not persist cookies may trigger this rule.\n- Browser extensions or privacy tools that clear cookies between requests may cause device token rotation.\n\n### Response and remediation\n- If attack is confirmed, reset the user's password immediately.\n- Block the source IP at the network perimeter.\n- Review and potentially reset MFA for the targeted account.\n- Monitor for any successful authentication that may indicate compromise.\n- Contact the user to verify if they experienced legitimate login issues.\n", + "query": "FROM logs-okta.system-* METADATA _id, _version, _index\n| WHERE\n event.dataset == \"okta.system\"\n AND (event.action LIKE \"user.authentication.*\" OR event.action == \"user.session.start\")\n AND okta.outcome.reason IN (\"INVALID_CREDENTIALS\", \"LOCKED_OUT\")\n AND okta.actor.alternate_id IS NOT NULL\n // Primary authn endpoint; sessions API provides additional coverage\n AND (\n okta.debug_context.debug_data.request_uri == \"/api/v1/authn\"\n OR okta.debug_context.debug_data.request_uri LIKE \"/api/v1/sessions*\"\n )\n// Track whether each event has a device token\n| EVAL has_dt_hash = CASE(okta.debug_context.debug_data.dt_hash IS NOT NULL, 1, 0)\n// Aggregate by IP + user to detect single-user brute force\n| STATS\n Esql.unique_dt_hashes = COUNT_DISTINCT(okta.debug_context.debug_data.dt_hash),\n Esql.total_attempts = COUNT(*),\n Esql.attempts_with_dt = SUM(has_dt_hash),\n Esql.unique_user_agents = COUNT_DISTINCT(okta.client.user_agent.raw_user_agent),\n Esql.first_seen = MIN(@timestamp),\n Esql.last_seen = MAX(@timestamp),\n Esql.dt_hash_values = VALUES(okta.debug_context.debug_data.dt_hash),\n Esql.event_action_values = VALUES(event.action),\n Esql.user_agent_values = VALUES(okta.client.user_agent.raw_user_agent),\n Esql.device_values = VALUES(okta.client.device),\n Esql.is_proxy_values = VALUES(okta.security_context.is_proxy),\n Esql.geo_country_values = VALUES(client.geo.country_name),\n Esql.geo_city_values = VALUES(client.geo.city_name),\n Esql.source_asn_values = VALUES(source.as.number),\n Esql.source_asn_org_values = VALUES(source.as.organization.name),\n Esql.threat_suspected_values = VALUES(okta.debug_context.debug_data.threat_suspected),\n Esql.risk_level_values = VALUES(okta.debug_context.debug_data.risk_level),\n Esql.risk_reasons_values = VALUES(okta.debug_context.debug_data.risk_reasons)\n BY okta.client.ip, okta.actor.alternate_id\n// Calculate automation detection metrics (float-safe division)\n| EVAL Esql.dt_coverage = Esql.attempts_with_dt * 1.0 / Esql.total_attempts,\n Esql.dt_per_attempt = Esql.unique_dt_hashes * 1.0 / Esql.total_attempts\n// Detection branches:\n// A) Many unique DT hashes relative to attempts = tooling generating new tokens per attempt\n// B) High attempts + very low DT coverage = cookie-less automation (no DT sent at all)\n// C) Multiple user agents for same user = evasion or automation\n| WHERE\n (Esql.unique_dt_hashes >= 7 AND Esql.total_attempts >= 10 AND Esql.dt_per_attempt >= 0.5)\n OR (Esql.total_attempts >= 12 AND Esql.dt_coverage < 0.15)\n OR (Esql.total_attempts >= 10 AND Esql.unique_user_agents >= 5)\n| SORT Esql.total_attempts DESC\n| KEEP Esql.*, okta.client.ip, okta.actor.alternate_id\n", + "references": [ + "https://support.okta.com/help/s/article/Troubleshooting-Distributed-Brute-Force-andor-Password-Spray-attacks-in-Okta", + "https://www.okta.com/identity-101/brute-force/", + "https://support.okta.com/help/s/article/How-does-the-Device-Token-work?language=en_US", + "https://developer.okta.com/docs/reference/api/event-types/", + "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy", + "https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection", + "https://www.okta.com/resources/whitepaper-how-adaptive-mfa-can-help-in-mitigating-brute-force-attacks/", + "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security", + "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta" + ], + "related_integrations": [ + { + "package": "okta", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.attempts_with_dt", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.device_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.dt_coverage", + "type": "double" + }, + { + "ecs": false, + "name": "Esql.dt_hash_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.dt_per_attempt", + "type": "double" + }, + { + "ecs": false, + "name": "Esql.event_action_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.first_seen", + "type": "date" + }, + { + "ecs": false, + "name": "Esql.geo_city_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.geo_country_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.is_proxy_values", + "type": "boolean" + }, + { + "ecs": false, + "name": "Esql.last_seen", + "type": "date" + }, + { + "ecs": false, + "name": "Esql.risk_level_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.risk_reasons_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.source_asn_org_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.source_asn_values", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.threat_suspected_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.total_attempts", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.unique_dt_hashes", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.unique_user_agents", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.user_agent_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "okta.actor.alternate_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "okta.client.ip", + "type": "ip" + } + ], + "risk_score": 21, + "rule_id": "23f18264-2d6d-11ef-9413-f661ea17fbce", + "setup": "The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.", + "severity": "low", + "tags": [ + "Domain: Identity", + "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/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 209 + }, + "id": "23f18264-2d6d-11ef-9413-f661ea17fbce_209", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/2553a9af-52a4-4a05-bb03-85b2a479a0a0_109.json b/packages/security_detection_engine/kibana/security_rule/2553a9af-52a4-4a05-bb03-85b2a479a0a0_109.json new file mode 100644 index 00000000000..ff70cfc6a61 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/2553a9af-52a4-4a05-bb03-85b2a479a0a0_109.json @@ -0,0 +1,104 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies PowerShell script block content containing known offensive-tool author handles or attribution strings (for example, public tool author names). Attackers often run public PowerShell tooling with minimal changes, leaving author artifacts in comments or headers.", + "from": "now-9m", + "index": [ + "winlogbeat-*", + "logs-windows.powershell*" + ], + "investigation_fields": { + "field_names": [ + "@timestamp", + "user.name", + "user.id", + "user.domain", + "powershell.file.script_block_text", + "powershell.file.script_block_id", + "powershell.sequence", + "powershell.total", + "file.path", + "file.directory", + "file.name", + "process.pid", + "host.name", + "host.id", + "powershell.file.script_block_length" + ] + }, + "language": "kuery", + "license": "Elastic License v2", + "name": "Potential PowerShell HackTool Script by Author", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This guide was created by humans with the assistance of generative AI. While its contents have been manually curated to include the most valuable information, always validate assumptions and adjust procedures to match your internal runbooks and incident triage and response policies.\n\n### Investigating Potential PowerShell HackTool Script by Author\n\nThis rule Detects PowerShell scripts that contains attribution strings commonly found in publicly available offensive PowerShell tooling. These artifacts are often present in headers or comment blocks but may also appear within embedded modules or minimally modified scripts. Use the script block content and metadata to reconstruct what ran, determine the likely source, and scope related activity across hosts and users.\n\n#### Key alert fields to review\n\n- `user.name`, `user.domain`, `user.id`: Account execution context for correlation, prioritization, and scoping.\n- `host.name`, `host.id`: Host execution context for correlation, prioritization, and scoping.\n- `powershell.file.script_block_text`: Script block content that matched the detection logic.\n- `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`: Script block metadata to pivot to other fragments or reconstruct full script content when split across multiple events.\n- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file.\n- `powershell.file.script_block_length`: Script block length (size) context.\n\n#### Possible investigation steps\n\n- Capture basic context and triage priority:\n - Record `@timestamp`, `host.name`/`host.id`, and `user.name`/`user.domain`/`user.id`.\n - Use host and identity context (asset owner, role, and expected admin activity) to determine whether this execution is likely authorized for the alerted user and endpoint.\n\n- Reconstruct the complete script block before making an assessment:\n - Review `powershell.file.script_block_text` and identify the specific author handle or attribution string and its surrounding lines.\n - If the content appears truncated or the event indicates multiple parts, use `powershell.file.script_block_id` together with `powershell.sequence` and `powershell.total` to assemble the full script in the correct order. Confirm all sequence parts are present.\n - Use `powershell.file.script_block_length` as additional context (for example, to distinguish short snippets from large modules) and preserve the reconstructed content for evidence and hunting.\n\n- Determine the likely source of the script content:\n - If `file.path`/`file.name` (and `file.directory`) are present, treat this as file-backed execution and note whether the location and filename align with approved script storage or deployment paths for that host.\n - If `file.path` is a network share (UNC) or otherwise unusual for the host, treat it as higher risk until validated.\n - If file fields are absent, treat the script block as inline, interactive, or dynamically generated content. Prioritize review for scripts that fetch, decode, or build additional code at runtime.\n - If a file path is present, pivot on `file.path` and `file.name` to identify other executions or duplicates of the same script across users and hosts.\n\n- Assess intent from the content and extract observables:\n - Determine whether the match is limited to comments/metadata or is accompanied by functional code.\n - Look for behaviors that commonly accompany offensive PowerShell tooling, such as broad host or domain discovery, credential access helpers, privilege manipulation, remote execution primitives, persistence logic, or payload delivery mechanisms.\n - Extract and record observables embedded in `powershell.file.script_block_text` (for example, domains, IPs, URLs, hostnames, usernames, file paths, or registry paths) and use them to pivot for additional activity.\n\n- Scope and correlate related activity:\n - Search for additional script block events containing the same author handle within `powershell.file.script_block_text` across the environment. Start with the same `user.id` and `host.id`, then expand to other users and hosts.\n - On the same `host.name`, review other script block events from the same `user.name` in the minutes before and after the alert to identify setup actions (module imports, function definitions) and follow-on execution.\n - If other endpoint telemetry is available, correlate around `@timestamp` on the same host to identify:\n - The PowerShell host process and any parent process responsible for launching it.\n - Network connections, file writes, or registry changes consistent with the script content and extracted observables.\n - Authentication activity for `user.name` that could explain the session context (interactive use vs remote access).\n\n### False positive analysis\n\n- Legitimate administrative scripts may incorporate third-party modules that include author headers; these are typically file-backed and executed from expected locations or managed repositories.\n- False positives are more likely when the author string is isolated within comments and there is minimal additional script functionality; they are less likely when the script implements operational capabilities aligned with offensive tooling.\n\n### Response and remediation\n\n- If activity is unauthorized or suspicious:\n - Preserve the full reconstructed script content (all parts) and retain supporting context: `powershell.file.script_block_id`, `host.id`, `host.name`, `user.id`, `user.name`, `user.domain`, and `@timestamp`.\n - Scope impact by searching for the same author handle and extracted observables across PowerShell script block logs to identify additional affected hosts and accounts.\n - If `file.path` is present, locate and quarantine the referenced script per your procedures and review the endpoint for other copies that share the same `file.name`.\n - Apply containment measures appropriate to the risk (for example, isolate the endpoint from the network) if the content indicates credential access, remote execution, or payload delivery.\n - Review the initiating account for compromise and take credential and access control actions consistent with your incident response process.\n\n- If activity is authorized:\n - Document the activity (owner, timeframe, intended hosts) and validate alignment with change management or testing approvals.\n - Ensure the SOC has an up-to-date list of approved users and endpoints for testing. Consider environment-specific tuning to reduce recurring noise while preserving coverage elsewhere.\n\n- Post-incident hardening:\n - Verify PowerShell logging coverage and retention are sufficient to reconstruct multi-part scripts during future investigations.\n - Use observed handles and extracted observables to perform retrospective searches for earlier executions and related activity patterns in historical script block logs.\n", + "query": "host.os.type:windows and event.category:process and\n powershell.file.script_block_text : (\n \"mattifestation\" or \"JosephBialek\" or\n \"harmj0y\" or \"ukstufus\" or\n \"SecureThisShit\" or \"Matthew Graeber\" or\n \"secabstraction\" or \"mgeeky\" or\n \"oddvarmoe\" or \"am0nsec\" or\n \"obscuresec\" or \"sixdub\" or\n \"darkoperator\" or \"funoverip\" or\n \"rvrsh3ll\" or \"kevin_robertson\" or\n \"dafthack\" or \"r4wd3r\" or\n \"danielhbohannon\" or \"OneLogicalMyth\" or\n \"cobbr_io\" or \"xorrior\" or\n \"PetrMedonos\" or \"citronneur\" or\n \"eladshamir\" or \"RastaMouse\" or\n \"enigma0x3\" or \"FuzzySec\" or\n \"424f424f\" or \"jaredhaight\" or\n \"fullmetalcache\" or \"Hubbl3\" or\n \"curi0usJack\" or \"Cx01N\" or\n \"itm4n\" or \"nurfed1\" or\n \"cfalta\" or \"Scott Sutherland\" or\n \"_nullbind\" or \"_tmenochet\" or\n \"jaredcatkinson\" or \"ChrisTruncer\" or\n \"monoxgas\" or \"TheRealWover\" or\n \"splinter_code\"\n ) and\n not powershell.file.script_block_text : (\"Get-UEFIDatabaseSigner\" or \"Posh-SSH\")\n", + "references": [ + "https://github.com/atc-project/atc-data/blob/master/docs/Logging_Policies/LP_0109_windows_powershell_script_block_log.md" + ], + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.category", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_text", + "type": "unknown" + } + ], + "risk_score": 73, + "rule_id": "2553a9af-52a4-4a05-bb03-85b2a479a0a0", + "setup": "## Setup\n\nPowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104).\nSetup instructions: https://ela.st/powershell-logging-setup\n", + "severity": "high", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Execution", + "Data Source: PowerShell Logs", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.001", + "name": "PowerShell", + "reference": "https://attack.mitre.org/techniques/T1059/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 109 + }, + "id": "2553a9af-52a4-4a05-bb03-85b2a479a0a0_109", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/27071ea3-e806-4697-8abc-e22c92aa4293_212.json b/packages/security_detection_engine/kibana/security_rule/27071ea3-e806-4697-8abc-e22c92aa4293_212.json new file mode 100644 index 00000000000..3000caae8e0 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/27071ea3-e806-4697-8abc-e22c92aa4293_212.json @@ -0,0 +1,182 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "building_block_type": "default", + "description": "Identifies PowerShell script block content that uses archive compression cmdlets or .NET compression classes (for example, Compress-Archive, ZipFile, GZipStream, DeflateStream) to build compressed artifacts. Attackers compress or package data to stage it for collection or exfiltration.", + "filters": [ + { + "meta": { + "negate": true + }, + "query": { + "wildcard": { + "file.path": { + "case_insensitive": true, + "value": "?:\\\\ProgramData\\\\Microsoft\\\\Windows Defender Advanced Threat Protection\\\\Downloads\\\\*" + } + } + } + }, + { + "meta": { + "negate": true + }, + "query": { + "wildcard": { + "file.path": { + "case_insensitive": true, + "value": "?:\\\\ProgramData\\\\Microsoft\\\\Windows Defender Advanced Threat Protection\\\\DataCollection\\\\*" + } + } + } + }, + { + "meta": { + "negate": true + }, + "query": { + "wildcard": { + "file.path": { + "case_insensitive": true, + "value": "?:\\\\Program Files\\\\WindowsPowerShell\\\\Modules\\\\*" + } + } + } + }, + { + "meta": { + "negate": true + }, + "query": { + "wildcard": { + "file.path": { + "case_insensitive": true, + "value": "?:\\\\Program Files\\\\Azure\\\\StorageSyncAgent\\\\AFSDiag.ps1" + } + } + } + } + ], + "from": "now-9m", + "index": [ + "winlogbeat-*", + "logs-windows.powershell*" + ], + "investigation_fields": { + "field_names": [ + "@timestamp", + "user.name", + "user.id", + "user.domain", + "powershell.file.script_block_text", + "powershell.file.script_block_id", + "powershell.sequence", + "powershell.total", + "file.path", + "file.directory", + "file.name", + "process.pid", + "host.name", + "host.id", + "powershell.file.script_block_length" + ] + }, + "language": "kuery", + "license": "Elastic License v2", + "name": "PowerShell Script with Archive Compression Capabilities", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This guide was created by humans with the assistance of generative AI. While its contents have been manually curated to include the most valuable information, always validate assumptions and adjust procedures to match your internal runbooks and incident triage and response policies.\n\n### Investigating PowerShell Script with Archive Compression Capabilities\n\nThis alert identifies PowerShell script block content that references archive compression functionality. Matches can be driven by the `Compress-Archive` cmdlet or by .NET compression classes (for example, `IO.Compression.ZipFile`, `IO.Compression.ZipArchive`, `GZipStream`, `DeflateStream`, `BrotliStream`, `ZLibStream`) paired with compression configuration terms (for example, `CompressionLevel`, `CompressionMode`, `ZipArchiveMode`). Compression is common in legitimate automation, but it can also be used to package collected data for staging and potential exfiltration.\n\nPrioritize understanding (1) who ran the script and where, (2) what data was targeted for compression, (3) where the resulting archive or compressed data was staged, and (4) whether there is follow-on activity consistent with collection or transfer.\n\n#### Key alert fields to review\n\n- `user.name`, `user.domain`, `user.id`: Account execution context for correlation, prioritization, and scoping.\n- `host.name`, `host.id`: Host execution context for correlation, prioritization, and scoping.\n- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file.\n- `powershell.file.script_block_text`: Script block content that matched the detection logic.\n- `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`: Script block metadata to pivot to other fragments or reconstruct full script content when split across multiple events.\n- `Esql.script_block_tmp`: Transformed script block where detection patterns replace original content with a marker to support scoring/counting and quickly spot match locations.\n- `Esql.script_block_pattern_count`: Count of matches for the detection pattern(s) observed in the script block content.\n- `powershell.file.script_block_entropy_bits`: Shannon entropy of the script block. Higher values may indicate obfuscation.\n- `powershell.file.script_block_surprisal_stdev`: Standard deviation of surprisal across the script block. Low values indicate uniform randomness. High values indicate mixed patterns and variability.\n- `powershell.file.script_block_unique_symbols`: Count of distinct characters present in the script block.\n- `powershell.file.script_block_length`: Script block length (size) context.\n\n#### Possible investigation steps\n\n- Establish initial context and priority:\n - Identify the affected host and user (`host.name`, `host.id`, `user.name`, `user.domain`, `user.id`).\n - Assess whether the user is expected to run PowerShell that creates archives on this host. Unexpected host-user pairings or rare activity on sensitive systems should be prioritized.\n - Review the alert time in relation to known operational activity (for example, maintenance windows, support cases, backup or migration tasks).\n\n- Quickly understand what matched:\n - Review `Esql.script_block_tmp` to locate the matched compression indicators within the script block.\n - Use `Esql.script_block_pattern_count` to understand whether the script contains repeated compression indicators (often seen in loops or multi-step staging).\n - Review `powershell.file.script_block_text` to determine whether the activity is `Compress-Archive` usage, .NET compression usage, or both.\n\n- Assess script complexity and likelihood of obfuscation:\n - Review `powershell.file.script_block_length` to understand whether the script block is small and targeted or large and multi-purpose.\n - Use `powershell.file.script_block_entropy_bits`, `powershell.file.script_block_surprisal_stdev`, and `powershell.file.script_block_unique_symbols` to triage for suspicious encoding/obfuscation:\n - High entropy with low variability can indicate embedded encoded content.\n - High variability can indicate a mix of readable logic and opaque data blobs.\n - If metrics suggest obfuscation, prioritize deeper review and broader scoping for related script blocks from the same host and user.\n\n- Reconstruct full script block content when fragmented:\n - Pivot on `powershell.file.script_block_id` and collect all fragments for that ID.\n - Order fragments by `powershell.sequence` and validate completeness using `powershell.total` when present.\n - Re-review the reconstructed script to understand inputs, outputs, and any follow-on behavior.\n\n- Identify what data is being compressed and where it is staged:\n - In `powershell.file.script_block_text`, identify source paths, file selection logic (for example, recursion, wildcards, extension filters), and loops that suggest bulk collection vs a single archive operation.\n - Identify the output archive name and destination directory (if specified). Focus on archives staged in user-writable or temporary directories, newly created staging folders, or remote locations.\n - Determine whether compression produces an on-disk archive, in-memory compressed data, or both (for example, stream-based compression used with output streams or byte arrays).\n\n- Determine script origin and delivery path:\n - If `file.path`, `file.directory`, or `file.name` are present, assess whether the script origin aligns with expected administrative tooling for the host role.\n - Review whether the script file appears newly introduced or recently modified relative to the alert time and whether similar scripts exist on other expected hosts.\n - If file origin fields are absent, treat the activity as potentially interactive or remotely delivered and prioritize identifying the initiating process/source using adjacent endpoint telemetry.\n\n- Correlate with adjacent host activity to validate intent and impact (as available):\n - Process context:\n - Identify the PowerShell host process associated with the script block and determine the parent process or initiation source near the alert time.\n - Increase suspicion for unusual launch chains, unexpected automation context, or repeated executions by the same user across multiple hosts.\n - File activity:\n - Look for archive creation or modification events consistent with the output identified in the script block.\n - Review whether the archive is renamed, moved, copied to shared locations, or deleted shortly after creation.\n - Network activity:\n - Review outbound connections from the same host following the suspected archive creation window, especially new or rare destinations, large transfers, or repeated connections shortly after staging.\n - Authentication activity:\n - Review nearby logon activity for the same user, including new logons to other hosts around the same time, which may indicate coordinated collection and staging.\n\n- Assess prevalence and scope:\n - Search for the same `file.path`/`file.name` or distinctive substrings from `powershell.file.script_block_text` across hosts to determine whether the behavior is isolated or widespread.\n - Identify whether similar compression activity occurs across multiple hosts under the same user context or within a short time window.\n\n### False positive analysis\n\n- This activity can be benign when compression is used for routine operations such as packaging logs, diagnostics, backups, software deployment artifacts, or data migration.\n- Benign activity is more likely when:\n - The script origin (`file.path`/`file.directory`/`file.name`) aligns with approved administrative workflows and expected host roles.\n - The compressed inputs are narrow and operationally relevant rather than broad user or shared data sets.\n - Execution is consistent over time (repeatable cadence, consistent hosts, consistent users) and is not followed by suspicious file movement or unusual outbound network activity.\n- Escalate for further review when:\n - Script block characteristics suggest obfuscation or embedded opaque content (entropy and symbol distribution inconsistent with typical administrative scripts).\n - Compression targets broad directories, multiple paths, or patterns suggestive of data harvesting.\n - Archives are staged in unusual locations or closely followed by movement off-host, deletion, or network activity indicative of transfer.\n\n### Response and remediation\n\n- If malicious or suspicious activity is confirmed:\n - Contain the affected host to prevent additional staging or transfer.\n - Preserve evidence:\n - Full `powershell.file.script_block_text` (reconstructed using `powershell.file.script_block_id`, `powershell.sequence`, and `powershell.total` when needed).\n - `file.path`/`file.name` for any on-disk script source and the archive output path and filename identified in the script content.\n - Host and user identifiers (`host.id`, `host.name`, `user.id`, `user.name`, `user.domain`).\n - Identify potential data exposure:\n - Determine what directories and file patterns were included and whether the archive was copied or transmitted externally.\n - Expand scoping:\n - Hunt for similar script block content and archive staging behavior across endpoints, especially under the same user context.\n - Remediate root cause:\n - Remove unauthorized scripts and staged archives.\n - If credential misuse is suspected, reset impacted credentials and review recent account activity for additional misuse.\n\n- If the activity is verified benign:\n - Document the legitimate owner, purpose, and expected host/user scope for future triage.\n - Consider adding operational context (for example, asset criticality, expected administrative accounts, or known script repositories) to reduce repeated investigation while preserving coverage for unexpected archive staging behavior.\n", + "query": "event.category:process and host.os.type:windows and\n(\n powershell.file.script_block_text : (\n \"IO.Compression.ZipFile\" or\n \"IO.Compression.ZipArchive\" or\n \"ZipFile.CreateFromDirectory\" or\n \"IO.Compression.BrotliStream\" or\n \"IO.Compression.DeflateStream\" or\n \"IO.Compression.GZipStream\" or\n \"IO.Compression.ZLibStream\"\n ) and \n powershell.file.script_block_text : (\n \"CompressionLevel\" or\n \"CompressionMode\" or\n \"ZipArchiveMode\"\n ) or\n powershell.file.script_block_text : \"Compress-Archive\"\n) and\nnot powershell.file.script_block_text : (\n \"Compress-Archive -Path 'C:\\ProgramData\\Lenovo\\Udc\\diagnostics\\latest\" or\n (\"Copyright: (c) 2017, Ansible Project\" and \"Ansible.ModuleUtils.Backup\")\n) and\nnot file.directory : (\n \"C:\\Program Files\\Microsoft Dependency Agent\\plugins\\lib\" or\n \"C:\\Program Files\\WindowsPowerShell\\Modules\\icinga-powershell-framework\\cache\" or\n \"C:\\ProgramData\\Microsoft\\Windows Defender Advanced Threat Protection\\Downloads\"\n) and\nnot user.id : \"S-1-5-18\"\n", + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.category", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.directory", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_text", + "type": "unknown" + }, + { + "ecs": true, + "name": "user.id", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "27071ea3-e806-4697-8abc-e22c92aa4293", + "setup": "## Setup\n\nPowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104).\nSetup instructions: https://ela.st/powershell-logging-setup\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Collection", + "Data Source: PowerShell Logs", + "Rule Type: BBR", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0009", + "name": "Collection", + "reference": "https://attack.mitre.org/tactics/TA0009/" + }, + "technique": [ + { + "id": "T1560", + "name": "Archive Collected Data", + "reference": "https://attack.mitre.org/techniques/T1560/" + } + ] + }, + { + "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": "query", + "version": 212 + }, + "id": "27071ea3-e806-4697-8abc-e22c92aa4293_212", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/27f7c15a-91f8-4c3d-8b9e-1f99cc030a51_212.json b/packages/security_detection_engine/kibana/security_rule/27f7c15a-91f8-4c3d-8b9e-1f99cc030a51_212.json new file mode 100644 index 00000000000..2d3ecf76175 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/27f7c15a-91f8-4c3d-8b9e-1f99cc030a51_212.json @@ -0,0 +1,95 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies when external access is enabled in Microsoft Teams. External access lets Teams and Skype for Business users communicate with other users that are outside their organization. An adversary may enable external access or add an allowed domain to exfiltrate data or maintain persistence in an environment.", + "false_positives": [ + "Teams external access may be enabled by a system or network administrator. Verify that the configuration change was expected. Exceptions can be added to this rule to filter expected behavior." + ], + "from": "now-9m", + "index": [ + "logs-o365.audit-*", + "filebeat-*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "Deprecated - M365 Teams External Access Enabled", + "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 - M365 Teams External Access Enabled\n\nMicrosoft Teams' external access feature allows users to communicate with individuals outside their organization, facilitating collaboration. However, adversaries can exploit this by enabling external access or adding trusted domains to exfiltrate data or maintain persistence. The detection rule monitors audit logs for changes in federation settings, specifically when external access is successfully enabled, indicating potential misuse.\n\n### Possible investigation steps\n\n- Review the audit logs for the specific event.action \"Set-CsTenantFederationConfiguration\" to identify when and by whom the external access was enabled.\n- Examine the o365.audit.Parameters.AllowFederatedUsers field to confirm that it is set to True, indicating that external access was indeed enabled.\n- Investigate the user account associated with the event to determine if the action was authorized and if the account has a history of suspicious activity.\n- Check the event.provider field to see if the change was made through SkypeForBusiness or MicrosoftTeams, which may provide additional context on the method used.\n- Assess the event.outcome field to ensure the action was successful and not a failed attempt, which could indicate a potential security threat.\n- Look into any recent changes in the list of allowed domains to identify if any unauthorized or suspicious domains have been added.\n\n### False positive analysis\n\n- Routine administrative changes to federation settings can trigger alerts. Regularly review and document these changes to differentiate between legitimate and suspicious activities.\n- Organizations with frequent collaboration with external partners may see increased alerts. Consider creating exceptions for known trusted domains to reduce noise.\n- Scheduled updates or policy changes by IT teams might enable external access temporarily. Coordinate with IT to log these activities and exclude them from triggering alerts.\n- Automated scripts or tools used for configuration management can inadvertently enable external access. Ensure these tools are properly documented and monitored to prevent false positives.\n- Changes made during mergers or acquisitions can appear suspicious. Maintain a record of such events and adjust monitoring rules accordingly to account for expected changes.\n\n### Response and remediation\n\n- Immediately disable external access in Microsoft Teams to prevent further unauthorized communication with external domains.\n- Review and remove any unauthorized or suspicious domains added to the allowed list in the Teams federation settings.\n- Conduct a thorough audit of recent changes in the Teams configuration to identify any other unauthorized modifications or suspicious activities.\n- Reset credentials and enforce multi-factor authentication for accounts involved in the configuration change to prevent further unauthorized access.\n- Notify the security team and relevant stakeholders about the incident for awareness and further investigation.\n- Escalate the incident to the incident response team if there is evidence of data exfiltration or if the scope of the breach is unclear.\n- Implement enhanced monitoring and alerting for changes in Teams federation settings to detect similar threats in the future.", + "query": "event.dataset:o365.audit and event.provider:(SkypeForBusiness or MicrosoftTeams) and\nevent.category:web and event.action:\"Set-CsTenantFederationConfiguration\" and\no365.audit.Parameters.AllowFederatedUsers:True and event.outcome:success\n", + "references": [ + "https://docs.microsoft.com/en-us/microsoftteams/manage-external-access" + ], + "related_integrations": [ + { + "package": "o365", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.category", + "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.Parameters.AllowFederatedUsers", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "27f7c15a-91f8-4c3d-8b9e-1f99cc030a51", + "setup": "The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Data Source: Microsoft 365", + "Use Case: Configuration Audit", + "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/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 212 + }, + "id": "27f7c15a-91f8-4c3d-8b9e-1f99cc030a51_212", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/29531d20-0e80-41d4-9ec6-d6b58e4a475c_2.json b/packages/security_detection_engine/kibana/security_rule/29531d20-0e80-41d4-9ec6-d6b58e4a475c_2.json new file mode 100644 index 00000000000..49fbf5a31f3 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/29531d20-0e80-41d4-9ec6-d6b58e4a475c_2.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 // Top noisy influencing rules\n not kibana.alert.rule.name in (\"Agent Spoofing - Mismatched Agent ID\", \"Compression DLL Loaded by Unusual Process\", \"Process Termination followed by Deletion\", \"Suspicious PrintSpooler Service Executable File Creation\", \"Potential PrintNightmare File Modification\") and\n not kibana.alert.rule.name like \"Deprecated - *\" and\n not KQL(\"\"\"kibana.alert.rule.tags : \"Rule Type: Higher-Order Rule\" \"\"\")\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": 2 + }, + "id": "29531d20-0e80-41d4-9ec6-d6b58e4a475c_2", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/2abda169-416b-4bb3-9a6b-f8d239fd78ba_206.json b/packages/security_detection_engine/kibana/security_rule/2abda169-416b-4bb3-9a6b-f8d239fd78ba_206.json deleted file mode 100644 index 4764ef62eec..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/2abda169-416b-4bb3-9a6b-f8d239fd78ba_206.json +++ /dev/null @@ -1,108 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "This rule detects when a pod is created with a sensitive volume of type hostPath. A hostPath volume type mounts a sensitive file or folder from the node to the container. If the container gets compromised, the attacker can use this mount for gaining access to the node. There are many ways a container with unrestricted access to the host filesystem can escalate privileges, including reading data from other containers, and accessing tokens of more privileged pods.", - "false_positives": [ - "An administrator may need to attach a hostPath volume for a legitimate reason. This alert should be investigated for legitimacy by determining if the kuberenetes.audit.requestObject.spec.volumes.hostPath.path triggered is one needed by its target container/pod. For example, when the fleet managed elastic agent is deployed as a daemonset it creates several hostPath volume mounts, some of which are sensitive host directories like /proc, /etc/kubernetes, and /var/log. Add exceptions for trusted container images using the query field \"kubernetes.audit.requestObject.spec.container.image\"" - ], - "index": [ - "logs-kubernetes.*" - ], - "language": "kuery", - "license": "Elastic License v2", - "name": "Kubernetes Pod created with a Sensitive hostPath Volume", - "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 Kubernetes Pod created with a Sensitive hostPath Volume\n\nKubernetes allows containers to access host filesystems via hostPath volumes, which can be crucial for certain applications. However, if a container is compromised, adversaries can exploit these mounts to access sensitive host data or escalate privileges. The detection rule identifies when pods are created or modified with hostPath volumes pointing to critical directories, signaling potential misuse or security risks.\n\n### Possible investigation steps\n\n- Review the Kubernetes audit logs to identify the specific pod creation or modification event that triggered the alert, focusing on the event.dataset field with the value \"kubernetes.audit_logs\".\n- Examine the kubernetes.audit.requestObject.spec.volumes.hostPath.path field to determine which sensitive hostPath was mounted and assess the potential risk associated with that specific path.\n- Check the kubernetes.audit.annotations.authorization_k8s_io/decision field to confirm that the action was allowed, and verify the legitimacy of the authorization decision.\n- Investigate the kubernetes.audit.requestObject.spec.containers.image field to identify the container image used, ensuring it is not a known or suspected malicious image, and cross-reference with any known vulnerabilities or security advisories.\n- Analyze the context of the pod creation or modification by reviewing the kubernetes.audit.verb field to understand whether the action was a create, update, or patch operation, and correlate this with recent changes or deployments in the environment.\n- Assess the potential impact on the cluster by identifying other pods or services that might be affected by the compromised pod, especially those with elevated privileges or access to sensitive data.\n\n### False positive analysis\n\n- Development environments often use hostPath volumes for testing purposes, which can trigger this rule. To manage this, create exceptions for specific namespaces or labels associated with development workloads.\n- Monitoring tools or agents may require access to certain host paths for legitimate reasons. Identify these tools and exclude their specific container images from the rule, similar to the exclusion of the elastic-agent image.\n- Backup or logging applications might need access to host directories to perform their functions. Review these applications and consider excluding their specific hostPath configurations if they are deemed non-threatening.\n- Some system maintenance tasks might temporarily use hostPath volumes. Document these tasks and schedule them during known maintenance windows, then create temporary exceptions during these periods.\n- Custom scripts or automation tools that interact with Kubernetes may inadvertently trigger this rule. Audit these scripts and tools, and if they are safe, exclude their specific actions or paths from the rule.\n\n### Response and remediation\n\n- Immediately isolate the affected pod to prevent further access to sensitive host data. This can be done by cordoning the node or deleting the pod if necessary.\n- Review and revoke any credentials or tokens that may have been exposed through the compromised pod to prevent unauthorized access to other resources.\n- Conduct a thorough analysis of the container image and application code to identify any vulnerabilities or malicious code that may have led to the compromise.\n- Patch or update the container image and application code to address any identified vulnerabilities, and redeploy the application with the updated image.\n- Implement network policies to restrict pod-to-pod and pod-to-node communication, limiting the potential impact of a compromised pod.\n- Enhance monitoring and logging for Kubernetes audit logs to ensure timely detection of similar threats in the future, focusing on unauthorized access attempts and privilege escalation activities.\n- Escalate the incident to the security operations team for further investigation and to assess the need for additional security measures or incident response actions.", - "query": "event.dataset : \"kubernetes.audit_logs\"\n and kubernetes.audit.annotations.authorization_k8s_io/decision:\"allow\"\n and kubernetes.audit.objectRef.resource:\"pods\"\n and kubernetes.audit.verb:(\"create\" or \"update\" or \"patch\")\n and kubernetes.audit.requestObject.spec.volumes.hostPath.path:\n (\"/\" or\n \"/proc\" or\n \"/root\" or\n \"/var\" or\n \"/var/run\" or\n \"/var/run/docker.sock\" or\n \"/var/run/crio/crio.sock\" or\n \"/var/run/cri-dockerd.sock\" or\n \"/var/lib/kubelet\" or\n \"/var/lib/kubelet/pki\" or\n \"/var/lib/docker/overlay2\" or\n \"/etc\" or\n \"/etc/kubernetes\" or\n \"/etc/kubernetes/manifests\" or\n \"/etc/kubernetes/pki\" or\n \"/home/admin\")\n and not kubernetes.audit.requestObject.spec.containers.image: (\"docker.elastic.co/beats/elastic-agent:8.4.0\")\n", - "references": [ - "https://blog.appsecco.com/kubernetes-namespace-breakout-using-insecure-host-path-volume-part-1-b382f2a6e216", - "https://kubernetes.io/docs/concepts/storage/volumes/#hostpath" - ], - "related_integrations": [ - { - "package": "kubernetes", - "version": "^1.80.0" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "event.dataset", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.annotations.authorization_k8s_io/decision", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.objectRef.resource", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.requestObject.spec.containers.image", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.requestObject.spec.volumes.hostPath.path", - "type": "unknown" - }, - { - "ecs": false, - "name": "kubernetes.audit.verb", - "type": "keyword" - } - ], - "risk_score": 47, - "rule_id": "2abda169-416b-4bb3-9a6b-f8d239fd78ba", - "setup": "The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule.", - "severity": "medium", - "tags": [ - "Data Source: Kubernetes", - "Tactic: Execution", - "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": "T1611", - "name": "Escape to Host", - "reference": "https://attack.mitre.org/techniques/T1611/" - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0002", - "name": "Execution", - "reference": "https://attack.mitre.org/tactics/TA0002/" - }, - "technique": [ - { - "id": "T1610", - "name": "Deploy Container", - "reference": "https://attack.mitre.org/techniques/T1610/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "query", - "version": 206 - }, - "id": "2abda169-416b-4bb3-9a6b-f8d239fd78ba_206", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/2bf78aa2-9c56-48de-b139-f169bf99cf86_419.json b/packages/security_detection_engine/kibana/security_rule/2bf78aa2-9c56-48de-b139-f169bf99cf86_419.json new file mode 100644 index 00000000000..7672c04014f --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/2bf78aa2-9c56-48de-b139-f169bf99cf86_419.json @@ -0,0 +1,120 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects writing executable files that will be automatically launched by Adobe on launch.", + "from": "now-9m", + "index": [ + "winlogbeat-*", + "logs-endpoint.events.file-*", + "logs-windows.sysmon_operational-*", + "endgame-*", + "logs-sentinel_one_cloud_funnel.*", + "logs-m365_defender.event-*", + "logs-crowdstrike.fdr*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Deprecated - Adobe Hijack Persistence", + "note": "## Triage and analysis\n\n### Investigating Deprecated - Adobe Hijack Persistence\n\nAttackers can replace the `RdrCEF.exe` executable with their own to maintain their access, which will be launched whenever Adobe Acrobat Reader is executed.\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 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 the user account that performed the action and whether it should perform this kind of action.\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- Examine the host for derived artifacts that indicate suspicious activities:\n - Analyze the file 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 - Examine the DNS cache for suspicious or anomalous entries.\n - !{osquery{\"label\":\"Osquery - Retrieve DNS Cache\",\"query\":\"SELECT * FROM dns_cache\"}}\n - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree.\n - Examine the host services for suspicious or anomalous entries.\n - !{osquery{\"label\":\"Osquery - Retrieve All Services\",\"query\":\"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services\"}}\n - !{osquery{\"label\":\"Osquery - Retrieve Services Running on User Accounts\",\"query\":\"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\\nuser_account == null)\\n\"}}\n - !{osquery{\"label\":\"Osquery - Retrieve Service Unsigned Executables with Virustotal Link\",\"query\":\"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\\n\"}}\n - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.\n- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the target host after the registry modification.\n\n### False positive analysis\n\n- This 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 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- 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- 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": "file where host.os.type == \"windows\" and event.type == \"creation\" and\n file.path : (\n \"?:\\\\Program Files (x86)\\\\Adobe\\\\Acrobat Reader DC\\\\Reader\\\\AcroCEF\\\\RdrCEF.exe\",\n \"?:\\\\Program Files\\\\Adobe\\\\Acrobat Reader DC\\\\Reader\\\\AcroCEF\\\\RdrCEF.exe\",\n\n /* Crowdstrike specific condition as it uses NT Object paths */\n \"\\\\Device\\\\HarddiskVolume*\\\\Program Files (x86)\\\\Adobe\\\\Acrobat Reader DC\\\\Reader\\\\AcroCEF\\\\RdrCEF.exe\",\n \"\\\\Device\\\\HarddiskVolume*\\\\Program Files\\\\Adobe\\\\Acrobat Reader DC\\\\Reader\\\\AcroCEF\\\\RdrCEF.exe\"\n ) and\n not process.name : (\"msiexec.exe\", \"AdobeARM.exe\")\n", + "references": [ + "https://twitter.com/pabraeken/status/997997818362155008" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "windows", + "version": "^3.0.0" + }, + { + "package": "sentinel_one_cloud_funnel", + "version": "^1.0.0" + }, + { + "package": "m365_defender", + "version": "^3.0.0" + }, + { + "package": "crowdstrike", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.path", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "2bf78aa2-9c56-48de-b139-f169bf99cf86", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Persistence", + "Resources: Investigation Guide", + "Data Source: Elastic Endgame", + "Data Source: Elastic Defend", + "Data Source: Sysmon", + "Data Source: SentinelOne", + "Data Source: Microsoft Defender for Endpoint", + "Data Source: Crowdstrike" + ], + "threat": [ + { + "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/" + }, + { + "id": "T1574", + "name": "Hijack Execution Flow", + "reference": "https://attack.mitre.org/techniques/T1574/", + "subtechnique": [ + { + "id": "T1574.010", + "name": "Services File Permissions Weakness", + "reference": "https://attack.mitre.org/techniques/T1574/010/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 419 + }, + "id": "2bf78aa2-9c56-48de-b139-f169bf99cf86_419", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/2c40dfe2-c13e-48a8-8eff-fb9bfb2a7854_2.json b/packages/security_detection_engine/kibana/security_rule/2c40dfe2-c13e-48a8-8eff-fb9bfb2a7854_2.json new file mode 100644 index 00000000000..63c082504c4 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/2c40dfe2-c13e-48a8-8eff-fb9bfb2a7854_2.json @@ -0,0 +1,101 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects FortiGate alerts that are observed for the first time in the previous 5 days of alert history. Analysts can use this to prioritize triage and response.", + "from": "now-7205m", + "interval": "5m", + "language": "esql", + "license": "Elastic License v2", + "name": "Newly Observed FortiGate Alert", + "note": "## Triage and analysis\n\n### Investigating Newly Observed Fortigate Alert\n\nThis rule surfaces newly observed, low-frequency high severity FortiGate alerts within the last 5 days.\n\nBecause the alert has not been seen previously, it should be prioritized for validation to determine whether it represents a true compromise or rare benign activity.\n\n### Investigation Steps\n\n- Identify the source address, affected host and review the associated message to understand the alert.\n- Validate the source address under which the activity occurred and assess whether it aligns with normal behavior.\n- Refer to the specific alert details like event.original to get more context.\n\n### False Positive Considerations\n\n- Vulnerability scanners and pentesting.\n- Administrative scripts or automation tools can trigger detections when first introduced.\n- Development or testing environments may produce one-off behaviors that resemble malicious techniques.\n\n### Response and Remediation\n\n- If the activity is confirmed malicious, isolate the affected host to prevent further execution or lateral movement.\n- Terminate malicious processes and remove any dropped files or persistence mechanisms.\n- Collect forensic artifacts to understand initial access and execution flow.\n- Patch or remediate any vulnerabilities or misconfigurations that enabled the behavior.\n- If benign, document the finding and consider tuning or exception handling to reduce future noise.\n- Continue monitoring the host and environment for recurrence of the behavior or related alerts.", + "query": "FROM logs-fortinet_fortigate.*, filebeat-* metadata _id\n\n| WHERE event.module == \"fortinet_fortigate\" and event.action in (\"signature\", \"ssl-anomaly\") and\n message is not null and event.category != \"authentication\" and\n message != \"Connection Failed\" and not message like \"Web.Client: *\" and\n not message like \"Network.Service: *\" and not message like \"General.Interest*\" and not message like \"Update: *\" and\n not message like \"tcp_reassembler*\" and not message like \"a-ipdf*\" and not message like \"Video*\" and not message like \"nbss_decode*\" and\n not message like \"name_server*\" and not message like \"misc*\" and not message like \"Collaboration*\" and not message like \"Business*\" and\n not message like \"Cloud.IT*\" and not message like \"Mobile*\"\n\n| STATS Esql.alerts_count = count(*),\n Esql.first_time_seen = MIN(@timestamp),\n Esql.distinct_count_src_ip = COUNT_DISTINCT(source.ip),\n Esql.distinct_count_dst_ip = COUNT_DISTINCT(destination.ip),\n src_ip = VALUES(source.ip),\n dst_ip = VALUES(destination.ip),\n url_domain = VALUES(url.domain),\n url_path = VALUES(url.path) by message, event.category, event.outcome\n\n// first time seen is within 10m of the rule execution time\n| eval Esql.recent = DATE_DIFF(\"minute\", Esql.first_time_seen, now())\n| where Esql.recent <= 10 and Esql.alerts_count <= 5 and Esql.distinct_count_src_ip <= 2 and Esql.distinct_count_dst_ip <= 2\n\n// move dynamic fields to ECS equivalent for rule exceptions\n| eval source.ip = MV_FIRST(src_ip),\n destination.ip = MV_FIRST(dst_ip),\n url.domain = MV_FIRST(url_domain),\n url.path = MV_FIRST(url_path)\n\n| keep message, event.category, event.outcome, Esql.*, source.ip, destination.ip, url.domain, url.path\n", + "references": [ + "https://www.elastic.co/docs/reference/integrations/fortinet_fortigate" + ], + "related_integrations": [ + { + "package": "fortinet_fortigate", + "version": "^1.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.alerts_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.distinct_count_dst_ip", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.distinct_count_src_ip", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.first_time_seen", + "type": "date" + }, + { + "ecs": false, + "name": "Esql.recent", + "type": "integer" + }, + { + "ecs": true, + "name": "destination.ip", + "type": "ip" + }, + { + "ecs": true, + "name": "event.category", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.outcome", + "type": "keyword" + }, + { + "ecs": true, + "name": "message", + "type": "match_only_text" + }, + { + "ecs": true, + "name": "source.ip", + "type": "ip" + }, + { + "ecs": true, + "name": "url.domain", + "type": "keyword" + }, + { + "ecs": true, + "name": "url.path", + "type": "wildcard" + } + ], + "risk_score": 99, + "rule_id": "2c40dfe2-c13e-48a8-8eff-fb9bfb2a7854", + "severity": "critical", + "tags": [ + "Use Case: Threat Detection", + "Rule Type: Higher-Order Rule", + "Resources: Investigation Guide", + "Domain: Network", + "Data Source: Fortinet" + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 2 + }, + "id": "2c40dfe2-c13e-48a8-8eff-fb9bfb2a7854_2", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/2c74e26b-dfe3-4644-b62b-d0482f124210_3.json b/packages/security_detection_engine/kibana/security_rule/2c74e26b-dfe3-4644-b62b-d0482f124210_3.json new file mode 100644 index 00000000000..4527604dfff --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/2c74e26b-dfe3-4644-b62b-d0482f124210_3.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-7d", + "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": 3 + }, + "id": "2c74e26b-dfe3-4644-b62b-d0482f124210_3", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/2d05fefd-40ba-43ae-af0c-3c25e86b54f1_1.json b/packages/security_detection_engine/kibana/security_rule/2d05fefd-40ba-43ae-af0c-3c25e86b54f1_1.json new file mode 100644 index 00000000000..618133dae3b --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/2d05fefd-40ba-43ae-af0c-3c25e86b54f1_1.json @@ -0,0 +1,133 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects execution of bpftool commands used to load, attach, run, or pin eBPF programs, as well as create or update eBPF maps and links. These operations interact directly with the Linux eBPF subsystem and can modify kernel-level behavior. While commonly used by legitimate networking or observability tooling, unexpected or interactive usage may indicate eBPF-based rootkit activity, policy tampering, or unauthorized kernel instrumentation.", + "from": "now-9m", + "index": [ + "auditbeat-*", + "endgame-*", + "logs-auditd_manager.auditd-*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", + "logs-crowdstrike.fdr*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "BPF Program or Map Load via bpftool", + "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 BPF Program or Map Load via bpftool\n\nThis rule flags bpftool executions that load, attach, run, or pin eBPF programs and that create or pin maps/links, actions that can change kernel behavior without traditional user-space artifacts. Adversaries can use bpftool to load a malicious eBPF object, attach it to a tracepoint or traffic control hook, and pin the program and maps in bpffs so it persists and hides or filters activity across reboots.\n\n### Possible investigation steps\n\n- Capture full command line, parent process, user context, TTY/session, and current working directory to determine whether execution was interactive administration or automated tooling. \n- Enumerate loaded and pinned eBPF artifacts and their attachment points using `bpftool prog show`, `bpftool map show`, `bpftool link show`, and a filesystem review of `/sys/fs/bpf` to identify unexpected persistence. \n- Identify the eBPF object/source used for the load (path, inode, hash, package origin) and retrieve a copy for analysis, including checking for recent writes or downloads in the same directory tree. \n- Correlate the event time with system logs and other telemetry for follow-on activity such as privilege escalation, module loads, network filtering changes, or suspicious process hiding indicators. \n- Hunt for persistence mechanisms that would reload the same eBPF program after reboot (systemd units/timers, cron, init scripts, container entrypoints) and validate against known legitimate observability/network stacks in the environment.\n\n### False positive analysis\n\n- A system administrator or SRE may run `bpftool prog load/attach/pin` or `bpftool map create/pin` during planned troubleshooting or performance investigation to temporarily instrument kernel events and persist objects under `/sys/fs/bpf` for multi-step validation. \n- A legitimate system service or boot-time automation may invoke `bpftool` to load and pin eBPF programs/maps as part of expected networking, security policy enforcement, or observability initialization, especially after upgrades or configuration changes that trigger reloading.\n\n### Response and remediation\n\n- Immediately isolate the host or container from the network and stop the initiating service/session, then detach any active hooks by removing pinned artifacts under `/sys/fs/bpf` and verifying with `bpftool prog show` and `bpftool link show` that the suspicious program/link is no longer attached. \n- Preserve evidence by collecting the full `bpftool` command line and parent chain, a recursive copy of `/sys/fs/bpf`, and the exact eBPF object file used for the load (path, hash, permissions, timestamps) before deleting or modifying artifacts. \n- Eradicate persistence by removing malicious eBPF pins, deleting or quarantining the associated `.o`/loader binaries, and disabling the boot-time mechanism that reloads them (systemd unit/timer, cron, init scripts, container entrypoint) followed by a controlled reboot to clear any remaining in-kernel state. \n- Recover by restoring the system to a known-good configuration, validating expected networking/observability behavior, and monitoring that no new pinned programs/maps/links reappear under `/sys/fs/bpf` after reboot or service restarts. \n- Escalate to incident response and kernel/rootkit specialists if the program attaches to security-relevant hooks (e.g., tracepoints/kprobes/LSM/tc) or if pinned objects reappear after removal, indicating an active persistence mechanism or compromised privileged runtime. \n- Harden by restricting `bpftool` availability and access to bpffs, enforcing least-privilege for CAP_BPF/CAP_SYS_ADMIN, requiring signed/managed eBPF loaders, and enabling controls that limit eBPF usage to approved components in production images and hosts.", + "query": "process where host.os.type == \"linux\" and event.type == \"start\" and\nevent.action in (\"exec\", \"exec_event\", \"start\", \"ProcessRollup2\", \"executed\", \"process_started\") and\nprocess.name == \"bpftool\" and (\n (process.args == \"prog\" and process.args in (\"load\", \"loadall\", \"attach\", \"run\", \"pin\")) or\n (process.args == \"map\" and process.args in (\"create\", \"pin\")) or\n (process.args == \"link\" and process.args == \"pin\")\n)\n", + "references": [ + "https://manpages.ubuntu.com/manpages/jammy/man8/bpftool-prog.8.html", + "https://manpages.ubuntu.com/manpages/noble/man8/bpftool-map.8.html", + "https://man.archlinux.org/man/bpftool-link.8.en" + ], + "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": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.args", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "2d05fefd-40ba-43ae-af0c-3c25e86b54f1", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Persistence", + "Tactic: Defense Evasion", + "Threat: Rootkit", + "Data Source: Elastic Endgame", + "Data Source: Elastic Defend", + "Data Source: Auditd Manager", + "Data Source: SentinelOne", + "Data Source: Crowdstrike", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0003", + "name": "Persistence", + "reference": "https://attack.mitre.org/tactics/TA0003/" + }, + "technique": [ + { + "id": "T1547", + "name": "Boot or Logon Autostart Execution", + "reference": "https://attack.mitre.org/techniques/T1547/", + "subtechnique": [ + { + "id": "T1547.006", + "name": "Kernel Modules and Extensions", + "reference": "https://attack.mitre.org/techniques/T1547/006/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1014", + "name": "Rootkit", + "reference": "https://attack.mitre.org/techniques/T1014/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 1 + }, + "id": "2d05fefd-40ba-43ae-af0c-3c25e86b54f1_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/2d3c27d5-d133-4152-8102-8d051619ec4a_1.json b/packages/security_detection_engine/kibana/security_rule/2d3c27d5-d133-4152-8102-8d051619ec4a_1.json new file mode 100644 index 00000000000..442168cf20d --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/2d3c27d5-d133-4152-8102-8d051619ec4a_1.json @@ -0,0 +1,207 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects potential password spray attacks where multiple source IPs target multiple Okta user accounts within a time window, indicating coordinated attacks using IP rotation to evade single-source detection.", + "false_positives": [ + "Large enterprises with many users experiencing simultaneous password issues during credential rotation events.", + "Automated monitoring or penetration testing tools scanning from multiple IPs." + ], + "from": "now-1h", + "interval": "15m", + "language": "esql", + "license": "Elastic License v2", + "name": "Potential Okta Password Spray (Multi-Source)", + "note": "## Triage and analysis\n\n### Investigating Potential Okta Password Spray (Multi-Source)\n\nThis rule identifies coordinated password spray attacks where multiple source IPs target multiple user accounts within a time window. This pattern indicates attackers using IP rotation to evade single-source detection while spraying passwords across the organization.\n\n#### Possible investigation steps\n- Review the list of targeted user accounts and check if any authentications succeeded.\n- Examine the source IPs and their ASN ownership for signs of proxy, VPN, or cloud infrastructure.\n- Check if Okta flagged any of the sources as known threats or proxies.\n- Analyze the attempts-per-user ratio to confirm spray behavior versus brute force.\n- Review the geographic distribution of source IPs for coordination patterns.\n- Cross-reference with successful authentication events to identify potential compromises.\n\n### False positive analysis\n- Organization-wide password rotation or expiration events may cause widespread authentication failures.\n- Misconfigured SSO or SAML integrations can cause batch failures from legitimate infrastructure.\n- Penetration testing should be coordinated and whitelisted in advance.\n\n### Response and remediation\n- If attack is confirmed, notify affected users and enforce password resets for potentially compromised accounts.\n- Block attacking IP ranges at the network perimeter.\n- Enable or strengthen MFA for targeted accounts.\n- Review Okta sign-on policies to add additional friction for suspicious authentication patterns.\n- Consider temporary lockdowns for highly targeted accounts.\n", + "query": "FROM logs-okta.system-* METADATA _id, _version, _index\n| WHERE\n event.dataset == \"okta.system\"\n AND (event.action LIKE \"user.authentication.*\" OR event.action == \"user.session.start\")\n AND okta.outcome.reason IN (\"INVALID_CREDENTIALS\", \"LOCKED_OUT\")\n AND okta.actor.alternate_id IS NOT NULL\n\n// Bucket into 15-minute windows and create user-source mapping for context\n| EVAL\n Esql.time_bucket = DATE_TRUNC(15 minutes, @timestamp),\n Esql.user_source_info = CONCAT(\n \"{\\\"user\\\":\\\"\", okta.actor.alternate_id,\n \"\\\",\\\"ip\\\":\\\"\", COALESCE(okta.client.ip::STRING, \"unknown\"),\n \"\\\",\\\"user_agent\\\":\\\"\", COALESCE(okta.client.user_agent.raw_user_agent, \"unknown\"), \"\\\"}\"\n )\n\n// Aggregate across entire tenant per time bucket to detect distributed spray\n| STATS\n Esql.unique_users = COUNT_DISTINCT(okta.actor.alternate_id),\n Esql.unique_source_ips = COUNT_DISTINCT(okta.client.ip),\n Esql.total_attempts = COUNT(*),\n Esql.unique_user_agents = COUNT_DISTINCT(okta.client.user_agent.raw_user_agent),\n Esql.unique_asns = COUNT_DISTINCT(source.as.number),\n Esql.unique_countries = COUNT_DISTINCT(client.geo.country_name),\n Esql.first_seen = MIN(@timestamp),\n Esql.last_seen = MAX(@timestamp),\n Esql.target_users = VALUES(okta.actor.alternate_id),\n Esql.source_ip_values = VALUES(okta.client.ip),\n Esql.user_source_mapping = VALUES(Esql.user_source_info),\n Esql.event_action_values = VALUES(event.action),\n Esql.user_agent_values = VALUES(okta.client.user_agent.raw_user_agent),\n Esql.device_values = VALUES(okta.client.device),\n Esql.is_proxy_values = VALUES(okta.security_context.is_proxy),\n Esql.geo_country_values = VALUES(client.geo.country_name),\n Esql.geo_city_values = VALUES(client.geo.city_name),\n Esql.source_asn_values = VALUES(source.as.number),\n Esql.source_asn_org_values = VALUES(source.as.organization.name),\n Esql.threat_suspected_values = VALUES(okta.debug_context.debug_data.threat_suspected),\n Esql.risk_level_values = VALUES(okta.debug_context.debug_data.risk_level),\n Esql.risk_reasons_values = VALUES(okta.debug_context.debug_data.risk_reasons)\n BY Esql.time_bucket\n\n// Calculate spray metrics\n| EVAL\n Esql.attempts_per_user = Esql.total_attempts * 1.0 / Esql.unique_users,\n Esql.attempts_per_ip = Esql.total_attempts * 1.0 / Esql.unique_source_ips,\n Esql.users_per_ip = Esql.unique_users * 1.0 / Esql.unique_source_ips\n\n// Distributed spray: many IPs, many users, moderate spread across both\n// Key differentiator: attacks come from multiple IPs (evading per-IP rules)\n| WHERE\n Esql.unique_source_ips >= 5\n AND Esql.unique_users >= 8\n AND Esql.total_attempts >= 25\n AND Esql.attempts_per_user <= 5.0\n AND Esql.users_per_ip >= 1.0\n\n| SORT Esql.total_attempts DESC\n| KEEP Esql.*\n", + "references": [ + "https://support.okta.com/help/s/article/Troubleshooting-Distributed-Brute-Force-andor-Password-Spray-attacks-in-Okta", + "https://www.okta.com/identity-101/brute-force/", + "https://developer.okta.com/docs/reference/api/event-types/", + "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy", + "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security", + "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta" + ], + "related_integrations": [ + { + "package": "okta", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.attempts_per_ip", + "type": "double" + }, + { + "ecs": false, + "name": "Esql.attempts_per_user", + "type": "double" + }, + { + "ecs": false, + "name": "Esql.device_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.event_action_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.first_seen", + "type": "date" + }, + { + "ecs": false, + "name": "Esql.geo_city_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.geo_country_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.is_proxy_values", + "type": "boolean" + }, + { + "ecs": false, + "name": "Esql.last_seen", + "type": "date" + }, + { + "ecs": false, + "name": "Esql.risk_level_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.risk_reasons_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.source_asn_org_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.source_asn_values", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.source_ip_values", + "type": "ip" + }, + { + "ecs": false, + "name": "Esql.target_users", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.threat_suspected_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.time_bucket", + "type": "date" + }, + { + "ecs": false, + "name": "Esql.total_attempts", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.unique_asns", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.unique_countries", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.unique_source_ips", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.unique_user_agents", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.unique_users", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.user_agent_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.user_source_mapping", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.users_per_ip", + "type": "double" + } + ], + "risk_score": 47, + "rule_id": "2d3c27d5-d133-4152-8102-8d051619ec4a", + "setup": "The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.", + "severity": "medium", + "tags": [ + "Domain: Identity", + "Use Case: Identity and Access Audit", + "Use Case: Threat Detection", + "Data Source: Okta", + "Data Source: Okta System Logs", + "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/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 1 + }, + "id": "2d3c27d5-d133-4152-8102-8d051619ec4a_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/2d62889e-e758-4c5e-b57e-c735914ee32a_208.json b/packages/security_detection_engine/kibana/security_rule/2d62889e-e758-4c5e-b57e-c735914ee32a_208.json new file mode 100644 index 00000000000..a71d3933656 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/2d62889e-e758-4c5e-b57e-c735914ee32a_208.json @@ -0,0 +1,148 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies PowerShell.exe or Cmd.exe execution spawning from Windows Script Host processes Wscript.exe.", + "from": "now-9m", + "index": [ + "logs-m365_defender.event-*", + "logs-sentinel_one_cloud_funnel.*", + "logs-system.security*", + "logs-windows.forwarded*", + "logs-windows.sysmon_operational-*", + "winlogbeat-*", + "endgame-*", + "logs-crowdstrike.fdr*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Command and Scripting Interpreter via Windows Scripts", + "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 and Scripting Interpreter via Windows Scripts\n\nPowerShell, a powerful scripting language in Windows, is often targeted by adversaries for executing malicious scripts. Attackers exploit Windows Script Host processes like cscript or wscript to launch PowerShell with obfuscated commands, evading detection. The detection rule identifies such suspicious activity by monitoring PowerShell executions with specific patterns and parent processes, while filtering out known legitimate use cases to reduce false positives.\n\n### Possible investigation steps\n\n- Review the process command line and arguments to identify any obfuscation patterns or suspicious commands, such as Base64 encoding or web requests, that match the query's suspicious patterns.\n- Examine the parent process details, specifically focusing on wscript.exe, cscript.exe, or mshta.exe, to determine if the PowerShell execution was initiated by a legitimate script or a potentially malicious one.\n- Check the process execution context, including the user account and host, to assess if the activity aligns with expected behavior for that user or system.\n- Investigate any network connections or file downloads initiated by the PowerShell process, especially those involving external IP addresses or domains, to identify potential data exfiltration or further malicious activity.\n- Correlate the alert with other security events or logs from the same host or user to identify any preceding or subsequent suspicious activities that could indicate a broader attack campaign.\n\n### False positive analysis\n\n- Legitimate PowerShell commands using non-shortened execution flags may trigger false positives. To manage this, exclude processes with arguments like \"-EncodedCommand\", \"Import-Module*\", and \"-NonInteractive\" unless they are associated with suspicious activity.\n- Third-party installation scripts, such as those related to Microsoft System Center or WebLogic, can cause false positives. Exclude these by filtering out specific parent process arguments or command lines, such as \"Microsoft.SystemCenter.ICMPProbe.WithConsecutiveSamples.vbs\" and \"WEBLOGIC_ARGS_CURRENT_1.DATA\".\n- Routine administrative tasks, like gathering network information, may be flagged. Exclude known scripts like \"gatherNetworkInfo.vbs\" from detection to prevent unnecessary alerts.\n- Exclude specific user scripts or tools that are known to be safe, such as those located in user directories like \"C:\\Users\\Prestige\\AppData\\Local\\Temp\\Rar$*\\KMS_VL_ALL_AIO.cmd\" if they are verified as non-malicious.\n- Regularly review and update exclusion lists to ensure they reflect current legitimate activities and do not inadvertently allow new threats.\n\n### Response and remediation\n\n- Isolate the affected system from the network to prevent further malicious activity and lateral movement.\n- Terminate any suspicious PowerShell processes identified by the alert to stop ongoing malicious execution.\n- Conduct a thorough review of the affected system's PowerShell execution logs to identify any additional malicious scripts or commands that may have been executed.\n- Remove any malicious scripts or files identified during the investigation from the system to prevent re-execution.\n- Restore the system from a known good backup if any critical system files or configurations have been altered by the malicious activity.\n- Update and patch the system to the latest security standards to close any vulnerabilities that may have been exploited.\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.", + "query": "process where host.os.type == \"windows\" and event.type == \"start\" and\n process.command_line != null and\n (\n process.name : (\"powershell.exe\", \"pwsh.exe\", \"powershell_ise.exe\", \"cmd.exe\") or\n ?process.pe.original_file_name : (\"powershell.exe\", \"pwsh.dll\", \"powershell_ise.exe\", \"Cmd.Exe\")\n ) and\n process.parent.name : (\"wscript.exe\", \"mshta.exe\") and\n not (\n process.args : (\n \"C:\\\\Program Files\\\\Intel\\\\SUR\\\\QUEENCREEK\\\\x64\\\\task.bat\",\n \"\\\"C:\\\\Program Files\\\\Intel\\\\SUR\\\\QUEENCREEK\\\\x64\\\\task.bat\\\"\"\n ) or\n process.command_line : (\n \"\\\"C:\\\\Windows\\\\system32\\\\cmd.exe\\\" /c auditpol.exe /set /SUBCATEGORY:*\",\n \"\\\"C:\\\\Windows\\\\system32\\\\cmd.exe\\\" /c auditpol.exe /get*\",\n \"\\\"C:\\\\Windows\\\\system32\\\\cmd.exe\\\" /c exit\\\"\"\n ) or\n (process.args == \"-File\" and process.args == \"-ExecutionPolicy\")\n )\n and \n not (\n ?user.id == \"S-1-5-18\" and\n /* Don't apply the user.id exclusion to Sysmon for compatibility */\n not event.dataset : (\"windows.sysmon_operational\", \"windows.sysmon\")\n ) \n", + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + }, + { + "package": "system", + "version": "^2.0.0" + }, + { + "package": "sentinel_one_cloud_funnel", + "version": "^1.0.0" + }, + { + "package": "m365_defender", + "version": "^3.0.0" + }, + { + "package": "crowdstrike", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.dataset", + "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": "process.pe.original_file_name", + "type": "keyword" + }, + { + "ecs": true, + "name": "user.id", + "type": "keyword" + } + ], + "risk_score": 73, + "rule_id": "2d62889e-e758-4c5e-b57e-c735914ee32a", + "severity": "high", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Execution", + "Resources: Investigation Guide", + "Data Source: Windows Security Event Logs", + "Data Source: Sysmon", + "Data Source: SentinelOne", + "Data Source: Microsoft Defender for Endpoint", + "Data Source: Elastic Endgame", + "Data Source: Crowdstrike" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.001", + "name": "PowerShell", + "reference": "https://attack.mitre.org/techniques/T1059/001/" + }, + { + "id": "T1059.003", + "name": "Windows Command Shell", + "reference": "https://attack.mitre.org/techniques/T1059/003/" + }, + { + "id": "T1059.005", + "name": "Visual Basic", + "reference": "https://attack.mitre.org/techniques/T1059/005/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 208 + }, + "id": "2d62889e-e758-4c5e-b57e-c735914ee32a_208", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/2de10e77-c144-4e69-afb7-344e7127abd0_213.json b/packages/security_detection_engine/kibana/security_rule/2de10e77-c144-4e69-afb7-344e7127abd0_213.json new file mode 100644 index 00000000000..af40a081f35 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/2de10e77-c144-4e69-afb7-344e7127abd0_213.json @@ -0,0 +1,105 @@ +{ + "attributes": { + "author": [ + "Elastic", + "Austin Songer" + ], + "description": "Identifies the first occurrence of SSO, SAML, or federated authentication errors for a user. These errors may indicate token manipulation, SAML assertion tampering, or OAuth phishing attempts. Modern adversaries often target SSO mechanisms through token theft, SAML response manipulation, or exploiting federated authentication weaknesses rather than traditional brute force attacks.", + "false_positives": [ + "Initial SSO configuration issues or first-time federation setup errors for legitimate users may trigger this detection. Temporary federation service outages affecting multiple users simultaneously." + ], + "from": "now-9m", + "history_window_start": "now-10d", + "index": [ + "logs-o365.audit-*", + "filebeat-*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "M365 Identity Unusual SSO Authentication Errors for User", + "new_terms_fields": [ + "o365.audit.UserId", + "o365.audit.ErrorNumber" + ], + "note": "## Triage and analysis\n\n### Investigating M365 Identity Unusual SSO Authentication Errors for User\n\nSSO, SAML, and federated authentication mechanisms are critical infrastructure for modern identity access. Adversaries increasingly\ntarget these systems through token manipulation, SAML response tampering, OAuth phishing, and exploitation of federated trust\nrelationships rather than traditional credential brute forcing. This detection identifies when a user experiences SSO-related\nauthentication errors that are unusual for their typical behavior, which may indicate an attacker attempting to abuse stolen tokens or manipulate\nauthentication flows.\n\n### Possible investigation steps\n\n- Review the specific error code(s) in the `o365.audit.ErrorNumber` field to understand the nature of the authentication failure\n (e.g., token signature failure, SAML assertion tampering, cross-tenant token misuse). Reference Microsoft's AADSTS error codes\n at https://login.microsoftonline.com/error?code= for detailed descriptions.\n- Examine the source IP address and geolocation of the authentication attempt - compare against the user's typical login patterns.\n- Check for concurrent authentication activity from the same user - multiple SSO errors alongside successful logins may indicate\n token replay or session hijacking attempts.\n- Investigate recent OAuth application consent activity for this user - OAuth phishing campaigns often precede SSO manipulation attempts.\n- Review the target application or service principal being accessed during the failed authentication to identify potential attacker objectives.\n- Analyze the user's recent mailbox activity, particularly for phishing emails with OAuth consent links or suspicious authentication requests.\n- Check for any recent changes to the user's federation settings, registered devices, or authentication methods.\n- Correlate with Entra ID risky sign-in detections and risky user alerts for the same account.\n\n### False positive analysis\n\n- First-time SSO setup: Users configuring SSO access to a new federated application may encounter initial authentication errors.\n Validate whether the errors occurred during expected onboarding windows.\n- Federation service outages: Widespread SSO errors affecting multiple users simultaneously often indicate infrastructure issues\n rather than targeted attacks. Check for service health incidents in the same timeframe.\n- Certificate rotation: Federated authentication certificate renewals can temporarily cause signature validation errors. Verify\n if the errors align with planned certificate maintenance.\n- Legitimate cross-tenant access: Users with business relationships across multiple tenants may encounter cross-tenant policy\n errors during authorized access attempts.\n\n### Response and remediation\n\n- If token manipulation or SAML tampering is suspected, immediately revoke all active sessions and refresh tokens for the affected user.\n- Review and audit all OAuth application consents granted by the user - remove any suspicious or unrecognized applications.\n- Enable Conditional Access policies requiring compliant devices and MFA for SSO authentication if not already enforced.\n- If cross-tenant token misuse is detected, review and restrict external collaboration settings and cross-tenant access policies.\n- For SAML assertion or signature errors, validate the integrity of federation trust certificates and metadata.\n- Investigate whether the user's credentials have been compromised - enforce password reset if credential theft is suspected.\n- Review Entra ID audit logs for unusual application registrations, service principal modifications, or federation setting changes.\n- Escalate to the security operations team if evidence suggests active token theft, SAML Golden Ticket techniques, or OAuth phishing campaigns.", + "query": "event.dataset:o365.audit\n and event.provider:AzureActiveDirectory\n and event.category:authentication\n and o365.audit.ErrorNumber:(\n 20001 or 20012 or 20033 or 40008 or 40009 or 40015 or\n 50006 or 50008 or 50012 or 50013 or 50027 or 50048 or\n 50099 or 50132 or 75005 or 75008 or 75011 or 75016 or\n 81004 or 81009 or 81010 or 399284 or 500212 or 500213 or\n 700005 or 5000819\n )\n", + "references": [ + "https://techcommunity.microsoft.com/blog/microsoft-entra-blog/understanding-and-mitigating-golden-saml-attacks/4418864", + "https://www.semperis.com/blog/meet-silver-saml/" + ], + "related_integrations": [ + { + "package": "o365", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.category", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.provider", + "type": "keyword" + }, + { + "ecs": false, + "name": "o365.audit.ErrorNumber", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "2de10e77-c144-4e69-afb7-344e7127abd0", + "severity": "medium", + "tags": [ + "Domain: Identity", + "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" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0001", + "name": "Initial Access", + "reference": "https://attack.mitre.org/tactics/TA0001/" + }, + "technique": [ + { + "id": "T1078", + "name": "Valid Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/", + "subtechnique": [ + { + "id": "T1078.004", + "name": "Cloud Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/004/" + } + ] + }, + { + "id": "T1566", + "name": "Phishing", + "reference": "https://attack.mitre.org/techniques/T1566/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "new_terms", + "version": 213 + }, + "id": "2de10e77-c144-4e69-afb7-344e7127abd0_213", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/2e29e96a-b67c-455a-afe4-de6183431d0d_217.json b/packages/security_detection_engine/kibana/security_rule/2e29e96a-b67c-455a-afe4-de6183431d0d_217.json new file mode 100644 index 00000000000..8f427206445 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/2e29e96a-b67c-455a-afe4-de6183431d0d_217.json @@ -0,0 +1,163 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects PowerShell scripts that combines Win32 APIs for allocation/protection or process access (for example, VirtualAlloc/VirtualProtect/OpenProcess/AdjustTokenPrivileges/LoadLibrary/GetProcAddress) with injection or execution APIs (WriteProcessMemory/CreateRemoteThread/NtCreateThreadEx/QueueUserAPC/ResumeThread). Attackers use these API chains to inject code into remote processes and execute payloads in memory for defense evasion.", + "false_positives": [ + "Legitimate PowerShell scripts that make use of these functions." + ], + "filters": [ + { + "meta": { + "negate": true + }, + "query": { + "wildcard": { + "file.path": { + "case_insensitive": true, + "value": "?:\\\\ProgramData\\\\Microsoft\\\\Windows Defender Advanced Threat Protection\\\\DataCollection\\\\*" + } + } + } + } + ], + "from": "now-9m", + "index": [ + "winlogbeat-*", + "logs-windows.powershell*" + ], + "investigation_fields": { + "field_names": [ + "@timestamp", + "user.name", + "user.id", + "user.domain", + "powershell.file.script_block_text", + "powershell.file.script_block_id", + "powershell.sequence", + "powershell.total", + "file.path", + "file.directory", + "file.name", + "process.pid", + "host.name", + "host.id", + "powershell.file.script_block_length" + ] + }, + "language": "kuery", + "license": "Elastic License v2", + "name": "Potential Process Injection via PowerShell", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This guide was created by humans with the assistance of generative AI. While its contents have been manually curated to include the most valuable information, always validate assumptions and adjust procedures to match your internal runbooks and incident triage and response policies.\n\n### Investigating Potential Process Injection via PowerShell\n\nThis rule Detects PowerShell scripts that references a combination of Win32 APIs commonly used to open a target process, allocate or change memory protections, write data into another process, and execute it via a remote thread or APC. This behavior is frequently associated with process injection and in-memory payload execution on Windows hosts.\n\n#### Key alert fields to review\n\n- `user.name`, `user.domain`, `user.id`: Account execution context for correlation, prioritization, and scoping.\n- `host.name`, `host.id`: Host execution context for correlation, prioritization, and scoping.\n- `powershell.file.script_block_text`: Script block content that matched the detection logic.\n- `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`: Script block metadata to pivot to other fragments or reconstruct full script content when split across multiple events.\n- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file.\n- `powershell.file.script_block_length`: Script block length (size) context.\n\n#### Possible investigation steps\n\n- Review and preserve the script content:\n - Inspect `powershell.file.script_block_text` for the full API chain and surrounding logic (function definitions, payload construction, and execution flow).\n - If the content is split across multiple events, reconstruct it by grouping on `powershell.file.script_block_id`, ordering by `powershell.sequence`, and validating completeness with `powershell.total`. Preserve the reconstructed content for follow-up analysis.\n - Use `powershell.file.script_block_length` to help gauge whether the script is a small launcher or a larger framework with embedded payloads.\n\n- Identify the injection technique and likely target:\n - Determine which execution primitive is being used (for example, `CreateRemoteThread`, `NtCreateThreadEx`, `QueueUserAPC`, or thread `SuspendThread`/`ResumeThread` patterns) and whether it suggests immediate or deferred execution.\n - Look for how the target process is selected (process name strings, PID variables, or process enumeration logic) and capture any referenced process names or IDs for scoping.\n - Note any privilege manipulation via `OpenProcessToken` and `AdjustTokenPrivileges`, which can indicate attempts to access protected processes.\n\n- Assess how native APIs are being invoked:\n - Identify dynamic resolution patterns such as `LoadLibrary*`/`LdrLoadDll` with `GetProcAddress`, which are commonly used to avoid static imports and hinder analysis.\n - If `GetDelegateForFunctionPointer` is present, review the surrounding text for delegate definitions and indirect invocation logic.\n\n- Validate execution context and script provenance:\n - Review `user.name`, `user.domain`, and `user.id` for signs of unusual execution (unexpected account type, first-time observation on the host, or activity outside expected administrative workflows).\n - Review `host.name` and `host.id` to understand the asset impacted and whether the behavior aligns with the host's role in your environment.\n - If `file.path`, `file.directory`, or `file.name` are populated, assess whether the script originated from a controlled location and naming convention, or from a user-writable or temporary location.\n\n- Scope related PowerShell activity:\n - On the same `host.id` and `user.id`, review additional script block events near `@timestamp` to identify staging actions that commonly bracket injection attempts (download, decode/decrypt, reflective loading, or cleanup).\n - Search for repeated use of distinctive substrings from `powershell.file.script_block_text` across other hosts or users to determine prevalence and potential reuse.\n\n- Correlate with adjacent host telemetry (if available in your environment):\n - Pivot from `host.name` and `@timestamp` to process activity to identify the PowerShell host process, its parent process, and any processes that may have been targeted for injection.\n - Review network activity from the same `host.name` around the alert time for potential payload retrieval, command-and-control, or lateral movement.\n - Review file activity related to `file.path` (when present) and for any new or modified scripts or binaries referenced by the script block.\n\n- Make a disposition:\n - Treat as higher risk when the script combines process access (`OpenProcess`), memory modification (`VirtualAlloc*`/`VirtualProtect`), and execution (`CreateRemoteThread`/`NtCreateThreadEx`/`QueueUserAPC`), especially when coupled with privilege adjustment or dynamic API resolution.\n - Treat as lower risk only when there is a clear, documented administrative or testing justification tied to the same `user.id`, `host.id`, and script origin.\n\n### False positive analysis\n\n- Legitimate PowerShell can use Win32 API interop for diagnostics, automation, or compatibility work; however, the combination of remote memory operations and remote execution APIs is uncommon in routine administration.\n- Developer tooling or monitoring frameworks may load libraries or resolve symbols dynamically; validate that the script content aligns with expected tool behavior and that the script origin (`file.path`/`file.name`) is consistent and controlled.\n\n### Response and remediation\n\n- If the activity is confirmed or strongly suspected malicious:\n - Contain the affected host to prevent follow-on actions and lateral movement.\n - Preserve evidence by retaining the reconstructed `powershell.file.script_block_text` (and associated `powershell.file.script_block_id`) and recording the alert context (`user.*`, `host.*`, and `file.*` where present).\n - Identify the intended injection target from the script content and investigate that process and its recent activity for signs of compromise or anomalous behavior.\n - Review the associated user account activity for additional suspicious behavior on the same host and other hosts, and take appropriate account actions if compromise is suspected.\n - Hunt for the same script patterns across the environment using stable substrings from `powershell.file.script_block_text` and common `file.path`/`file.name` values, and remediate any additional impacted systems.\n\n- If the activity is verified as benign:\n - Document the script purpose, owner, expected execution context (hosts and accounts), and expected script origin (`file.path`/`file.name`).\n - Consider controlled rule tuning using stable, high-confidence identifiers from the verified benign workflow to reduce repeat alerts while maintaining coverage for new or unauthorized variants.\n", + "query": "event.category:process and host.os.type:windows and\n powershell.file.script_block_text : (\n (VirtualAlloc or VirtualAllocEx or VirtualProtect or LdrLoadDll or LoadLibrary or LoadLibraryA or\n LoadLibraryEx or GetProcAddress or OpenProcess or OpenProcessToken or AdjustTokenPrivileges) and\n (WriteProcessMemory or CreateRemoteThread or NtCreateThreadEx or CreateThread or QueueUserAPC or\n SuspendThread or ResumeThread or GetDelegateForFunctionPointer)\n ) and not \n file.directory: (\n \"C:\\ProgramData\\Microsoft\\Windows Defender Advanced Threat Protection\\SenseCM\" or\n \"C:\\ProgramData\\Microsoft\\Windows Defender Advanced Threat Protection\\Downloads\"\n )\n", + "references": [ + "https://github.com/EmpireProject/Empire/blob/master/data/module_source/management/Invoke-PSInject.ps1", + "https://github.com/EmpireProject/Empire/blob/master/data/module_source/management/Invoke-ReflectivePEInjection.ps1", + "https://github.com/BC-SECURITY/Empire/blob/master/empire/server/data/module_source/credentials/Invoke-Mimikatz.ps1", + "https://www.elastic.co/security-labs/detect-credential-access" + ], + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.category", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.directory", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_text", + "type": "unknown" + } + ], + "risk_score": 73, + "rule_id": "2e29e96a-b67c-455a-afe4-de6183431d0d", + "setup": "## Setup\n\nPowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104).\nSetup instructions: https://ela.st/powershell-logging-setup\n", + "severity": "high", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Tactic: Execution", + "Resources: Investigation Guide", + "Data Source: PowerShell Logs" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1055", + "name": "Process Injection", + "reference": "https://attack.mitre.org/techniques/T1055/", + "subtechnique": [ + { + "id": "T1055.001", + "name": "Dynamic-link Library Injection", + "reference": "https://attack.mitre.org/techniques/T1055/001/" + }, + { + "id": "T1055.002", + "name": "Portable Executable Injection", + "reference": "https://attack.mitre.org/techniques/T1055/002/" + } + ] + } + ] + }, + { + "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": "T1106", + "name": "Native API", + "reference": "https://attack.mitre.org/techniques/T1106/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 217 + }, + "id": "2e29e96a-b67c-455a-afe4-de6183431d0d_217", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/32c5cf9c-2ef8-4e87-819e-5ccb7cd18b14_319.json b/packages/security_detection_engine/kibana/security_rule/32c5cf9c-2ef8-4e87-819e-5ccb7cd18b14_319.json new file mode 100644 index 00000000000..18d5b1a1f96 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/32c5cf9c-2ef8-4e87-819e-5ccb7cd18b14_319.json @@ -0,0 +1,114 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies execution from a directory masquerading as the Windows Program Files directories. These paths are trusted and usually host trusted third party programs. An adversary may leverage masquerading, along with low privileges to bypass detections allowlisting those folders.", + "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": "Program Files Directory Masquerading", + "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 Program Files Directory Masquerading\n\nThe Program Files directories in Windows are trusted locations for legitimate software. Adversaries may exploit this trust by creating similarly named directories to execute malicious files, bypassing security measures. The detection rule identifies suspicious executions from these masquerading paths, excluding known legitimate directories, to flag potential threats. This helps in identifying defense evasion tactics used by attackers.\n\n### Possible investigation steps\n\n- Review the process executable path to confirm if it matches any known masquerading patterns, such as unexpected directories containing \"Program Files\" in their path.\n- Check the parent process of the suspicious executable to determine how it was launched and assess if the parent process is legitimate or potentially malicious.\n- Investigate the user account associated with the process execution to determine if it has low privileges and if the activity aligns with typical user behavior.\n- Correlate the event with other security logs or alerts from data sources like Microsoft Defender for Endpoint or Sysmon to identify any related suspicious activities or patterns.\n- Examine the file hash of the executable to see if it matches known malware signatures or if it has been flagged in threat intelligence databases.\n- Assess the network activity associated with the process to identify any unusual outbound connections that could indicate data exfiltration or command-and-control communication.\n\n### False positive analysis\n\n- Legitimate software installations or updates may create temporary directories resembling Program Files paths. Users can monitor installation logs and exclude these specific paths if they are verified as part of a legitimate process.\n- Some enterprise applications may use custom directories that mimic Program Files for compatibility reasons. IT administrators should document these paths and add them to the exclusion list to prevent false alerts.\n- Development environments might create test directories with similar naming conventions. Developers should ensure these paths are excluded during active development phases to avoid unnecessary alerts.\n- Security tools or scripts that perform regular checks or updates might execute from non-standard directories. Verify these tools and add their execution paths to the exception list if they are confirmed safe.\n- Backup or recovery software might temporarily use directories that resemble Program Files for storing executable files. Confirm the legitimacy of these operations and exclude the paths if they are part of routine backup processes.\n\n### Response and remediation\n\n- Isolate the affected system from the network to prevent further spread of the potential threat and to contain any malicious activity.\n- Terminate any suspicious processes identified as executing from masquerading directories to halt any ongoing malicious actions.\n- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious files or remnants.\n- Review and restore any altered system configurations or settings to their original state to ensure system integrity.\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- Implement additional monitoring on the affected system and similar environments to detect any recurrence of the threat or similar tactics.\n- Update security policies and access controls to prevent unauthorized creation of directories that mimic trusted paths, enhancing defenses against similar masquerading attempts.", + "query": "process where host.os.type == \"windows\" and event.type == \"start\" and\n process.executable : (\n \"C:\\\\*Program Files*\\\\*.exe\",\n \"\\\\Device\\\\HarddiskVolume*\\\\*Program Files*\\\\*.exe\"\n ) and\n not process.executable : (\n \"?:\\\\Program Files\\\\*.exe\",\n \"?:\\\\Program Files (x86)\\\\*.exe\",\n \"?:\\\\Users\\\\*.exe\",\n \"?:\\\\ProgramData\\\\*.exe\",\n \"?:\\\\Windows\\\\Downloaded Program Files\\\\*.exe\",\n \"?:\\\\Windows\\\\Temp\\\\.opera\\\\????????????\\\\CProgram?FilesOpera*\\\\*.exe\",\n \"?:\\\\Windows\\\\Temp\\\\.opera\\\\????????????\\\\CProgram?Files?(x86)Opera*\\\\*.exe\",\n\n /* NT Object Paths */\n \"\\\\Device\\\\HarddiskVolume*\\\\Program Files\\\\*.exe\",\n \"\\\\Device\\\\HarddiskVolume*\\\\Program Files (x86)\\\\*.exe\",\n \"\\\\Device\\\\HarddiskVolume*\\\\Users\\\\*.exe\",\n \"\\\\Device\\\\HarddiskVolume*\\\\ProgramData\\\\*.exe\",\n \"\\\\Device\\\\HarddiskVolume*\\\\Windows\\\\Downloaded Program Files\\\\*.exe\"\n )\n", + "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": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.executable", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "32c5cf9c-2ef8-4e87-819e-5ccb7cd18b14", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: Elastic Endgame", + "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", + "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/", + "subtechnique": [ + { + "id": "T1036.005", + "name": "Match Legitimate Resource Name or Location", + "reference": "https://attack.mitre.org/techniques/T1036/005/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 319 + }, + "id": "32c5cf9c-2ef8-4e87-819e-5ccb7cd18b14_319", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/34fde489-94b0-4500-a76f-b8a157cf9269_111.json b/packages/security_detection_engine/kibana/security_rule/34fde489-94b0-4500-a76f-b8a157cf9269_111.json new file mode 100644 index 00000000000..7ef39323144 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/34fde489-94b0-4500-a76f-b8a157cf9269_111.json @@ -0,0 +1,139 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects network events that may indicate the use of Telnet traffic. Telnet is commonly used by system administrators to remotely control older or embedded systems using the command line shell. It should almost never be directly exposed to the Internet, as it is frequently targeted and exploited by threat actors as an initial access or backdoor vector. As a plain-text protocol, it may also expose usernames and passwords to anyone capable of observing the traffic.", + "false_positives": [ + "IoT (Internet of Things) devices and networks may use telnet and can be excluded if desired. Some business work-flows may use Telnet for administration of older devices. These often have a predictable behavior. Telnet activity involving an unusual source or destination may be more suspicious. Telnet activity involving a production server that has no known associated Telnet work-flow or business requirement is often suspicious." + ], + "from": "now-9m", + "index": [ + "packetbeat-*", + "auditbeat-*", + "filebeat-*", + "logs-network_traffic.*", + "logs-panw.panos*", + "logs-fortinet_fortigate.log-*", + "logs-sonicwall_firewall.log-*", + "logs-suricata.*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "Accepted Default Telnet Port Connection", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Accepted Default Telnet Port Connection\n\nTelnet, a protocol for remote command-line access, is often used in legacy systems. Its lack of encryption makes it vulnerable, allowing attackers to intercept credentials or use it as a backdoor. The detection rule identifies unencrypted Telnet traffic on port 23, flagging connections that bypass typical security measures, thus highlighting potential unauthorized access attempts.\n\n### Possible investigation steps\n\n- Review the network traffic logs to identify the source IP address associated with the Telnet connection on port 23. Determine if the source IP is internal or external to the organization.\n- Check the destination IP address to ascertain if it belongs to a critical system or a legacy device that might still use Telnet for management purposes.\n- Investigate the timeline of the connection event to see if there are any patterns or repeated attempts, which could indicate a persistent threat or automated attack.\n- Analyze any associated user accounts or credentials used during the Telnet session to verify if they are legitimate and authorized for remote access.\n- Correlate the Telnet connection event with other security alerts or logs to identify any related suspicious activities, such as failed login attempts or unusual data transfers.\n- Assess the network segment where the Telnet traffic was detected to determine if it is appropriately segmented and secured against unauthorized access.\n- Consider implementing network security measures, such as disabling Telnet on devices or replacing it with secure alternatives like SSH, to prevent future unauthorized access attempts.\n\n### False positive analysis\n\n- Legacy systems or devices that require Telnet for management may trigger alerts. To manage this, create exceptions for specific IP addresses or subnets known to host these systems.\n- Internal network monitoring tools that use Telnet for legitimate purposes might be flagged. Identify these tools and exclude their traffic from the rule to prevent unnecessary alerts.\n- Lab environments or test networks where Telnet is used for educational or testing purposes can cause false positives. Implement network segmentation and apply exceptions to these environments to reduce noise.\n- Automated scripts or maintenance tasks that utilize Telnet for routine operations may be mistakenly identified. Document these tasks and whitelist their associated traffic patterns to avoid false 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- Terminate any active Telnet sessions on the affected system to disrupt potential attacker activities.\n- Conduct a thorough review of system logs and network traffic to identify any unauthorized access or data manipulation that may have occurred.\n- Change all credentials that may have been exposed through Telnet traffic, prioritizing those with administrative privileges.\n- Implement network segmentation to restrict Telnet access to only necessary internal systems, ensuring it is not exposed to the internet.\n- Deploy encryption protocols such as SSH to replace Telnet for remote command-line access, enhancing security for remote management.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the need for additional security measures.", + "query": "(event.dataset:(fortinet_fortigate.log or network_traffic.flow\n or sonicwall_firewall.log or suricata.eve or panw.panos)\n or event.category:(network or network_traffic))\n and event.type:(connection and not end) and not event.action:(\n flow_dropped or flow_denied or denied or deny or\n flow_terminated or timeout or Reject or network_flow)\n and destination.port:23\n", + "related_integrations": [ + { + "package": "network_traffic", + "version": "^1.1.0" + }, + { + "package": "panw", + "version": "^5.0.0" + }, + { + "package": "fortinet_fortigate", + "version": "^1.0.0" + }, + { + "package": "sonicwall_firewall", + "version": "^1.0.0" + }, + { + "package": "suricata", + "version": "^2.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "destination.port", + "type": "long" + }, + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.category", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "34fde489-94b0-4500-a76f-b8a157cf9269", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "Use Case: Threat Detection", + "Tactic: Command and Control", + "Tactic: Lateral Movement", + "Tactic: Initial Access", + "Data Source: PAN-OS", + "Data Source: Fortinet", + "Data Source: SonicWall", + "Data Source: Suricata", + "Resources: Investigation Guide" + ], + "threat": [ + { + "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": "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": "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/" + } + ] + } + ], + "timeline_id": "300afc76-072d-4261-864d-4149714bf3f1", + "timeline_title": "Comprehensive Network Timeline", + "timestamp_override": "event.ingested", + "type": "query", + "version": 111 + }, + "id": "34fde489-94b0-4500-a76f-b8a157cf9269_111", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/36c48a0c-c63a-4cbc-aee1-8cac87db31a9_8.json b/packages/security_detection_engine/kibana/security_rule/36c48a0c-c63a-4cbc-aee1-8cac87db31a9_8.json new file mode 100644 index 00000000000..eb029506201 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/36c48a0c-c63a-4cbc-aee1-8cac87db31a9_8.json @@ -0,0 +1,63 @@ +{ + "attributes": { + "anomaly_threshold": 70, + "author": [ + "Elastic" + ], + "description": "A machine learning job has detected unusually high number of process arguments in an RDP session. Executing sophisticated attacks such as lateral movement can involve the use of complex commands, obfuscation mechanisms, redirection and piping, which in turn increases the number of arguments in a command.", + "from": "now-12h", + "interval": "15m", + "license": "Elastic License v2", + "machine_learning_job_id": "lmd_high_mean_rdp_process_args", + "name": "High Mean of Process Arguments in an RDP Session", + "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 Mean of Process Arguments in an RDP Session\n\nRemote Desktop Protocol (RDP) facilitates remote access to systems, often targeted by adversaries for lateral movement. Attackers may exploit RDP by executing complex commands with numerous arguments to obfuscate their actions. The detection rule leverages machine learning to identify anomalies in process arguments, flagging potential misuse indicative of sophisticated attacks.\n\n### Possible investigation steps\n\n- Review the specific RDP session details, including the source and destination IP addresses, to identify any unusual or unauthorized access patterns.\n- Analyze the process arguments flagged by the machine learning model to determine if they include known malicious commands or patterns indicative of obfuscation or redirection.\n- Check the user account associated with the RDP session for any signs of compromise, such as recent password changes or login attempts from unusual locations.\n- Correlate the alert with other security events or logs, such as firewall logs or intrusion detection system alerts, to identify any related suspicious activities or lateral movement attempts.\n- Investigate the historical behavior of the involved systems and users to determine if the high number of process arguments is an anomaly or part of a regular pattern.\n\n### False positive analysis\n\n- Routine administrative tasks may generate a high number of process arguments, such as batch scripts or automated maintenance operations. Users can create exceptions for known scripts or processes that are regularly executed by trusted administrators.\n- Software updates or installations often involve complex commands with multiple arguments. To mitigate false positives, users should whitelist update processes from trusted vendors.\n- Monitoring and management tools that perform extensive logging or diagnostics can trigger this rule. Users should identify and exclude these tools if they are verified as non-threatening.\n- Custom applications or scripts developed in-house may use numerous arguments for configuration purposes. Users should document and exclude these applications if they are part of normal business operations.\n- Scheduled tasks that run during off-hours might appear suspicious due to their complexity. Users can adjust the rule to ignore these tasks if they are part of a regular, approved schedule.\n\n### Response and remediation\n\n- Isolate the affected system from the network to prevent further lateral movement and potential data exfiltration.\n- Terminate any suspicious RDP sessions and associated processes that exhibit high numbers of arguments to halt ongoing malicious activities.\n- Conduct a thorough review of the affected system's event logs and process execution history to identify any unauthorized access or changes made during the RDP session.\n- Reset credentials for any accounts that were accessed during the suspicious RDP session to prevent unauthorized access using compromised credentials.\n- Apply security patches and updates to the affected system and any other systems within the network to mitigate vulnerabilities that could be exploited for similar attacks.\n- Enhance monitoring and logging for RDP sessions across the network to detect and respond to similar anomalies more quickly in the future.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems have been compromised.", + "references": [ + "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html", + "https://docs.elastic.co/en/integrations/lmd", + "https://www.elastic.co/blog/detecting-lateral-movement-activity-a-new-kibana-integration", + "https://www.elastic.co/blog/remote-desktop-protocol-connections-elastic-security" + ], + "related_integrations": [ + { + "package": "lmd", + "version": "^2.0.0" + }, + { + "package": "endpoint", + "version": "^8.2.0" + } + ], + "risk_score": 21, + "rule_id": "36c48a0c-c63a-4cbc-aee1-8cac87db31a9", + "setup": "## Setup\n\nThis rule requires the `host.ip` field to be populated.\nFor **Elastic Defend** events on versions **8.18 and above**, this field is **disabled by default**.\n\nIf you are using **Elastic Defend**, ensure host IP collection is enabled by following the configuration steps in the\n[helper guide](https://www.elastic.co/docs/solutions/security/configure-elastic-defend/configure-data-volume-for-elastic-endpoint#host-fields).\n\nThe rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration.\n\n### Lateral Movement Detection Setup\nThe Lateral Movement Detection integration detects lateral movement activity by identifying abnormalities in file and Windows RDP events. Anomalies are detected using Elastic's Anomaly Detection feature.\n\n#### Prerequisite Requirements:\n- Fleet is required for Lateral Movement Detection.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n- Windows RDP process events collected by the [Elastic Defend](https://docs.elastic.co/en/integrations/endpoint) integration.\n- To install Elastic Defend, refer to the [documentation](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n\n#### The following steps should be executed to install assets associated with the Lateral Movement Detection integration:\n- Go to the Kibana homepage. Under Management, click Integrations.\n- In the query bar, search for Lateral Movement Detection and select the integration to see more details about it.\n- Follow the instructions under the **Installation** section.\n- For this rule to work, complete the instructions through **Add preconfigured anomaly detection jobs**.\n", + "severity": "low", + "tags": [ + "Use Case: Lateral Movement Detection", + "Rule Type: ML", + "Rule Type: Machine Learning", + "Tactic: Lateral Movement", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0008", + "name": "Lateral Movement", + "reference": "https://attack.mitre.org/tactics/TA0008/" + }, + "technique": [ + { + "id": "T1210", + "name": "Exploitation of Remote Services", + "reference": "https://attack.mitre.org/techniques/T1210/" + } + ] + } + ], + "type": "machine_learning", + "version": 8 + }, + "id": "36c48a0c-c63a-4cbc-aee1-8cac87db31a9_8", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/37cb6756-8892-4af3-a6bd-ddc56db0069d_4.json b/packages/security_detection_engine/kibana/security_rule/37cb6756-8892-4af3-a6bd-ddc56db0069d_4.json new file mode 100644 index 00000000000..d12ac7e722a --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/37cb6756-8892-4af3-a6bd-ddc56db0069d_4.json @@ -0,0 +1,135 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "LSA protecton is provided to prevent nonprotected processes from reading memory and injecting code. This feature provides added security for the credentials that LSA stores and manages. Adversaries may modify the RunAsPPL registry and wait or initiate a system restart to enable Lsass credentials access.", + "from": "now-9m", + "index": [ + "winlogbeat-*", + "logs-endpoint.events.registry-*", + "logs-windows.sysmon_operational-*", + "endgame-*", + "logs-m365_defender.event-*", + "logs-sentinel_one_cloud_funnel.*", + "logs-crowdstrike.fdr*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Disabling Lsa Protection via Registry Modification", + "note": "## Triage and analysis\n\n### Investigating Disabling Lsa Protection via Registry Modification\n\nFor more information about the Lsa Protection and how it works, check the [official Microsoft docs page](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection).\n\nAttackers may disable Lsa protection to access Lsass memory for credentals. This rule identifies RunAsPPL registry value modifications.\n\n#### Possible investigation steps\n\n- Verify the context of the change and if it's related to a planned system administration activity.\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- Inspect the host for suspicious or abnormal behaviors in the alert timeframe.\n- Investigate abnormal behaviors observed by the subject process such as network connections, registry or file modifications, and any spawned child processes.\n\n### False positive analysis\n\n- Approved changes to relax the Lsa protection for compatibility with third party solutions such as authentication plugins or alike.\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- Restore UAC settings to the desired state.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.\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- 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": "registry where host.os.type == \"windows\" and event.type == \"change\" and\n registry.data.strings != null and process.name != null and\n registry.value : \"RunAsPPL\" and\n registry.path : \"*\\\\SYSTEM\\\\*ControlSet*\\\\Control\\\\Lsa\\\\RunAsPPL\" and\n not registry.data.strings : (\"1\", \"0x00000001\", \"2\", \"0x00000002\") and\n not process.executable : \"?:\\\\Windows\\\\System32\\\\SecurityHealthService.exe\"\n", + "references": [ + "https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection" + ], + "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" + }, + { + "package": "crowdstrike", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.executable", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "registry.data.strings", + "type": "wildcard" + }, + { + "ecs": true, + "name": "registry.path", + "type": "keyword" + }, + { + "ecs": true, + "name": "registry.value", + "type": "keyword" + } + ], + "risk_score": 73, + "rule_id": "37cb6756-8892-4af3-a6bd-ddc56db0069d", + "severity": "high", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Resources: Investigation Guide", + "Data Source: Elastic Endgame", + "Data Source: Elastic Defend", + "Data Source: Sysmon", + "Data Source: Microsoft Defender for Endpoint", + "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": "T1112", + "name": "Modify Registry", + "reference": "https://attack.mitre.org/techniques/T1112/" + }, + { + "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": 4 + }, + "id": "37cb6756-8892-4af3-a6bd-ddc56db0069d_4", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/38948d29-3d5d-42e3-8aec-be832aaaf8eb_210.json b/packages/security_detection_engine/kibana/security_rule/38948d29-3d5d-42e3-8aec-be832aaaf8eb_210.json deleted file mode 100644 index 01a0cf69ce5..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/38948d29-3d5d-42e3-8aec-be832aaaf8eb_210.json +++ /dev/null @@ -1,110 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies the use of osascript to execute scripts via standard input that may prompt a user with a rogue dialog for credentials.", - "from": "now-9m", - "index": [ - "logs-endpoint.events.process*" - ], - "language": "eql", - "license": "Elastic License v2", - "name": "Prompt for Credentials with OSASCRIPT", - "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 Prompt for Credentials with OSASCRIPT\n\nOSASCRIPT is a macOS utility that allows the execution of AppleScript and other OSA language scripts. Adversaries may exploit it to display deceptive dialogs prompting users for credentials, mimicking legitimate requests. The detection rule identifies suspicious OSASCRIPT usage by monitoring specific command patterns and excluding known legitimate processes, thereby flagging potential credential theft attempts.\n\n### Possible investigation steps\n\n- Review the process command line to confirm if the osascript command includes suspicious patterns like \"display dialog\" with \"password\" or \"passphrase\" to determine if it is attempting to prompt for credentials.\n- Check the parent process executable to see if it matches any known legitimate applications or services, such as those listed in the exclusion criteria, to rule out false positives.\n- Investigate the user account associated with the process to determine if it is a privileged account or if there is any unusual activity associated with it.\n- Examine the process execution context, including the effective parent executable, to identify if the osascript was executed by a legitimate management tool or script.\n- Look for any other related alerts or logs around the same timeframe to identify if this is part of a broader attack or isolated incident.\n- Assess the risk and impact by determining if any credentials were potentially compromised and if further containment or remediation actions are necessary.\n\n### False positive analysis\n\n- Legitimate administrative scripts using osascript may trigger alerts if they include dialog prompts for passwords or passphrases. To manage this, identify and exclude these scripts by adding their specific command lines or parent executables to the exception list.\n- Processes initiated by trusted applications like JAMF or Karabiner-Elements can be mistakenly flagged. Ensure these applications are included in the exclusion list to prevent unnecessary alerts.\n- Scheduled maintenance tasks that use osascript for legitimate purposes might be misidentified. Review and exclude these tasks by specifying their user IDs or command line patterns in the detection rule exceptions.\n- Custom scripts executed by system administrators for routine operations may appear suspicious. Document these scripts and add them to the exclusion criteria to avoid false positives.\n- Terminal-based automation tools that interact with osascript could be incorrectly flagged. Verify these tools and include their paths in the exclusion list to reduce false alerts.\n\n### Response and remediation\n\n- Immediately isolate the affected macOS device from the network to prevent further unauthorized access or data exfiltration.\n- Terminate the suspicious osascript process identified by the alert to stop any ongoing credential theft attempts.\n- Conduct a thorough review of the affected system's recent activity logs to identify any unauthorized access or changes made during the incident.\n- Reset credentials for any accounts that may have been compromised, ensuring that new passwords are strong and unique.\n- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected.\n- Implement additional monitoring on the affected system and similar endpoints to detect any recurrence of the threat.\n- Review and update endpoint security configurations to block unauthorized script execution and enhance detection capabilities for similar threats in the future.", - "query": "process where event.action == \"exec\" and host.os.type == \"macos\" and\n process.name : \"osascript\" and process.args : \"-e\" and process.command_line : (\"*osascript*display*dialog*password*\", \"*osascript*display*dialog*passphrase*\") and\n not (process.parent.executable : \"/usr/bin/sudo\" and process.command_line : \"*Encryption Key Escrow*\") and\n not (process.command_line : \"*-e with timeout of 3600 seconds*\" and user.id == \"0\" and process.parent.executable : \"/bin/bash\") and\n not process.Ext.effective_parent.executable : (\"/usr/local/jamf/*\",\n \"/Applications/Karabiner-Elements.app/Contents/MacOS/Karabiner-Elements\",\n \"/System/Applications/Utilities/Terminal.app/Contents/MacOS/Terminal\",\n \"/Library/Application Support/JAMF/Jamf.app/Contents/MacOS/JamfDaemon.app/Contents/MacOS/JamfDaemon\",\n \"/Library/Application Support/JAMF/Jamf.app/Contents/MacOS/JamfManagementService.app/Contents/MacOS/JamfManagementService\")\n", - "references": [ - "https://github.com/EmpireProject/EmPyre/blob/master/lib/modules/collection/osx/prompt.py", - "https://ss64.com/osx/osascript.html" - ], - "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": false, - "name": "process.Ext.effective_parent.executable", - "type": "unknown" - }, - { - "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": "user.id", - "type": "keyword" - } - ], - "risk_score": 73, - "rule_id": "38948d29-3d5d-42e3-8aec-be832aaaf8eb", - "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 macOS 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, for MacOS it is recommended to select \"Traditional Endpoints\".\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/current/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: macOS", - "Use Case: Threat Detection", - "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": "T1056", - "name": "Input Capture", - "reference": "https://attack.mitre.org/techniques/T1056/", - "subtechnique": [ - { - "id": "T1056.002", - "name": "GUI Input Capture", - "reference": "https://attack.mitre.org/techniques/T1056/002/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "eql", - "version": 210 - }, - "id": "38948d29-3d5d-42e3-8aec-be832aaaf8eb_210", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/3c59d2e1-8ca1-4f13-b2ac-f4bb99ff69d7_1.json b/packages/security_detection_engine/kibana/security_rule/3c59d2e1-8ca1-4f13-b2ac-f4bb99ff69d7_1.json new file mode 100644 index 00000000000..d1c529fc7c2 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/3c59d2e1-8ca1-4f13-b2ac-f4bb99ff69d7_1.json @@ -0,0 +1,114 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects attempts to disassociate or manipulate Amazon GuardDuty member accounts within an AWS organization. In multi-account GuardDuty deployments, a delegated administrator account aggregates findings from member accounts. Adversaries may attempt to disassociate member accounts, delete member relationships, stop monitoring members, or delete pending invitations to break this centralized visibility. These actions can be precursors to or alternatives for deleting GuardDuty detectors entirely, allowing attackers to operate undetected in member accounts while the administrator account loses visibility. This rule identifies successful API calls that manipulate GuardDuty member relationships, which are rare in normal operations and warrant immediate investigation.", + "false_positives": [ + "GuardDuty member relationships may be modified during legitimate organizational changes such as account migrations, security architecture restructuring, or delegated administrator transitions. Verify whether the user identity and timing align with approved change management processes. If this is expected administrative activity, 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 GuardDuty Member Account Manipulation", + "note": "## Triage and analysis\n\n### Investigating AWS GuardDuty Member Account Manipulation\n\nIn AWS Organizations with GuardDuty enabled, a delegated administrator account receives and aggregates security findings from all member accounts. This centralized visibility is critical for detecting threats across the organization. Adversaries who compromise a member account may attempt to break this relationship to operate without triggering alerts visible to the security team.\n\nThis rule detects several API actions that manipulate GuardDuty member relationships:\n- `DisassociateFromMasterAccount` / `DisassociateFromAdministratorAccount`: Member account breaks its connection to the administrator\n- `DeleteMembers`: Administrator removes member accounts from GuardDuty\n- `StopMonitoringMembers`: Administrator stops monitoring specific member accounts without fully removing them\n- `DeleteInvitations`: Member account deletes pending invitations, preventing association\n\nThese actions are extremely rare in normal operations and can indicate either a compromised account or an attacker preparing to disable GuardDuty entirely.\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 performed the action.\n - Determine whether the action originated from a member account (disassociation) or the administrator account (deletion/stop monitoring).\n\n- **Review request context**\n - Check `aws.cloudtrail.request_parameters` to identify which member accounts were affected.\n - Determine the scope: single account or multiple accounts targeted.\n\n- **Analyze source and access patterns**\n - Review `source.ip` and `user_agent.original` for anomalous access patterns.\n - Check if the action occurred outside normal business hours or maintenance windows.\n\n- **Correlate with related activity**\n - Search for subsequent `DeleteDetector` API calls in the affected member accounts.\n - Look for other defense evasion indicators: CloudTrail modifications, Config rule deletions, Security Hub changes.\n - Check for privilege escalation or credential access events preceding this action.\n\n- **Verify business justification**\n - Confirm with the identified user or team whether there was a legitimate organizational change.\n - Check for related change tickets or migration documentation.\n\n### False positive analysis\n\n- **Organizational restructuring**\n - Member relationships may change during account migrations or delegated administrator transitions.\n - Validate against documented organizational changes.\n\n- **Account decommissioning**\n - Accounts being retired may be removed from GuardDuty before closure.\n - Confirm this aligns with account lifecycle management processes.\n\n### Response and remediation\n\n- **Immediate containment**\n - If unauthorized, immediately re-associate the affected member accounts with the administrator.\n - For `StopMonitoringMembers`, use `StartMonitoringMembers` to restore visibility.\n\n- **Investigation**\n - Audit the affected member accounts for suspicious activity during the visibility gap.\n - Review CloudTrail for any actions taken while GuardDuty monitoring was disrupted.\n\n- **Hardening**\n - Restrict `guardduty:DisassociateFromAdministratorAccount`, `guardduty:DeleteMembers`, and related permissions.\n - Use SCPs to prevent member accounts from disassociating from GuardDuty administrators.\n - Implement Security Hub controls to detect changes to GuardDuty organization configuration.\n\n### Additional information\n- **[AWS GuardDuty Multi-Account Documentation](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_accounts.html)**\n- **[AWS IR Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/)**\n- **[AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs)**\n", + "query": "event.dataset: \"aws.cloudtrail\"\n and event.provider: \"guardduty.amazonaws.com\"\n and event.action: (\n \"DisassociateFromAdministratorAccount\" or\n \"DeleteMembers\" or\n \"StopMonitoringMembers\" or\n \"DeleteInvitations\" or\n \"DisassociateMembers\"\n )\n and event.outcome: \"success\"\n", + "references": [ + "https://docs.aws.amazon.com/guardduty/latest/APIReference/API_DisassociateFromAdministratorAccount.html", + "https://docs.aws.amazon.com/guardduty/latest/APIReference/API_DeleteMembers.html", + "https://docs.aws.amazon.com/guardduty/latest/APIReference/API_StopMonitoringMembers.html", + "https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_accounts.html", + "https://permiso.io/blog/lucr-3-scattered-spider-getting-saas-y-in-the-cloud" + ], + "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": "3c59d2e1-8ca1-4f13-b2ac-f4bb99ff69d7", + "severity": "medium", + "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": 1 + }, + "id": "3c59d2e1-8ca1-4f13-b2ac-f4bb99ff69d7_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/3d3aa8f9-12af-441f-9344-9f31053e316d_211.json b/packages/security_detection_engine/kibana/security_rule/3d3aa8f9-12af-441f-9344-9f31053e316d_211.json new file mode 100644 index 00000000000..4a57b5b5206 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/3d3aa8f9-12af-441f-9344-9f31053e316d_211.json @@ -0,0 +1,163 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "building_block_type": "default", + "description": "Identifies PowerShell script block content that clears Windows event logs using Clear-EventLog, Remove-EventLog, or EventLogSession/EventLog Clear methods. Attackers clear local logs to evade detection and destroy forensic evidence.", + "filters": [ + { + "meta": { + "negate": true + }, + "query": { + "wildcard": { + "file.path": { + "case_insensitive": true, + "value": "?:\\\\Windows\\\\system32\\\\WindowsPowerShell\\\\v1.0\\\\Modules\\\\Microsoft.PowerShell.Management\\\\*.psd1" + } + } + } + }, + { + "meta": { + "negate": true + }, + "query": { + "wildcard": { + "file.path": { + "case_insensitive": true, + "value": "?:\\\\Program Files\\\\Microsoft Monitoring Agent\\\\Agent\\\\Health Service State\\\\Resources\\\\*\\\\M365Library.ps1" + } + } + } + } + ], + "from": "now-119m", + "index": [ + "winlogbeat-*", + "logs-windows.powershell*" + ], + "interval": "60m", + "investigation_fields": { + "field_names": [ + "@timestamp", + "user.name", + "user.id", + "user.domain", + "powershell.file.script_block_text", + "powershell.file.script_block_id", + "powershell.sequence", + "powershell.total", + "file.path", + "file.directory", + "file.name", + "process.pid", + "host.name", + "host.id", + "powershell.file.script_block_length" + ] + }, + "language": "kuery", + "license": "Elastic License v2", + "name": "PowerShell Script with Log Clear Capabilities", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This guide was created by humans with the assistance of generative AI. While its contents have been manually curated to include the most valuable information, always validate assumptions and adjust procedures to match your internal runbooks and incident triage and response policies.\n\n### Investigating PowerShell Script with Log Clear Capabilities\n\nThis alert identifies PowerShell script block content associated with clearing Windows event logs through cmdlets or .NET methods. Clearing local logs can reduce forensic visibility and interrupt security monitoring. Because script block logging records executed content, confirm whether log clearing occurred and identify the broader activity that led to this action.\n\n#### Key alert fields to review\n\n- `user.name`, `user.domain`, `user.id`: Account execution context for correlation, prioritization, and scoping.\n- `host.name`, `host.id`: Host execution context for correlation, prioritization, and scoping.\n- `powershell.file.script_block_text`: Script block content that matched the detection logic.\n- `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`: Script block metadata to pivot to other fragments or reconstruct full script content when split across multiple events.\n- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file.\n- `powershell.file.script_block_length`: Script block length (size) context.\n\n#### Possible investigation steps\n\n- Analyze `powershell.file.script_block_text` to determine intent and scope:\n - Identify the clearing technique used (for example, `Clear-EventLog`, `Remove-EventLog`, `EventLogSession.ClearLog`, or `Diagnostics.EventLog.Clear`).\n - Extract referenced log names/channels and any values that indicate breadth (single log vs multiple logs, loops, or log enumeration).\n - Note any remote targets, session objects, or hostnames that suggest log clearing on other systems.\n - If `Remove-EventLog` is used, treat it as higher impact and determine whether it targets built-in logs or custom logs/event sources.\n\n- Reconstruct full content when the script block is split:\n - Pivot on `powershell.file.script_block_id` to collect all fragments.\n - Order by `powershell.sequence` and confirm completeness using `powershell.total`.\n - Use `powershell.file.script_block_length` to identify unusually large content that may include additional actions beyond log clearing.\n\n- Establish execution context and likely origin:\n - Review `user.name`, `user.domain`, and `user.id` to determine whether the account is expected to perform log maintenance and whether the timing is consistent with approved activity.\n - Review `host.name` and `host.id` to determine whether the affected system is high value (for example, servers or shared systems) and to scope other alerts on the same host.\n - If `file.path`, `file.directory`, or `file.name` are present, capture the script location/name and evaluate whether it aligns with known administrative scripts or automation.\n - If file context is absent, treat the activity as inline or dynamically generated and prioritize identifying how PowerShell was launched (interactive session, scheduled execution, service, or parent process) using adjacent endpoint telemetry.\n\n- Confirm whether logs were actually cleared and identify what was impacted:\n - Review available Windows logging for records indicating event logs were cleared around `@timestamp`, and document which logs were affected.\n - Look for gaps in event coverage or abrupt changes in event volume beginning at or shortly after the alert time on the same `host.id`.\n\n- Correlate with adjacent activity around `@timestamp` (as available in your environment):\n - Process execution: identify the PowerShell host process, its parent process, and any related automation that triggered the script.\n - Authentication and remote access: identify new or unusual logons, session establishment, or privilege changes leading up to the event.\n - Network activity: review connections consistent with remote administration or lateral movement preceding the log clearing.\n - Additional PowerShell activity: review other script block events for the same `host.id` and `user.id` before and after the alert to identify precursor actions and follow-on cleanup.\n\n- Scope across the environment:\n - Search for the same or similar `powershell.file.script_block_text` patterns on other hosts to determine whether this is isolated behavior, shared tooling, or coordinated activity.\n - Pivot on `user.id` to identify whether the same account performed similar activity on multiple hosts within a short time window.\n\n### False positive analysis\n\n- Authorized administrators may clear logs during troubleshooting, controlled testing, or specific maintenance procedures. Validate against change records, maintenance windows, and documented responsibilities for the account in `user.name`.\n- Endpoint provisioning, imaging, or environment resets (for example, labs or short-lived systems) can include log clearing as part of baseline preparation. Validate whether `host.name` is part of an expected rebuild or reset workflow.\n- Operational scripts may clear specific logs to address performance or retention constraints. Benign activity is more likely when `file.path` and `file.name` are from a controlled script repository and no additional suspicious activity is present for the same `user.id` and `host.id`.\n\n### Response and remediation\n\n- If activity is unauthorized or suspicious:\n - Treat this as potential evidence destruction. Preserve remaining forensic data and collect relevant telemetry from the affected host.\n - Preserve the full script content by capturing all fragments linked by `powershell.file.script_block_id` (use `powershell.sequence` and `powershell.total` for ordering) and retain it with the case record.\n - Contain the involved account and host according to incident response procedures (for example, restrict access, reset credentials, and isolate the endpoint if required).\n - Investigate for additional post-compromise activity on the same `host.id` and by the same `user.id`, prioritizing persistence, credential access, and lateral movement around the alert time.\n - Assess logging resilience: verify critical logs are centrally forwarded and retained, and review access controls that allow event log clearing to ensure they are limited to necessary administrative roles.\n\n- If activity is confirmed benign:\n - Document the authorized workflow (who, what, where, and when), including expected `host.name`, `user.name`, and any associated script identifiers (`file.name`/`file.path`).\n - Maintain monitoring for deviations from the approved pattern (unexpected accounts, hosts, timing, or expanded targeting) to reduce noise without losing coverage.\n", + "query": "event.category:process and host.os.type:windows and\n powershell.file.script_block_text : (\n \"Clear-EventLog\" or\n \"Remove-EventLog\" or\n (\"Eventing.Reader.EventLogSession\" and \".ClearLog\") or\n (\"Diagnostics.EventLog\" and \".Clear\")\n ) and\n not powershell.file.script_block_text : (\n \"CmdletsToExport=@(\\\"Add-Content\\\"\"\n ) and\n not file.directory : \"C:\\Program Files\\WindowsAdminCenter\\PowerShellModules\\Microsoft.WindowsAdminCenter.Configuration\"\n", + "references": [ + "https://learn.microsoft.com/en-us/dotnet/api/system.diagnostics.eventlog.clear", + "https://learn.microsoft.com/en-us/dotnet/api/system.diagnostics.eventing.reader.eventlogsession.clearlog" + ], + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.category", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.directory", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_text", + "type": "unknown" + } + ], + "risk_score": 21, + "rule_id": "3d3aa8f9-12af-441f-9344-9f31053e316d", + "setup": "## Setup\n\nPowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104).\nSetup instructions: https://ela.st/powershell-logging-setup\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: PowerShell Logs", + "Rule Type: BBR", + "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/", + "subtechnique": [ + { + "id": "T1070.001", + "name": "Clear Windows Event Logs", + "reference": "https://attack.mitre.org/techniques/T1070/001/" + } + ] + } + ] + }, + { + "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": "query", + "version": 211 + }, + "id": "3d3aa8f9-12af-441f-9344-9f31053e316d_211", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/3e0561b5-3fac-4461-84cc-19163b9aaa61_8.json b/packages/security_detection_engine/kibana/security_rule/3e0561b5-3fac-4461-84cc-19163b9aaa61_8.json new file mode 100644 index 00000000000..740aca341be --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/3e0561b5-3fac-4461-84cc-19163b9aaa61_8.json @@ -0,0 +1,63 @@ +{ + "attributes": { + "anomaly_threshold": 70, + "author": [ + "Elastic" + ], + "description": "A machine learning job has detected a high count of destination IPs establishing an RDP connection with a single source IP. Once an attacker has gained access to one system, they might attempt to access more in the network in search of valuable assets, data, or further access points.", + "from": "now-12h", + "interval": "15m", + "license": "Elastic License v2", + "machine_learning_job_id": "lmd_high_rdp_distinct_count_destination_ip_for_source", + "name": "Spike in Number of Connections Made from a Source IP", + "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 Spike in Number of Connections Made from a Source IP\n\nRemote Desktop Protocol (RDP) is a common tool for remote management, but adversaries exploit it for lateral movement within networks. By establishing numerous connections from a single IP, attackers seek to expand their access. This detection rule leverages machine learning to identify unusual spikes in RDP connections, signaling potential unauthorized access attempts, and aids in early threat identification.\n\n### Possible investigation steps\n\n- Review the source IP address to determine if it is a known or trusted entity within the network.\n- Analyze the list of destination IPs to identify any unusual or unauthorized systems being accessed.\n- Check the timestamps of the connections to see if they align with expected activity patterns or occur during unusual hours.\n- Investigate the user account associated with the RDP connections to verify if it has been compromised or is being misused.\n- Correlate the spike in connections with any recent changes or incidents in the network that might explain the activity.\n- Examine network logs and RDP session logs for any signs of suspicious behavior or anomalies during the connection attempts.\n\n### False positive analysis\n\n- Routine administrative tasks can trigger spikes in RDP connections. Regularly scheduled maintenance or software updates may cause a high number of connections from a single IP. To manage this, identify and whitelist IPs associated with known administrative activities.\n- Automated scripts or tools used for network management might establish multiple RDP connections. Review and document these tools, then create exceptions for their IP addresses to prevent false alerts.\n- Load balancers or proxy servers can appear as a single source IP making numerous connections. Verify the network architecture and exclude these IPs from the rule to avoid misidentification.\n- Security scans or vulnerability assessments conducted by internal teams can result in a spike of connections. Coordinate with security teams to recognize these activities and exclude their IPs from triggering the rule.\n- Remote work solutions or VPNs might centralize connections through a single IP, leading to false positives. Identify these IPs and adjust the rule to accommodate legitimate remote access patterns.\n\n### Response and remediation\n\n- Isolate the affected system immediately to prevent further lateral movement within the network. Disconnect it from the network or place it in a quarantine VLAN.\n- Terminate any unauthorized RDP sessions originating from the identified source IP to halt ongoing unauthorized access attempts.\n- Conduct a thorough review of the affected system for signs of compromise, including checking for unauthorized user accounts, changes in system configurations, and the presence of malware or suspicious files.\n- Reset credentials for any accounts accessed via the compromised system to prevent further unauthorized access using stolen credentials.\n- Implement network segmentation to limit RDP access to only necessary systems and users, reducing the attack surface for lateral movement.\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- Update and enhance monitoring rules to detect similar patterns of unusual RDP connection spikes, ensuring early detection of future attempts.", + "references": [ + "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html", + "https://docs.elastic.co/en/integrations/lmd", + "https://www.elastic.co/blog/detecting-lateral-movement-activity-a-new-kibana-integration", + "https://www.elastic.co/blog/remote-desktop-protocol-connections-elastic-security" + ], + "related_integrations": [ + { + "package": "lmd", + "version": "^2.0.0" + }, + { + "package": "endpoint", + "version": "^8.2.0" + } + ], + "risk_score": 21, + "rule_id": "3e0561b5-3fac-4461-84cc-19163b9aaa61", + "setup": "## Setup\n\nThis rule requires the `host.ip` field to be populated.\nFor **Elastic Defend** events on versions **8.18 and above**, this field is **disabled by default**.\n\nIf you are using **Elastic Defend**, ensure host IP collection is enabled by following the configuration steps in the\n[helper guide](https://www.elastic.co/docs/solutions/security/configure-elastic-defend/configure-data-volume-for-elastic-endpoint#host-fields).\n\nThe rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration.\n\n### Lateral Movement Detection Setup\nThe Lateral Movement Detection integration detects lateral movement activity by identifying abnormalities in file and Windows RDP events. Anomalies are detected using Elastic's Anomaly Detection feature.\n\n#### Prerequisite Requirements:\n- Fleet is required for Lateral Movement Detection.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n- Windows RDP process events collected by the [Elastic Defend](https://docs.elastic.co/en/integrations/endpoint) integration.\n- To install Elastic Defend, refer to the [documentation](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n\n#### The following steps should be executed to install assets associated with the Lateral Movement Detection integration:\n- Go to the Kibana homepage. Under Management, click Integrations.\n- In the query bar, search for Lateral Movement Detection and select the integration to see more details about it.\n- Follow the instructions under the **Installation** section.\n- For this rule to work, complete the instructions through **Add preconfigured anomaly detection jobs**.\n", + "severity": "low", + "tags": [ + "Use Case: Lateral Movement Detection", + "Rule Type: ML", + "Rule Type: Machine Learning", + "Tactic: Lateral Movement", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0008", + "name": "Lateral Movement", + "reference": "https://attack.mitre.org/tactics/TA0008/" + }, + "technique": [ + { + "id": "T1210", + "name": "Exploitation of Remote Services", + "reference": "https://attack.mitre.org/techniques/T1210/" + } + ] + } + ], + "type": "machine_learning", + "version": 8 + }, + "id": "3e0561b5-3fac-4461-84cc-19163b9aaa61_8", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/3f4e2dba-828a-452a-af35-fe29c5e78969_8.json b/packages/security_detection_engine/kibana/security_rule/3f4e2dba-828a-452a-af35-fe29c5e78969_8.json new file mode 100644 index 00000000000..30944c6a8de --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/3f4e2dba-828a-452a-af35-fe29c5e78969_8.json @@ -0,0 +1,63 @@ +{ + "attributes": { + "anomaly_threshold": 70, + "author": [ + "Elastic" + ], + "description": "A machine learning job has detected an RDP session started at an usual time or weekday. An RDP session at an unusual time could be followed by other suspicious activities, so catching this is a good first step in detecting a larger attack.", + "from": "now-12h", + "interval": "15m", + "license": "Elastic License v2", + "machine_learning_job_id": "lmd_unusual_time_weekday_rdp_session_start", + "name": "Unusual Time or Day for an RDP Session", + "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 Time or Day for an RDP Session\n\nRemote Desktop Protocol (RDP) enables remote access to systems, crucial for IT management but also a target for adversaries seeking unauthorized access. Attackers exploit RDP by initiating sessions at odd hours to avoid detection. The detection rule leverages machine learning to identify atypical RDP session timings, flagging potential lateral movement attempts for further investigation.\n\n### Possible investigation steps\n\n- Review the timestamp of the RDP session to determine the specific unusual time or day it was initiated, and correlate it with known business hours or scheduled maintenance windows.\n- Identify the source and destination IP addresses involved in the RDP session to determine if they are internal or external, and check for any known associations with previous security incidents.\n- Examine the user account used to initiate the RDP session, verifying if it is a legitimate account and if the login aligns with the user's typical behavior or role within the organization.\n- Check for any additional suspicious activities or alerts involving the same user account or IP addresses around the time of the unusual RDP session, such as failed login attempts or access to sensitive files.\n- Investigate any recent changes or anomalies in the network or system configurations that could have facilitated the unusual RDP session, such as newly opened ports or modified firewall rules.\n- Consult logs from other security tools or systems, such as SIEM or endpoint detection and response (EDR) solutions, to gather more context on the RDP session and any related activities.\n\n### False positive analysis\n\n- Regular maintenance activities by IT staff during off-hours can trigger false positives. Identify and document these activities to create exceptions in the detection rule.\n- Scheduled automated tasks or scripts that initiate RDP sessions at unusual times may be misclassified. Review and whitelist these tasks to prevent unnecessary alerts.\n- Time zone differences for remote employees accessing systems outside of standard business hours can lead to false positives. Adjust detection parameters to account for these time zone variations.\n- Third-party vendors or contractors who require access at non-standard times should be documented and their access patterns reviewed to establish exceptions.\n- Emergency access situations where IT staff need to respond to critical incidents outside normal hours should be logged and considered when analyzing alerts.\n\n### Response and remediation\n\n- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.\n- Terminate the suspicious RDP session to halt any ongoing unauthorized activities.\n- Conduct a thorough review of the affected system's logs and processes to identify any malicious activities or changes made during the session.\n- Reset credentials for any accounts accessed during the unusual RDP session to prevent further unauthorized use.\n- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited.\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- Implement enhanced monitoring on the affected system and related network segments to detect any further suspicious activities or attempts at unauthorized access.", + "references": [ + "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html", + "https://docs.elastic.co/en/integrations/lmd", + "https://www.elastic.co/blog/detecting-lateral-movement-activity-a-new-kibana-integration", + "https://www.elastic.co/blog/remote-desktop-protocol-connections-elastic-security" + ], + "related_integrations": [ + { + "package": "lmd", + "version": "^2.0.0" + }, + { + "package": "endpoint", + "version": "^8.2.0" + } + ], + "risk_score": 21, + "rule_id": "3f4e2dba-828a-452a-af35-fe29c5e78969", + "setup": "## Setup\n\nThis rule requires the `host.ip` field to be populated.\nFor **Elastic Defend** events on versions **8.18 and above**, this field is **disabled by default**.\n\nIf you are using **Elastic Defend**, ensure host IP collection is enabled by following the configuration steps in the\n[helper guide](https://www.elastic.co/docs/solutions/security/configure-elastic-defend/configure-data-volume-for-elastic-endpoint#host-fields).\n\nThe rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration.\n\n### Lateral Movement Detection Setup\nThe Lateral Movement Detection integration detects lateral movement activity by identifying abnormalities in file and Windows RDP events. Anomalies are detected using Elastic's Anomaly Detection feature.\n\n#### Prerequisite Requirements:\n- Fleet is required for Lateral Movement Detection.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n- Windows RDP process events collected by the [Elastic Defend](https://docs.elastic.co/en/integrations/endpoint) integration.\n- To install Elastic Defend, refer to the [documentation](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n\n#### The following steps should be executed to install assets associated with the Lateral Movement Detection integration:\n- Go to the Kibana homepage. Under Management, click Integrations.\n- In the query bar, search for Lateral Movement Detection and select the integration to see more details about it.\n- Follow the instructions under the **Installation** section.\n- For this rule to work, complete the instructions through **Add preconfigured anomaly detection jobs**.\n", + "severity": "low", + "tags": [ + "Use Case: Lateral Movement Detection", + "Rule Type: ML", + "Rule Type: Machine Learning", + "Tactic: Lateral Movement", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0008", + "name": "Lateral Movement", + "reference": "https://attack.mitre.org/tactics/TA0008/" + }, + "technique": [ + { + "id": "T1210", + "name": "Exploitation of Remote Services", + "reference": "https://attack.mitre.org/techniques/T1210/" + } + ] + } + ], + "type": "machine_learning", + "version": 8 + }, + "id": "3f4e2dba-828a-452a-af35-fe29c5e78969_8", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/41554afd-d839-4cc2-b185-170ac01cbefc_1.json b/packages/security_detection_engine/kibana/security_rule/41554afd-d839-4cc2-b185-170ac01cbefc_1.json new file mode 100644 index 00000000000..1b3c5789535 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/41554afd-d839-4cc2-b185-170ac01cbefc_1.json @@ -0,0 +1,141 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies sensitive AWS IAM operations performed via AWS CloudShell based on the user agent string. CloudShell is a browser-based shell that provides command-line access to AWS resources directly from the AWS Management Console. While convenient for administrators, CloudShell access from compromised console sessions can enable attackers to perform privileged operations without installing tools or using programmatic credentials. This rule detects high-risk actions such as creating IAM users, access keys, roles, or attaching policies when initiated from CloudShell, which may indicate post-compromise credential harvesting or privilege escalation activity.", + "false_positives": [ + "Administrators may legitimately use CloudShell for IAM management tasks during routine operations or troubleshooting. Verify whether the user, source IP, and specific actions align with expected administrative workflows. Establish a baseline of normal CloudShell usage patterns to reduce false positives." + ], + "from": "now-6m", + "index": [ + "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 Sensitive IAM Operations Performed via CloudShell", + "note": "## Triage and analysis\n\n### Investigating AWS Sensitive IAM Operations Performed via CloudShell\n\nAWS CloudShell is a browser-based shell environment that provides instant command-line access to AWS resources without requiring local CLI installation or credential configuration. While this is convenient for legitimate administrators, it also provides adversaries with a powerful tool if they gain access to a compromised AWS console session. Attackers can use CloudShell to perform sensitive operations without leaving artifacts on their local systems.\n\nThis rule detects high-risk IAM operations performed via CloudShell, including credential creation, user management, and policy attachment. These actions are commonly seen in post-compromise scenarios where attackers establish persistence or escalate privileges.\n\n### Possible investigation steps\n\n- **Identify the actor**\n - Review `aws.cloudtrail.user_identity.arn` to determine which IAM principal performed the action.\n - Check `source.ip` and `source.geo` fields to verify the request origin matches expected administrator locations.\n - Investigate the console login event that established the CloudShell session.\n\n- **Analyze the specific action**\n - Review `event.action` to understand exactly what operation was performed.\n - For `CreateAccessKey` or `CreateUser`, identify the target principal and assess whether this was authorized.\n - For policy attachments, review which policies were attached and to which entities.\n\n- **Review request and response details**\n - Examine `aws.cloudtrail.request_parameters` for specifics like user names, policy ARNs, or role configurations.\n - Check `aws.cloudtrail.response_elements` for created resource identifiers.\n\n- **Correlate with surrounding activity**\n - Search for preceding events such as `ConsoleLogin` from the same session or IP address.\n - Look for MFA bypass indicators or unusual login patterns before CloudShell usage.\n - Check for subsequent use of any created credentials or roles.\n\n- **Assess the broader context**\n - Determine if this CloudShell usage pattern is typical for this user.\n - Review recent access patterns for the console session that initiated CloudShell.\n\n### False positive analysis\n\n- Routine administrative tasks using CloudShell are common in some organizations. Create baseline profiles for users who regularly use CloudShell.\n- Infrastructure automation testing may involve CloudShell for quick validation. Verify with the user.\n\n\n### Response and remediation\n\n- If unauthorized, immediately terminate the console session and revoke any created credentials.\n- Rotate credentials for any IAM users or roles that may have been compromised.\n- Review and remove any unauthorized users, access keys, roles, or policy attachments.\n- Consider restricting CloudShell access via SCPs or IAM policies for sensitive accounts.\n- Implement session duration limits to reduce the window of opportunity for console session abuse.\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", + "query": "event.dataset: \"aws.cloudtrail\"\n and event.provider: \"iam.amazonaws.com\"\n and event.action: (\n \"CreateAccessKey\" or\n \"CreateUser\" or\n \"AttachUserPolicy\" or\n \"PutUserPolicy\" or\n \"CreateRole\" or\n \"AttachRolePolicy\" or\n \"PutRolePolicy\" or\n \"CreateInstanceProfile\" or\n \"AddRoleToInstanceProfile\"\n )\n and event.outcome: \"success\"\n and user_agent.original: *CloudShell*\n", + "references": [ + "https://docs.aws.amazon.com/cloudshell/latest/userguide/welcome.html", + "https://permiso.io/blog/lucr-3-scattered-spider-getting-saas-y-in-the-cloud", + "https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-320a" + ], + "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": "user_agent.original", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "41554afd-d839-4cc2-b185-170ac01cbefc", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Data Source: AWS CloudTrail", + "Data Source: AWS IAM", + "Tactic: Persistence", + "Tactic: Privilege Escalation", + "Use Case: Threat Detection", + "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/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0004", + "name": "Privilege Escalation", + "reference": "https://attack.mitre.org/tactics/TA0004/" + }, + "technique": [ + { + "id": "T1098", + "name": "Account Manipulation", + "reference": "https://attack.mitre.org/techniques/T1098/", + "subtechnique": [ + { + "id": "T1098.003", + "name": "Additional Cloud Roles", + "reference": "https://attack.mitre.org/techniques/T1098/003/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 1 + }, + "id": "41554afd-d839-4cc2-b185-170ac01cbefc_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/41824afb-d68c-4d0e-bfee-474dac1fa56e_104.json b/packages/security_detection_engine/kibana/security_rule/41824afb-d68c-4d0e-bfee-474dac1fa56e_104.json deleted file mode 100644 index cea7b05be2c..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/41824afb-d68c-4d0e-bfee-474dac1fa56e_104.json +++ /dev/null @@ -1,90 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies the execution of and EggShell Backdoor. EggShell is a known post exploitation tool for macOS and Linux.", - "from": "now-9m", - "index": [ - "auditbeat-*", - "logs-endpoint.events.*" - ], - "language": "kuery", - "license": "Elastic License v2", - "name": "EggShell Backdoor 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 EggShell Backdoor Execution\n\nEggShell is a post-exploitation tool used on macOS and Linux systems, allowing adversaries to execute commands and scripts remotely. It leverages command and scripting interpreters to gain control over compromised systems. Attackers exploit this by executing malicious payloads, maintaining persistence, and exfiltrating data. The detection rule identifies suspicious process activities, specifically targeting the execution patterns and arguments associated with EggShell, to alert analysts of potential backdoor usage.\n\n### Possible investigation steps\n\n- Review the alert details to confirm the presence of the process name 'espl' and check if the process arguments start with 'eyJkZWJ1ZyI6', which indicates potential EggShell activity.\n- Investigate the parent process of 'espl' to understand how it was initiated and identify any associated suspicious activities or processes.\n- Examine the user account under which the 'espl' process was executed to determine if it aligns with expected behavior or if it indicates a compromised account.\n- Check for any network connections or data exfiltration attempts associated with the 'espl' process to assess if data has been sent to an external source.\n- Review system logs and other security alerts around the time of the 'espl' process execution to identify any correlated events or anomalies.\n- Assess the persistence mechanisms on the affected system to determine if the EggShell backdoor has established any means to survive reboots or user logouts.\n\n### False positive analysis\n\n- Legitimate administrative scripts or tools that use similar command patterns to EggShell may trigger false positives. Review the process arguments and context to determine if the activity is expected and authorized.\n- Development or testing environments where EggShell or similar tools are used for legitimate purposes can cause alerts. Implement exceptions for these environments by excluding specific user accounts or process paths.\n- Automated scripts or monitoring tools that mimic EggShell's execution patterns might be flagged. Identify these scripts and create exceptions based on their unique identifiers or execution context.\n- Regularly update the detection rule to refine the criteria based on observed false positives, ensuring that legitimate activities are not continuously flagged.\n\n### Response and remediation\n\n- Immediately isolate the affected system from the network to prevent further command execution and data exfiltration.\n- Terminate any suspicious processes associated with the EggShell backdoor, specifically those matching the process name 'espl' and arguments starting with 'eyJkZWJ1ZyI6'.\n- Conduct a thorough examination of the system to identify any additional malicious payloads or persistence mechanisms that may have been deployed by the attacker.\n- Remove any unauthorized user accounts or access credentials that may have been created or compromised during the exploitation.\n- Restore the system from a known good backup to ensure all traces of the backdoor and any associated malware are eradicated.\n- Update and patch all software and systems to close any vulnerabilities that may have been exploited by the attacker.\n- Enhance monitoring and detection capabilities to identify similar threats in the future, focusing on command and scripting interpreter activities as outlined in MITRE ATT&CK technique T1059.", - "query": "event.category:process and event.type:(process_started or start) and process.name:espl and process.args:eyJkZWJ1ZyI6*\n", - "references": [ - "https://github.com/neoneggplant/EggShell" - ], - "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": "process.args", - "type": "keyword" - }, - { - "ecs": true, - "name": "process.name", - "type": "keyword" - } - ], - "risk_score": 73, - "rule_id": "41824afb-d68c-4d0e-bfee-474dac1fa56e", - "severity": "high", - "tags": [ - "Domain: Endpoint", - "OS: Linux", - "OS: macOS", - "Use Case: Threat Detection", - "Tactic: Execution", - "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.006", - "name": "Python", - "reference": "https://attack.mitre.org/techniques/T1059/006/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "query", - "version": 104 - }, - "id": "41824afb-d68c-4d0e-bfee-474dac1fa56e_104", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/42bf698b-4738-445b-8231-c834ddefd8a0_416.json b/packages/security_detection_engine/kibana/security_rule/42bf698b-4738-445b-8231-c834ddefd8a0_416.json new file mode 100644 index 00000000000..89a469b5794 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/42bf698b-4738-445b-8231-c834ddefd8a0_416.json @@ -0,0 +1,196 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects potential password spray attacks where a single source IP attempts authentication against multiple Okta user accounts with repeated attempts per user, indicating common password guessing paced to avoid lockouts.", + "false_positives": [ + "Corporate proxy or VPN exit nodes may aggregate traffic from multiple legitimate users with login issues.", + "Automated processes or misconfigured applications retrying authentication may trigger this rule." + ], + "from": "now-1h", + "interval": "15m", + "language": "esql", + "license": "Elastic License v2", + "name": "Potential Okta Password Spray (Single Source)", + "note": "## Triage and analysis\n\n### Investigating Potential Okta Password Spray (Single Source)\n\nThis rule identifies a single source IP attempting authentication against multiple user accounts with repeated attempts per user over time. This pattern indicates password spraying where attackers try common passwords while pacing attempts to avoid lockouts.\n\n#### Possible investigation steps\n- Identify the source IP and determine if it belongs to known proxy, VPN, or cloud infrastructure.\n- Review the list of targeted user accounts and check if any authentications succeeded.\n- Analyze the timing of attempts to determine if they are paced to avoid lockout thresholds.\n- Check if Okta flagged the source as a known threat or proxy.\n- Examine user agent strings for signs of automation or consistent tooling across attempts.\n- Review the geographic location and ASN of the source IP for anomalies.\n\n### False positive analysis\n- Corporate proxies or VPN exit nodes may aggregate traffic from multiple legitimate users with login issues.\n- Automated processes or misconfigured applications retrying authentication may trigger this rule.\n- Password rotation events may cause legitimate widespread authentication failures.\n\n### Response and remediation\n- If attack is confirmed, block the source IP at the network perimeter.\n- Notify targeted users and enforce password resets for accounts that may have been compromised.\n- Enable or strengthen MFA for targeted accounts.\n- Consider implementing CAPTCHA or additional friction for suspicious authentication patterns.\n- Review Okta sign-on policies to ensure lockout thresholds are appropriately configured.\n", + "query": "FROM logs-okta.system-* METADATA _id, _version, _index\n| WHERE\n event.dataset == \"okta.system\"\n AND (event.action LIKE \"user.authentication.*\" OR event.action == \"user.session.start\")\n AND okta.outcome.reason IN (\"INVALID_CREDENTIALS\", \"LOCKED_OUT\")\n AND okta.actor.alternate_id IS NOT NULL\n// Build user-source context as JSON for enrichment\n| EVAL Esql.user_source_info = CONCAT(\n \"{\\\"user\\\":\\\"\", okta.actor.alternate_id,\n \"\\\",\\\"ip\\\":\\\"\", COALESCE(okta.client.ip::STRING, \"unknown\"),\n \"\\\",\\\"user_agent\\\":\\\"\", COALESCE(okta.client.user_agent.raw_user_agent, \"unknown\"), \"\\\"}\"\n )\n// FIRST STATS: Aggregate by (IP, user) to get per-user attempt counts\n// This prevents skew from outlier users with many attempts\n| STATS\n Esql.user_attempts = COUNT(*),\n Esql.user_source_info = VALUES(Esql.user_source_info),\n Esql.user_agents_per_user = VALUES(okta.client.user_agent.raw_user_agent),\n Esql.devices_per_user = VALUES(okta.client.device),\n Esql.is_proxy = VALUES(okta.security_context.is_proxy),\n Esql.geo_country = VALUES(client.geo.country_name),\n Esql.geo_city = VALUES(client.geo.city_name),\n Esql.asn_number = VALUES(source.as.number),\n Esql.asn_org = VALUES(source.as.organization.name),\n Esql.threat_suspected = VALUES(okta.debug_context.debug_data.threat_suspected),\n Esql.risk_level = VALUES(okta.debug_context.debug_data.risk_level),\n Esql.event_actions = VALUES(event.action),\n Esql.first_seen_user = MIN(@timestamp),\n Esql.last_seen_user = MAX(@timestamp)\n BY okta.client.ip, okta.actor.alternate_id\n// SECOND STATS: Aggregate by IP to detect password spray pattern\n// Now we can accurately measure the distribution of attempts across users\n| STATS\n Esql.unique_users = COUNT(*),\n Esql.total_attempts = SUM(Esql.user_attempts),\n Esql.max_attempts_per_user = MAX(Esql.user_attempts),\n Esql.min_attempts_per_user = MIN(Esql.user_attempts),\n Esql.avg_attempts_per_user = AVG(Esql.user_attempts),\n // Spray band: 2-6 attempts per user (deliberate slow spray below lockout)\n Esql.users_in_spray_band = SUM(CASE(Esql.user_attempts >= 2 AND Esql.user_attempts <= 6, 1, 0)),\n // Also track users with only 1 attempt (stuffing-like) for differentiation\n Esql.users_with_single_attempt = SUM(CASE(Esql.user_attempts == 1, 1, 0)),\n Esql.first_seen = MIN(Esql.first_seen_user),\n Esql.last_seen = MAX(Esql.last_seen_user),\n Esql.target_users = VALUES(okta.actor.alternate_id),\n Esql.user_source_mapping = VALUES(Esql.user_source_info),\n Esql.event_action_values = VALUES(Esql.event_actions),\n Esql.user_agent_values = VALUES(Esql.user_agents_per_user),\n Esql.device_values = VALUES(Esql.devices_per_user),\n Esql.is_proxy_values = VALUES(Esql.is_proxy),\n Esql.geo_country_values = VALUES(Esql.geo_country),\n Esql.geo_city_values = VALUES(Esql.geo_city),\n Esql.source_asn_values = VALUES(Esql.asn_number),\n Esql.source_asn_org_values = VALUES(Esql.asn_org),\n Esql.threat_suspected_values = VALUES(Esql.threat_suspected),\n Esql.risk_level_values = VALUES(Esql.risk_level)\n BY okta.client.ip\n// Calculate spray signature metrics\n| EVAL\n // Percentage of users in the spray band (2-6 attempts)\n Esql.pct_users_in_spray_band = Esql.users_in_spray_band * 100.0 / Esql.unique_users,\n // Attack duration in minutes (spray is paced, not bursty)\n Esql.attack_duration_minutes = DATE_DIFF(\"minute\", Esql.first_seen, Esql.last_seen)\n// Password spraying detection logic:\n// - Many users targeted (>= 5)\n// - Hard cap below Okta lockout threshold (max <= 8 attempts per user)\n// - Majority of users in spray band (2-6 attempts) (at least 60%)\n// - Attack is paced over time (>= 5 minutes) (not a 10-second burst like stuffing)\n// - Minimum total attempts to reduce noise\n// Note: For IP rotation attacks, see \"Distributed Password Spray Attack in Okta\" rule\n| WHERE\n Esql.unique_users >= 5\n AND Esql.total_attempts >= 15\n AND Esql.max_attempts_per_user <= 8\n AND Esql.max_attempts_per_user >= 2\n AND Esql.pct_users_in_spray_band >= 60.0\n AND Esql.attack_duration_minutes >= 5\n| SORT Esql.total_attempts DESC\n| KEEP Esql.*, okta.client.ip\n", + "references": [ + "https://support.okta.com/help/s/article/Troubleshooting-Distributed-Brute-Force-andor-Password-Spray-attacks-in-Okta", + "https://www.okta.com/identity-101/brute-force/", + "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://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security", + "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta" + ], + "related_integrations": [ + { + "package": "okta", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.attack_duration_minutes", + "type": "integer" + }, + { + "ecs": false, + "name": "Esql.avg_attempts_per_user", + "type": "double" + }, + { + "ecs": false, + "name": "Esql.device_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.event_action_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.first_seen", + "type": "date" + }, + { + "ecs": false, + "name": "Esql.geo_city_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.geo_country_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.is_proxy_values", + "type": "boolean" + }, + { + "ecs": false, + "name": "Esql.last_seen", + "type": "date" + }, + { + "ecs": false, + "name": "Esql.max_attempts_per_user", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.min_attempts_per_user", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.pct_users_in_spray_band", + "type": "double" + }, + { + "ecs": false, + "name": "Esql.risk_level_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.source_asn_org_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.source_asn_values", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.target_users", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.threat_suspected_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.total_attempts", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.unique_users", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.user_agent_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.user_source_mapping", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.users_in_spray_band", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.users_with_single_attempt", + "type": "long" + }, + { + "ecs": false, + "name": "okta.client.ip", + "type": "ip" + } + ], + "risk_score": 47, + "rule_id": "42bf698b-4738-445b-8231-c834ddefd8a0", + "severity": "medium", + "tags": [ + "Domain: Identity", + "Use Case: Identity and Access Audit", + "Tactic: Credential Access", + "Data Source: Okta", + "Data Source: Okta System Logs", + "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/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 416 + }, + "id": "42bf698b-4738-445b-8231-c834ddefd8a0_416", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/47403d72-3ee2-4752-a676-19dc8ff2b9d6_1.json b/packages/security_detection_engine/kibana/security_rule/47403d72-3ee2-4752-a676-19dc8ff2b9d6_1.json new file mode 100644 index 00000000000..76db2c1a785 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/47403d72-3ee2-4752-a676-19dc8ff2b9d6_1.json @@ -0,0 +1,140 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects when an uncommon user or role creates an OpenID Connect (OIDC) Identity Provider in AWS IAM. OIDC providers enable web identity federation, allowing users authenticated by external identity providers (such as Google, GitHub, or custom OIDC-compliant providers) to assume IAM roles and access AWS resources. Adversaries who have gained administrative access may create rogue OIDC providers to establish persistent, federated access that survives credential rotation. This technique allows attackers to assume roles using tokens from an IdP they control. While OIDC provider creation is benign in some environments, it should still be validated against authorized infrastructure changes.", + "false_positives": [ + "OIDC providers may be created during legitimate CI/CD integration (e.g., GitHub Actions, GitLab CI), Kubernetes service account federation, or other web identity use cases. Verify whether the user identity and timing align with approved change management processes. If this is expected administrative activity, it can be exempted from the rule." + ], + "from": "now-6m", + "history_window_start": "now-10d", + "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 OIDC Provider Created by Rare User", + "new_terms_fields": [ + "cloud.account.id", + "user.name" + ], + "note": "## Triage and analysis\n\n### Investigating AWS IAM OIDC Provider Created by Rare User\n\nOpenID Connect (OIDC) providers in AWS IAM enable web identity federation, allowing external identity providers to authenticate users who then assume IAM roles. Common legitimate use cases include GitHub Actions accessing AWS resources, Kubernetes pods authenticating to AWS, and web applications using social login.\n\nThis rule detects the first time a specific user or role creates an OIDC provider within an account. While OIDC provider creation is common in some environments, a new user creating one for the first time warrants validation to ensure it's authorized.\n\n### Possible investigation steps\n\n- **Identify the actor**\n - Review `aws.cloudtrail.user_identity.arn` to determine who created the OIDC provider.\n - Check if this user has created OIDC providers before in other accounts.\n\n- **Review the OIDC provider details**\n - Examine `aws.cloudtrail.request_parameters` for the provider URL and client IDs.\n - Identify the external IdP (e.g., GitHub, Google, custom provider).\n\n- **Validate business justification**\n - Confirm with DevOps or platform teams whether this aligns with CI/CD pipeline setup.\n - Check for related change tickets or infrastructure-as-code deployments.\n\n- **Check for follow-on activity**\n - Search for `CreateRole` or `UpdateAssumeRolePolicy` calls that trust the new OIDC provider.\n - Look for `AssumeRoleWithWebIdentity` calls using the newly created provider.\n\n- **Correlate with other suspicious activity**\n - Check for preceding privilege escalation or credential access events.\n - Look for other persistence mechanisms being established concurrently.\n\n### False positive analysis\n\n- **CI/CD pipeline integration**\n - GitHub Actions, GitLab CI, and other CI/CD systems commonly use OIDC for AWS authentication.\n - Validate against known DevOps workflows.\n\n- **Kubernetes federation**\n - EKS and self-managed Kubernetes clusters may use OIDC providers for pod identity.\n - Confirm with platform engineering teams.\n\n- **Infrastructure-as-code deployments**\n - Terraform, CloudFormation, or other IaC tools may create OIDC providers.\n - Verify via CI/CD logs.\n\n### Response and remediation\n\n- **Immediate containment**\n - If unauthorized, delete the OIDC provider using `DeleteOpenIDConnectProvider`.\n - Review and remove any IAM roles that trust the rogue provider.\n\n- **Investigation**\n - Audit CloudTrail for any `AssumeRoleWithWebIdentity` calls using this provider.\n - Review all IAM roles with web identity trust relationships.\n\n- **Hardening**\n - Restrict `iam:CreateOpenIDConnectProvider` permissions to authorized roles.\n - Implement SCPs to control OIDC provider creation in member accounts.\n - Enable AWS Config rules to monitor identity provider configurations.\n\n### Additional information\n- **[AWS IAM OIDC Providers Documentation](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_oidc.html)**\n- **[AWS IR Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/)**\n- **[AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs)**\n", + "query": "event.dataset: \"aws.cloudtrail\"\n and event.provider: \"iam.amazonaws.com\"\n and event.action: \"CreateOpenIDConnectProvider\"\n and event.outcome: \"success\"\n", + "references": [ + "https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateOpenIDConnectProvider.html", + "https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_oidc.html", + "https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-320a" + ], + "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": "47403d72-3ee2-4752-a676-19dc8ff2b9d6", + "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": "T1078", + "name": "Valid Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/", + "subtechnique": [ + { + "id": "T1078.004", + "name": "Cloud Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/004/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0004", + "name": "Privilege Escalation", + "reference": "https://attack.mitre.org/tactics/TA0004/" + }, + "technique": [ + { + "id": "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": "new_terms", + "version": 1 + }, + "id": "47403d72-3ee2-4752-a676-19dc8ff2b9d6_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/498e4094-60e7-11f0-8847-f661ea17fbcd_7.json b/packages/security_detection_engine/kibana/security_rule/498e4094-60e7-11f0-8847-f661ea17fbcd_7.json new file mode 100644 index 00000000000..8ac62ce343c --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/498e4094-60e7-11f0-8847-f661ea17fbcd_7.json @@ -0,0 +1,1117 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects when the issuer URL of a federated identity credential is changed on an Entra ID application. Adversaries may modify the issuer to point to an attacker-controlled identity provider, enabling them to authenticate as the application's service principal and gain persistent access to Azure resources. This technique allows bypassing traditional authentication controls by federating trust with a malicious external identity provider.", + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "Entra ID Federated Identity Credential Issuer Modified", + "note": "## Triage and analysis\n\n### Investigating Entra ID Federated Identity Credential Issuer Modified\n\nThis rule detects when the issuer URL within a federated identity credential is modified on an Entra ID application. Federated identity credentials allow applications to authenticate using tokens from external identity providers (like GitHub Actions, AWS, etc.) without managing secrets. Adversaries can abuse this by changing the issuer to an attacker-controlled identity provider, allowing them to generate valid tokens and authenticate as the application's service principal.\n\nThis technique provides persistent access to Azure resources with the application's permissions and bypasses secret-based authentication controls.\n\n### Possible investigation steps\n\n- Review `azure.auditlogs.properties.initiated_by.user.userPrincipalName` and `ipAddress` to identify who made the change and from where.\n- Examine the `Esql.external_idp_old_issuer` and `Esql.external_idp_new_issuer` fields to determine if the new issuer is expected or potentially malicious.\n- Check if the new issuer domain is controlled by the organization or if it's an external/suspicious domain.\n- Review the application's assigned roles and permissions to understand the scope of access gained.\n- Use `azure.correlation_id` to pivot to related changes in the same session.\n- Check for subsequent Azure sign-in activity using the modified federated credential.\n- Investigate if the application has been used to access sensitive resources after the change.\n\n### False positive analysis\n\n- Legitimate migrations from one identity provider to another (e.g., GitHub to GitLab) may trigger this detection.\n- DevOps teams may update issuer URLs as part of CI/CD pipeline changes.\n- Validate any changes with the application owner or DevOps team before taking action.\n\n### Response and remediation\n\n- If the change is unauthorized, immediately remove or revert the federated identity credential.\n- Rotate any secrets or certificates associated with the application.\n- Review Azure sign-in logs and audit logs for any unauthorized activity using the application's identity.\n- Disable the application or service principal if compromise is confirmed.\n- Investigate how the unauthorized change occurred (e.g., compromised admin account, over-privileged service principal).\n- Implement conditional access policies and PIM (Privileged Identity Management) to protect application management operations.\n", + "query": "from logs-azure.auditlogs-* metadata _id, _version, _index\n| where event.action == \"Update application\"\n| where `azure.auditlogs.properties.target_resources.0.modified_properties.0.display_name` == \"FederatedIdentityCredentials\"\n| eval Esql.target_resources_old_value_clean = replace(`azure.auditlogs.properties.target_resources.0.modified_properties.0.old_value`, \"\\\\\\\\\", \"\")\n| eval Esql.target_resources_new_value_clean = replace(`azure.auditlogs.properties.target_resources.0.modified_properties.0.new_value`, \"\\\\\\\\\", \"\")\n| dissect Esql.target_resources_old_value_clean \"%{}\\\"Issuer\\\":\\\"%{Esql.external_idp_old_issuer}\\\"%{}\"\n| dissect Esql.target_resources_new_value_clean \"%{}\\\"Issuer\\\":\\\"%{Esql.external_idp_new_issuer}\\\"%{}\"\n| where Esql.external_idp_old_issuer is not null and Esql.external_idp_new_issuer is not null\n| where Esql.external_idp_old_issuer != Esql.external_idp_new_issuer\n| keep @timestamp, Esql.*, azure.*, event.*, cloud.*, related.*, tags, source.*, agent.*, client.*, _id, _version, _index, data_stream.namespace\n", + "references": [ + "https://dirkjanm.io/persisting-with-federated-credentials-entra-apps-managed-identities/", + "https://learn.microsoft.com/en-us/entra/workload-id/workload-identity-federation" + ], + "related_integrations": [ + { + "package": "azure", + "version": "^1.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "@timestamp", + "type": "date" + }, + { + "ecs": false, + "name": "Esql.external_idp_new_issuer", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.external_idp_old_issuer", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.target_resources_new_value_clean", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.target_resources_old_value_clean", + "type": "keyword" + }, + { + "ecs": false, + "name": "_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "_index", + "type": "keyword" + }, + { + "ecs": false, + "name": "_version", + "type": "long" + }, + { + "ecs": true, + "name": "agent.build.original", + "type": "keyword" + }, + { + "ecs": true, + "name": "agent.ephemeral_id", + "type": "keyword" + }, + { + "ecs": true, + "name": "agent.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "agent.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "agent.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "agent.version", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.category", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.identity", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.level", + "type": "double" + }, + { + "ecs": false, + "name": "azure.auditlogs.operation_name", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.operation_version", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.activity_datetime", + "type": "date" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.activity_display_name", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.additional_details.key", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.additional_details.user_agent", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.additional_details.value", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.authentication_protocol", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.category", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.correlation_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.id", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.initiated_by.app.appId", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.initiated_by.app.displayName", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.initiated_by.app.servicePrincipalId", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.initiated_by.app.servicePrincipalName", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.initiated_by.user.displayName", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.initiated_by.user.id", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.initiated_by.user.ipAddress", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.initiated_by.user.roles", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.initiated_by.user.userPrincipalName", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.logged_by_service", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.operation_type", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.result", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.result_reason", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.target_resources.*.display_name", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.target_resources.*.id", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.target_resources.*.ip_address", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.target_resources.*.modified_properties.*.display_name", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.target_resources.*.modified_properties.*.new_value", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.target_resources.*.modified_properties.*.old_value", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.target_resources.*.type", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.target_resources.*.user_principal_name", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.target_resources.0.modified_properties.0.display_name", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.target_resources.0.modified_properties.0.new_value", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.target_resources.0.modified_properties.0.old_value", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.target_resources.0.modified_properties.1.display_name", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.target_resources.0.modified_properties.1.new_value", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.target_resources.0.modified_properties.2.new_value", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.target_resources.0.modified_properties.3.new_value", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.result_description", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.result_signature", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.tenant_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.correlation_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.resource.authorization_rule", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.resource.group", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.resource.id", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.resource.name", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.resource.namespace", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.resource.provider", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.subscription_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.tenant_id", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.address", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.as.number", + "type": "long" + }, + { + "ecs": true, + "name": "client.as.organization.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.bytes", + "type": "long" + }, + { + "ecs": true, + "name": "client.domain", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.geo.city_name", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.geo.continent_code", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.geo.continent_name", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.geo.country_iso_code", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.geo.country_name", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.geo.location", + "type": "geo_point" + }, + { + "ecs": true, + "name": "client.geo.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.geo.postal_code", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.geo.region_iso_code", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.geo.region_name", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.geo.timezone", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.ip", + "type": "ip" + }, + { + "ecs": true, + "name": "client.mac", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.nat.ip", + "type": "ip" + }, + { + "ecs": true, + "name": "client.nat.port", + "type": "long" + }, + { + "ecs": true, + "name": "client.packets", + "type": "long" + }, + { + "ecs": true, + "name": "client.port", + "type": "long" + }, + { + "ecs": true, + "name": "client.registered_domain", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.subdomain", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.top_level_domain", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.user.domain", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.user.email", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.user.full_name", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.user.group.domain", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.user.group.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.user.group.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.user.hash", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.user.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.user.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.user.roles", + "type": "keyword" + }, + { + "ecs": true, + "name": "cloud.account.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "cloud.account.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "cloud.availability_zone", + "type": "keyword" + }, + { + "ecs": false, + "name": "cloud.image.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "cloud.instance.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "cloud.instance.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "cloud.machine.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "cloud.origin.account.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "cloud.origin.account.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "cloud.origin.availability_zone", + "type": "keyword" + }, + { + "ecs": true, + "name": "cloud.origin.instance.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "cloud.origin.instance.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "cloud.origin.machine.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "cloud.origin.project.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "cloud.origin.project.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "cloud.origin.provider", + "type": "keyword" + }, + { + "ecs": true, + "name": "cloud.origin.region", + "type": "keyword" + }, + { + "ecs": true, + "name": "cloud.origin.service.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "cloud.project.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "cloud.project.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "cloud.provider", + "type": "keyword" + }, + { + "ecs": true, + "name": "cloud.region", + "type": "keyword" + }, + { + "ecs": true, + "name": "cloud.service.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "cloud.target.account.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "cloud.target.account.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "cloud.target.availability_zone", + "type": "keyword" + }, + { + "ecs": true, + "name": "cloud.target.instance.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "cloud.target.instance.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "cloud.target.machine.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "cloud.target.project.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "cloud.target.project.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "cloud.target.provider", + "type": "keyword" + }, + { + "ecs": true, + "name": "cloud.target.region", + "type": "keyword" + }, + { + "ecs": true, + "name": "cloud.target.service.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "data_stream.namespace", + "type": "constant_keyword" + }, + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.agent_id_status", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.category", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.code", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.created", + "type": "date" + }, + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.duration", + "type": "long" + }, + { + "ecs": true, + "name": "event.end", + "type": "date" + }, + { + "ecs": true, + "name": "event.hash", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.ingested", + "type": "date" + }, + { + "ecs": true, + "name": "event.kind", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.module", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.original", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.outcome", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.provider", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.reason", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.reference", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.risk_score", + "type": "float" + }, + { + "ecs": true, + "name": "event.risk_score_norm", + "type": "float" + }, + { + "ecs": true, + "name": "event.sequence", + "type": "long" + }, + { + "ecs": true, + "name": "event.severity", + "type": "long" + }, + { + "ecs": true, + "name": "event.start", + "type": "date" + }, + { + "ecs": true, + "name": "event.timezone", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.url", + "type": "keyword" + }, + { + "ecs": false, + "name": "related.entity", + "type": "keyword" + }, + { + "ecs": true, + "name": "related.hash", + "type": "keyword" + }, + { + "ecs": true, + "name": "related.hosts", + "type": "keyword" + }, + { + "ecs": true, + "name": "related.ip", + "type": "ip" + }, + { + "ecs": true, + "name": "related.user", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.address", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.as.number", + "type": "long" + }, + { + "ecs": true, + "name": "source.as.organization.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.bytes", + "type": "long" + }, + { + "ecs": true, + "name": "source.domain", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.geo.city_name", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.geo.continent_code", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.geo.continent_name", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.geo.country_iso_code", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.geo.country_name", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.geo.location", + "type": "geo_point" + }, + { + "ecs": true, + "name": "source.geo.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.geo.postal_code", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.geo.region_iso_code", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.geo.region_name", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.geo.timezone", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.ip", + "type": "ip" + }, + { + "ecs": true, + "name": "source.mac", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.nat.ip", + "type": "ip" + }, + { + "ecs": true, + "name": "source.nat.port", + "type": "long" + }, + { + "ecs": true, + "name": "source.packets", + "type": "long" + }, + { + "ecs": true, + "name": "source.port", + "type": "long" + }, + { + "ecs": true, + "name": "source.registered_domain", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.subdomain", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.top_level_domain", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.user.domain", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.user.email", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.user.full_name", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.user.group.domain", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.user.group.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.user.group.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.user.hash", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.user.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.user.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.user.roles", + "type": "keyword" + }, + { + "ecs": true, + "name": "tags", + "type": "keyword" + } + ], + "risk_score": 73, + "rule_id": "498e4094-60e7-11f0-8847-f661ea17fbcd", + "setup": "### Microsft Entra ID Audit Logs\nThis rule requires the Azure integration with Microsoft Entra ID Audit Logs data stream ingesting in your Elastic Stack deployment. For more information, refer to the [Microsoft Entra ID Audit Logs integration documentation](https://www.elastic.co/docs/reference/integrations/azure/adlogs).\n", + "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", + "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/", + "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": "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": "esql", + "version": 7 + }, + "id": "498e4094-60e7-11f0-8847-f661ea17fbcd_7", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/4ae94fc1-f08f-419f-b692-053d28219380_3.json b/packages/security_detection_engine/kibana/security_rule/4ae94fc1-f08f-419f-b692-053d28219380_3.json new file mode 100644 index 00000000000..50665bf9ee6 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/4ae94fc1-f08f-419f-b692-053d28219380_3.json @@ -0,0 +1,112 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies DNS queries to known Large Language Model domains by unsigned binaries or common Windows scripting utilities. Malwares may leverage the capabilities of LLM to perform actions in the affected system in a dynamic way.", + "from": "now-9m", + "index": [ + "endgame-*", + "logs-endpoint.events.network-*", + "logs-sentinel_one_cloud_funnel.*", + "logs-windows.sysmon_operational-*", + "winlogbeat-*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Connection to Common Large Language Model Endpoints", + "note": "## Triage and analysis\n\n### Investigating Connection to Common Large Language Model Endpoints\n\n#### Possible investigation steps\n\n- Investigate the process execution chain (parent process tree) for unknown processes or malicious scripts.\n- Verify if the executed process is persistent on the host like common mechanisms Startup folder, task or Run key.\n- Review any unusual network, files or registry events by the same process.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Extract this communication's indicators of compromise (IoCs) and use traffic logs to search for other potentially compromised hosts.\n\n### False positive analysis\n\n- Trusted applications from an expected process running in the environment.\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- Immediately block the identified indicators of compromise (IoCs).\n- Implement any temporary network rules, procedures, and segmentation required to contain the attack.\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- Update firewall rules to be more restrictive.\n- Reimage the host operating system or restore the compromised files to clean versions.\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 in (\"macos\", \"windows\") and dns.question.name != null and\n(\n process.name : (\"MSBuild.exe\", \"mshta.exe\", \"wscript.exe\", \"powershell.exe\", \"pwsh.exe\", \"msiexec.exe\", \"rundll32.exe\",\n \"bitsadmin.exe\", \"InstallUtil.exe\", \"RegAsm.exe\", \"vbc.exe\", \"RegSvcs.exe\", \"regsvr32.exe\", \"dllhost.exe\",\n \"node.exe\", \"javaw.exe\", \"java.exe\", \"*.pif\", \"*.com\", \"python*\", \"osascript\", \"Script Editor\", \"curl\", \"curl.exe\", \"deno\", \n \"deno.exe\", \"node\", \"bun\", \"bun.exe\") or\n\n ?process.code_signature.subject_name : (\"AutoIt Consulting Ltd\", \"OpenJS Foundation\", \"Python Software Foundation\") or\n\n (\n process.executable : (\"?:\\\\Users\\\\*.exe\", \"?:\\\\ProgramData\\\\*.exe\", \"/Users/Shared/*\", \"/Library/WebServer/*\", \n \"/Users/*/Library/WebServer/*\", \"/Library/Graphics/*\", \"/Users/*/Library/Graphics/*\", \"/Library/Fonts/*\", \n \"/Users/*/Library/Fonts/*\", \"/private/var/root/Library/HTTPStorages/*\", \"/tmp/*\", \"/var/tmp/*\", \"/private/tmp/*\") and\n (?process.code_signature.trusted == false or ?process.code_signature.exists == false)\n )\n ) and\n dns.question.name : (\n // Major LLM APIs\n \"api.openai.com\",\n \"*.openai.azure.com\",\n \"api.anthropic.com\",\n \"api.mistral.ai\",\n \"api.cohere.ai\",\n \"api.ai21.com\",\n \"api.groq.com\",\n \"api.perplexity.ai\",\n \"api.x.ai\",\n \"api.deepseek.com\",\n \"api.gemini.google.com\",\n \"generativelanguage.googleapis.com\",\n \"api.azure.com\",\n \"api.bedrock.aws\",\n \"bedrock-runtime.amazonaws.com\",\n\n // Hugging Face & other ML infra\n \"api-inference.huggingface.co\",\n \"inference-endpoint.huggingface.cloud\",\n \"*.hf.space\",\n \"*.replicate.com\",\n \"api.replicate.com\",\n \"api.runpod.ai\",\n \"*.runpod.io\",\n \"api.modal.com\",\n \"*.forefront.ai\",\n\n // Consumer-facing AI chat portals\n \"chat.openai.com\",\n \"chatgpt.com\",\n \"copilot.microsoft.com\",\n \"bard.google.com\",\n \"gemini.google.com\",\n \"claude.ai\",\n \"perplexity.ai\",\n \"poe.com\",\n \"chat.forefront.ai\",\n \"chat.deepseek.com\",\n\n // OpenClaw\n \"openclaw.ai\"\n ) and\n\n not process.executable : (\n \"?:\\\\Program Files\\\\*.exe\",\n \"?:\\\\Program Files (x86)\\\\*.exe\",\n \"?:\\\\Windows\\\\System32\\\\svchost.exe\",\n \"?:\\\\Windows\\\\SystemApps\\\\Microsoft.LockApp_*\\\\LockApp.exe\",\n \"?:\\\\Users\\\\*\\\\AppData\\\\Local\\\\Google\\\\Chrome\\\\Application\\\\chrome.exe\",\n \"?:\\\\Users\\\\*\\\\AppData\\\\Local\\\\BraveSoftware\\\\*\\\\Application\\\\brave.exe\",\n \"?:\\\\Users\\\\*\\\\AppData\\\\Local\\\\Vivaldi\\\\Application\\\\vivaldi.exe\",\n \"?:\\\\Users\\\\*\\\\AppData\\\\Local\\\\Programs\\\\Opera*\\\\opera.exe\",\n \"?:\\\\Users\\\\*\\\\AppData\\\\Local\\\\Programs\\\\Fiddler\\\\Fiddler.exe\"\n ) and\n not (?process.code_signature.trusted == true and\n ?process.code_signature.subject_name : (\"Anthropic, PBC\", \"Google LLC\", \"Mozilla Corporation\", \"Brave Software, Inc.\", \"Island Technology Inc.\", \"Opera Norway AS\"))\n", + "references": [ + "https://malpedia.caad.fkie.fraunhofer.de/details/py.lamehug" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "windows", + "version": "^3.0.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.exists", + "type": "boolean" + }, + { + "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" + } + ], + "risk_score": 47, + "rule_id": "4ae94fc1-f08f-419f-b692-053d28219380", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "OS: macOS", + "Use Case: Threat Detection", + "Tactic: Command and Control", + "Resources: Investigation Guide", + "Data Source: Elastic Endgame", + "Data Source: Elastic Defend", + "Data Source: SentinelOne", + "Data Source: Sysmon" + ], + "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": "eql", + "version": 3 + }, + "id": "4ae94fc1-f08f-419f-b692-053d28219380_3", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/4c59cff1-b78a-41b8-a9f1-4231984d1fb6_115.json b/packages/security_detection_engine/kibana/security_rule/4c59cff1-b78a-41b8-a9f1-4231984d1fb6_115.json new file mode 100644 index 00000000000..31c54b479ca --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/4c59cff1-b78a-41b8-a9f1-4231984d1fb6_115.json @@ -0,0 +1,148 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects PowerShell scripts that uses ShareFinder functions (Invoke-ShareFinder/Invoke-ShareFinderThreaded) or Windows share enumeration APIs (shi1_netname/shi1_remark with NetShareEnum/NetApiBufferFree). Attackers use share enumeration to map accessible network shares for collection, lateral movement, or ransomware targeting.", + "from": "now-9m", + "index": [ + "winlogbeat-*", + "logs-windows.powershell*" + ], + "investigation_fields": { + "field_names": [ + "@timestamp", + "user.name", + "user.id", + "user.domain", + "powershell.file.script_block_text", + "powershell.file.script_block_id", + "powershell.sequence", + "powershell.total", + "file.path", + "file.directory", + "file.name", + "process.pid", + "host.name", + "host.id", + "powershell.file.script_block_length" + ] + }, + "language": "kuery", + "license": "Elastic License v2", + "name": "PowerShell Share Enumeration Script", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This guide was created by humans with the assistance of generative AI. While its contents have been manually curated to include the most valuable information, always validate assumptions and adjust procedures to match your internal runbooks and incident triage and response policies.\n\n### Investigating PowerShell Share Enumeration Script\n\nThis alert indicates PowerShell script block content consistent with Windows network share enumeration. The matched text includes ShareFinder functions (for example, `Invoke-ShareFinder` or `Invoke-ShareFinderThreaded`) and/or native share enumeration API references (for example, `NetShareEnum` / `NetApiBufferFree` and `shi1_netname` / `shi1_remark`). Share discovery can be a normal administrative activity, but in attacks it is frequently used to map accessible shares prior to data collection, lateral movement, or impact activity.\n\n#### Key alert fields to review\n\n- `user.name`, `user.domain`, `user.id`: Account execution context for correlation, prioritization, and scoping.\n- `host.name`, `host.id`: Host execution context for correlation, prioritization, and scoping.\n- `powershell.file.script_block_text`: Script block content that matched the detection logic.\n- `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`: Script block metadata to pivot to other fragments or reconstruct full script content when split across multiple events.\n- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file.\n- `powershell.file.script_block_length`: Script block length (size) context.\n\n#### Possible investigation steps\n\n- Establish context and triage priority:\n - Use `@timestamp` as the activity anchor and note the executing `user.name` / `user.domain` / `user.id` and affected `host.name` / `host.id`.\n - Determine whether the account and host are expected to perform share inventory (for example, administrative workstation or management server vs. a standard user endpoint).\n - Check whether similar share enumeration activity has occurred recently for the same `user.id` or on the same `host.id` to identify repeated scanning or automation.\n\n- Review the script block content and classify the activity:\n - Inspect `powershell.file.script_block_text` and capture relevant excerpts for the case record (function names, API calls, and any referenced hosts/shares).\n - Differentiate between a function definition/import and an actual invocation:\n - Function definition or module load (lower confidence): the text contains the function name as part of a definition or import logic.\n - Function invocation (higher confidence): the text shows parameters, target lists, or loops that initiate enumeration.\n - Identify which pattern is present and what it implies about scope:\n - `Invoke-ShareFinder`: share discovery logic implemented in PowerShell.\n - `Invoke-ShareFinderThreaded`: broader or faster discovery due to concurrent enumeration.\n - `NetShareEnum` / `NetApiBufferFree` with `shi1_netname` / `shi1_remark`: direct use of Windows share enumeration APIs and may reflect customized scripting.\n - Extract scoping and intent details from the text when available:\n - Target hostnames/IPs, server lists, domain-related identifiers, or UNC paths.\n - Filters for share names and remarks, or include/exclude logic that focuses discovery on specific systems or shares.\n - Use of alternate credentials or explicit authentication material embedded in the script (if present).\n - Any output handling (formatting, writing results to disk, or staging).\n\n- Reconstruct full content when script blocks are split:\n - Pivot on `powershell.file.script_block_id` to collect all related fragments for the same execution context.\n - Use `powershell.sequence` and `powershell.total` to order fragments and identify missing pieces (if populated).\n - Review adjacent script blocks for the same `host.id` and `user.id` near `@timestamp` to capture supporting functions or follow-on actions that may not appear in the triggering fragment.\n\n- Determine whether the activity originated from an on-disk script:\n - If present, use `file.path` / `file.directory` / `file.name` to identify the script source.\n - Assess whether the script location and name align with approved administrative tooling. Scripts originating from user-writable or temporary locations are higher risk than centrally managed locations.\n - If an on-disk script is involved, preserve the file for further analysis and determine whether it appears on additional hosts (pivot on `file.name` where applicable).\n\n- Scope across users and hosts:\n - Look for additional events containing the same discovery keywords in `powershell.file.script_block_text` to identify other affected endpoints.\n - Check whether the same `user.id` performed similar activity from multiple `host.id` values in a short period, which can indicate automation or credential misuse.\n - Identify whether multiple users are performing similar enumeration from the same host, which can indicate a shared jump box or a compromised administrative endpoint.\n\n- Correlate with adjacent telemetry (as available) to confirm intent and detect follow-on behavior:\n - Process execution telemetry on the same `host.id` around `@timestamp` to determine how PowerShell was launched and whether the initiating process and execution pattern are consistent with expected activity for `user.id`.\n - Network telemetry around `@timestamp` for access to multiple remote hosts consistent with share enumeration and subsequent SMB activity.\n - Authentication telemetry for `user.id` around `@timestamp` for unusual access to file servers or multiple servers, especially if the behavior is new for the account.\n - File activity telemetry (endpoint and/or file server) for unusual access patterns to shared locations following the enumeration (for example, rapid directory traversal or access to sensitive paths).\n\n- Assess risk and impact:\n - Prioritize investigation if the script targets high-value systems (for example, file servers) or if the discovery appears broad (large target lists, threading, repeated runs).\n - If the executing `user.id` is privileged or the host is sensitive, treat the alert as higher risk and expand scoping to additional related activity.\n\n### False positive analysis\n\n- Legitimate administrative share inventory, auditing, or documentation activity performed by IT or infrastructure teams.\n- Approved operational scripts used for backup validation, migration planning, access reviews, or troubleshooting that enumerate shares across servers.\n\n### Response and remediation\n\n- If the activity is unauthorized or suspicious:\n - Contain the affected endpoint (`host.id`) following your incident response procedures to reduce the risk of further discovery and lateral movement.\n - Preserve evidence by retaining the complete `powershell.file.script_block_text` content and all fragments linked by `powershell.file.script_block_id` (including ordered reconstruction using `powershell.sequence` / `powershell.total` when available).\n - Identify and prioritize potential targets referenced in the script content (servers and shares) and coordinate review of access patterns to those resources.\n - Investigate the executing account (`user.name` / `user.id`) for compromise, including recent authentication activity and unexpected resource access, and take appropriate containment actions (credential reset, privilege review, and session invalidation where applicable).\n - Expand hunting for additional share enumeration and subsequent access attempts associated with the same `user.id` or originating from the same `host.id`.\n - If an on-disk script was used (`file.path` / `file.name` present), remove or quarantine the artifact per your response process and check for the same file on other systems.\n\n- If the activity is confirmed benign:\n - Document the owner, purpose, expected timing, and expected scope (accounts and endpoints) of the share enumeration.\n - If tuning is required, scope it narrowly to stable identifiers present in the alert (for example, specific `user.id` values and known management `host.id` endpoints) and continue to monitor for deviations from the expected pattern.\n - Consider establishing a documented allowlist of approved share inventory scripts and their expected execution locations to reduce future triage time.\n", + "query": "event.category:process and host.os.type:windows and\n powershell.file.script_block_text:(\n \"Invoke-ShareFinder\" or\n \"Invoke-ShareFinderThreaded\" or\n (\n \"shi1_netname\" and\n \"shi1_remark\"\n ) or\n (\n \"NetShareEnum\" and\n \"NetApiBufferFree\"\n )\n ) and not user.id : \"S-1-5-18\"\n", + "references": [ + "https://www.advintel.io/post/hunting-for-corporate-insurance-policies-indicators-of-ransom-exfiltrations", + "https://thedfirreport.com/2022/04/04/stolen-images-campaign-ends-in-conti-ransomware/", + "https://github.com/atc-project/atc-data/blob/master/docs/Logging_Policies/LP_0109_windows_powershell_script_block_log.md" + ], + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.category", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_text", + "type": "unknown" + }, + { + "ecs": true, + "name": "user.id", + "type": "keyword" + } + ], + "risk_score": 73, + "rule_id": "4c59cff1-b78a-41b8-a9f1-4231984d1fb6", + "setup": "## Setup\n\nPowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104).\nSetup instructions: https://ela.st/powershell-logging-setup\n", + "severity": "high", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Discovery", + "Tactic: Collection", + "Tactic: Execution", + "Resources: Investigation Guide", + "Data Source: PowerShell Logs" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0007", + "name": "Discovery", + "reference": "https://attack.mitre.org/tactics/TA0007/" + }, + "technique": [ + { + "id": "T1135", + "name": "Network Share Discovery", + "reference": "https://attack.mitre.org/techniques/T1135/" + } + ] + }, + { + "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": "T1106", + "name": "Native API", + "reference": "https://attack.mitre.org/techniques/T1106/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0009", + "name": "Collection", + "reference": "https://attack.mitre.org/tactics/TA0009/" + }, + "technique": [ + { + "id": "T1039", + "name": "Data from Network Shared Drive", + "reference": "https://attack.mitre.org/techniques/T1039/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 115 + }, + "id": "4c59cff1-b78a-41b8-a9f1-4231984d1fb6_115", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/50742e15-c5ef-49c8-9a2d-31221d45af58_1.json b/packages/security_detection_engine/kibana/security_rule/50742e15-c5ef-49c8-9a2d-31221d45af58_1.json new file mode 100644 index 00000000000..b96d26cbf1f --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/50742e15-c5ef-49c8-9a2d-31221d45af58_1.json @@ -0,0 +1,217 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Correlates Okta credential attack alerts with subsequent successful authentication for the same user account, identifying potential compromise following brute force, password spray, or credential stuffing attempts.", + "false_positives": [ + "A user experiencing legitimate login issues (forgotten password, typos) may trigger credential attack alerts before successfully authenticating.", + "Automated password reset flows where a user fails multiple times then succeeds after resetting their password." + ], + "from": "now-6h", + "interval": "30m", + "language": "esql", + "license": "Elastic License v2", + "name": "Okta Successful Login After Credential Attack", + "note": "## Triage and analysis\n\n### Investigating Okta Successful Login After Credential Attack\n\nThis rule correlates credential attack alerts with subsequent successful authentication for the same user account. The correlation is user-centric, capturing IP rotation scenarios where attackers may login from a different IP after obtaining credentials.\n\n#### Possible investigation steps\n- Identify the user account and review the timeline between the attack and successful login.\n- Compare the attack source IPs versus the login source IP to identify potential IP rotation.\n- Review the original credential attack alert to understand the scope and nature of the attack.\n- Check the authentication method used and whether MFA was required and satisfied.\n- Review the session activity following the successful login for signs of account takeover.\n- Verify with the user if the login was legitimate.\n\n### False positive analysis\n- Users experiencing legitimate login issues may trigger attack alerts before successfully authenticating.\n- Automated password reset flows where a user fails multiple times then succeeds after resetting may trigger this rule.\n- The rule correlates on user identity only, so it fires when a user is targeted and later logs in, even if from different IPs.\n\n### Response and remediation\n- If compromise is suspected, reset the user's password and revoke all active sessions.\n- Reset MFA if the attacker may have enrolled their own device.\n- Block the source IP at the network perimeter.\n- Review the user's recent activity for signs of lateral movement or data access.\n- Check for persistence mechanisms such as new OAuth apps, API tokens, or enrolled devices.\n", + "query": "FROM .alerts-security.*, logs-okta.system-* METADATA _id, _version, _index\n// Filter for credential attack alerts OR successful Okta authentications\n| WHERE\n (\n // Credential attack alerts from the five correlated rules\n kibana.alert.rule.rule_id IN (\n \"94e734c0-2cda-11ef-84e1-f661ea17fbce\", // Credential Stuffing\n \"42bf698b-4738-445b-8231-c834ddefd8a0\", // Password Spraying\n \"23f18264-2d6d-11ef-9413-f661ea17fbce\", // DT Brute Force\n \"5889760c-9858-4b4b-879c-e299df493295\", // Distributed Brute Force\n \"2d3c27d5-d133-4152-8102-8d051619ec4a\" // Distributed Spray\n )\n )\n OR (\n // Successful Okta authentication events\n event.dataset == \"okta.system\"\n AND (event.action LIKE \"user.authentication.*\" OR event.action == \"user.session.start\")\n AND okta.outcome.result == \"SUCCESS\"\n AND okta.actor.alternate_id IS NOT NULL\n )\n// correlation - alerts may store user/IP in different fields than raw logs\n| EVAL\n Esql.user = COALESCE(okta.actor.alternate_id, user.name, user.email),\n Esql.source_ip = COALESCE(okta.client.ip, client.ip, source.ip)\n// Must have user identity to correlate\n| WHERE Esql.user IS NOT NULL\n// Classify events and capture timestamps/IPs by event type\n| EVAL\n Esql.is_attack_alert = CASE(\n kibana.alert.rule.rule_id IN (\n \"94e734c0-2cda-11ef-84e1-f661ea17fbce\",\n \"42bf698b-4738-445b-8231-c834ddefd8a0\",\n \"23f18264-2d6d-11ef-9413-f661ea17fbce\",\n \"5889760c-9858-4b4b-879c-e299df493295\",\n \"2d3c27d5-d133-4152-8102-8d051619ec4a\"\n ), 1, 0\n ),\n Esql.is_success_login = CASE(\n event.dataset == \"okta.system\"\n AND okta.outcome.result == \"SUCCESS\", 1, 0\n ),\n Esql.attack_ip = CASE(\n kibana.alert.rule.rule_id IN (\n \"94e734c0-2cda-11ef-84e1-f661ea17fbce\",\n \"42bf698b-4738-445b-8231-c834ddefd8a0\",\n \"23f18264-2d6d-11ef-9413-f661ea17fbce\",\n \"5889760c-9858-4b4b-879c-e299df493295\",\n \"2d3c27d5-d133-4152-8102-8d051619ec4a\"\n ), Esql.source_ip, null\n ),\n Esql.login_ip = CASE(\n event.dataset == \"okta.system\"\n AND okta.outcome.result == \"SUCCESS\", Esql.source_ip, null\n ),\n Esql.attack_ts = CASE(\n kibana.alert.rule.rule_id IN (\n \"94e734c0-2cda-11ef-84e1-f661ea17fbce\",\n \"42bf698b-4738-445b-8231-c834ddefd8a0\",\n \"23f18264-2d6d-11ef-9413-f661ea17fbce\",\n \"5889760c-9858-4b4b-879c-e299df493295\",\n \"2d3c27d5-d133-4152-8102-8d051619ec4a\"\n ), @timestamp, null\n ),\n Esql.login_ts = CASE(\n event.dataset == \"okta.system\"\n AND okta.outcome.result == \"SUCCESS\", @timestamp, null\n )\n// Aggregate by user (catches IP rotation: spray from IP A, login from IP B)\n| STATS\n Esql.attack_count = SUM(Esql.is_attack_alert),\n Esql.login_count = SUM(Esql.is_success_login),\n Esql.earliest_attack = MIN(Esql.attack_ts),\n Esql.latest_attack = MAX(Esql.attack_ts),\n Esql.earliest_login = MIN(Esql.login_ts),\n Esql.latest_login = MAX(Esql.login_ts),\n Esql.attack_source_ips = VALUES(Esql.attack_ip),\n Esql.login_source_ips = VALUES(Esql.login_ip),\n Esql.all_source_ips = VALUES(Esql.source_ip),\n Esql.alert_rule_ids = VALUES(kibana.alert.rule.rule_id),\n Esql.alert_rule_names = VALUES(kibana.alert.rule.name),\n Esql.event_action_values = VALUES(event.action),\n Esql.geo_country_values = VALUES(client.geo.country_name),\n Esql.geo_city_values = VALUES(client.geo.city_name),\n Esql.source_asn_values = VALUES(source.as.number),\n Esql.source_asn_org_values = VALUES(source.as.organization.name),\n Esql.user_agent_values = VALUES(okta.client.user_agent.raw_user_agent),\n Esql.device_values = VALUES(okta.client.device),\n Esql.is_proxy_values = VALUES(okta.security_context.is_proxy)\n BY Esql.user\n// Calculate time gap between latest attack and earliest subsequent login\n| EVAL Esql.attack_to_login_minutes = DATE_DIFF(\"minute\", Esql.latest_attack, Esql.earliest_login)\n// Correlation: attack BEFORE login + success within reasonable window (3 hours)\n| WHERE\n Esql.attack_count > 0\n AND Esql.login_count > 0\n AND Esql.latest_attack < Esql.earliest_login\n AND Esql.attack_to_login_minutes <= 180\n| SORT Esql.login_count DESC\n| KEEP Esql.*\n", + "references": [ + "https://support.okta.com/help/s/article/Troubleshooting-Distributed-Brute-Force-andor-Password-Spray-attacks-in-Okta", + "https://www.okta.com/identity-101/brute-force/", + "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://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security", + "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta" + ], + "related_integrations": [ + { + "package": "okta", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.alert_rule_ids", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.alert_rule_names", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.all_source_ips", + "type": "ip" + }, + { + "ecs": false, + "name": "Esql.attack_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.attack_source_ips", + "type": "ip" + }, + { + "ecs": false, + "name": "Esql.attack_to_login_minutes", + "type": "integer" + }, + { + "ecs": false, + "name": "Esql.device_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.earliest_attack", + "type": "date" + }, + { + "ecs": false, + "name": "Esql.earliest_login", + "type": "date" + }, + { + "ecs": false, + "name": "Esql.event_action_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.geo_city_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.geo_country_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.is_proxy_values", + "type": "boolean" + }, + { + "ecs": false, + "name": "Esql.latest_attack", + "type": "date" + }, + { + "ecs": false, + "name": "Esql.latest_login", + "type": "date" + }, + { + "ecs": false, + "name": "Esql.login_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.login_source_ips", + "type": "ip" + }, + { + "ecs": false, + "name": "Esql.source_asn_org_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.source_asn_values", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.user", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.user_agent_values", + "type": "keyword" + } + ], + "risk_score": 73, + "rule_id": "50742e15-c5ef-49c8-9a2d-31221d45af58", + "setup": "## Setup\n\nThis rule requires the following:\n1. The Okta Fleet integration, Filebeat module, or similarly structured data for Okta System Logs.\n2. The correlated credential attack detection rules must be enabled (at least one):\n - Potential Okta Credential Stuffing (Single Source) (94e734c0-2cda-11ef-84e1-f661ea17fbce)\n - Potential Okta Password Spray (Single Source) (42bf698b-4738-445b-8231-c834ddefd8a0)\n - Potential Okta Brute Force (Device Token Rotation) (23f18264-2d6d-11ef-9413-f661ea17fbce)\n - Potential Okta Brute Force (Multi-Source) (5889760c-9858-4b4b-879c-e299df493295)\n - Potential Okta Password Spray (Multi-Source) (2d3c27d5-d133-4152-8102-8d051619ec4a)\n3. Alerts from these rules must be written to the `.alerts-security.*` indices.\n\nThe rule queries both alert indices and Okta log indices to correlate attack alerts with successful logins.", + "severity": "high", + "tags": [ + "Domain: Identity", + "Use Case: Identity and Access Audit", + "Use Case: Threat Detection", + "Data Source: Okta", + "Data Source: Okta System Logs", + "Tactic: Credential Access", + "Tactic: Initial Access", + "Resources: Investigation Guide", + "Rule Type: Higher-Order Rule" + ], + "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/" + } + ] + } + ] + }, + { + "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": 1 + }, + "id": "50742e15-c5ef-49c8-9a2d-31221d45af58_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/56f2e9b5-4803-4e44-a0a4-a52dc79d57fe_317.json b/packages/security_detection_engine/kibana/security_rule/56f2e9b5-4803-4e44-a0a4-a52dc79d57fe_317.json new file mode 100644 index 00000000000..cd0ff826a34 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/56f2e9b5-4803-4e44-a0a4-a52dc79d57fe_317.json @@ -0,0 +1,133 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects PowerShell scripts that implements PSReflect-style helpers (for example, Add-Win32Type, New-InMemoryModule, or DllImport patterns) for dynamic Win32 API invocation. Attackers use PSReflect to call native APIs from PowerShell for execution, injection, or privilege manipulation.", + "false_positives": [ + "Legitimate PowerShell scripts that make use of PSReflect to access the win32 API" + ], + "filters": [ + { + "meta": { + "negate": true + }, + "query": { + "wildcard": { + "file.path": { + "case_insensitive": true, + "value": "?:\\\\ProgramData\\\\MaaS360\\\\Cloud Extender\\\\AR\\\\Scripts\\\\ASModuleCommon.ps1" + } + } + } + } + ], + "from": "now-9m", + "index": [ + "winlogbeat-*", + "logs-windows.powershell*" + ], + "investigation_fields": { + "field_names": [ + "@timestamp", + "user.name", + "user.id", + "user.domain", + "powershell.file.script_block_text", + "powershell.file.script_block_id", + "powershell.sequence", + "powershell.total", + "file.path", + "file.directory", + "file.name", + "process.pid", + "host.name", + "host.id", + "powershell.file.script_block_length" + ] + }, + "language": "kuery", + "license": "Elastic License v2", + "name": "PowerShell PSReflect Script", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This guide was created by humans with the assistance of generative AI. While its contents have been manually curated to include the most valuable information, always validate assumptions and adjust procedures to match your internal runbooks and incident triage and response policies.\n\n### Investigating PowerShell PSReflect Script\n\nThis rule detects PowerShell scripts consistent with PSReflect-style helpers used to dynamically define in-memory .NET types and invoke Win32 APIs via interop (for example, Add-Win32Type, New-InMemoryModule, and DllImport patterns). This technique can be used for legitimate administration and development, but it is also commonly used by adversaries to access native capabilities from PowerShell.\n\n#### Key alert fields to review\n\n- `user.name`, `user.domain`, `user.id`: Account execution context for correlation, prioritization, and scoping.\n- `host.name`, `host.id`: Host execution context for correlation, prioritization, and scoping.\n- `powershell.file.script_block_text`: Script block content that matched the detection logic.\n- `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`: Script block metadata to pivot to other fragments or reconstruct full script content when split across multiple events.\n- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file.\n- `powershell.file.script_block_length`: Script block length (size) context.\n\n#### Possible investigation steps\n\n- Review the alert context to prioritize the investigation:\n - Identify the affected host (`host.name`, `host.id`) and the execution context (`user.name`, `user.domain`, `user.id`).\n - Use `@timestamp` to scope a short timeline around the activity and identify related alerts on the same host or user.\n - Treat activity as higher risk when the executing account is unexpected for PowerShell development/administration or when the host is not typically used for scripting.\n\n- Reconstruct the complete script block content before assessing intent:\n - Pivot on `powershell.file.script_block_id` to locate all related events.\n - Order events by `powershell.sequence` and confirm whether the observed sequence aligns with `powershell.total`.\n - Combine the fragments into a single script view to avoid misinterpreting partial content.\n\n- Analyze `powershell.file.script_block_text` to understand capability and likely intent:\n - Identify which PSReflect artifacts are present (for example, `Add-Win32Type`, `New-InMemoryModule`, `psenum`, `DefineDynamicAssembly`, `DefineDynamicModule`, and `Runtime.InteropServices.DllImportAttribute`).\n - Determine whether the content is primarily a helper library (type/struct/enum definitions and import scaffolding) or includes immediate API calls or operational logic.\n - If `DllImportAttribute` is used, extract the referenced DLLs and imported function names from the script text and map them to likely objectives (for example, process/memory operations, token and privilege manipulation, registry or service interaction, or networking).\n - Capture distinctive identifiers from the script (function names, type names, imported API names, unique strings) to support scoping and hunting.\n\n- Establish script origin and distribution:\n - If `file.path`/`file.name` are present, treat the script as file-backed and assess whether the location and filename align with approved tooling and change control.\n - If `file.path` is not present, consider that the script may have been executed interactively or delivered in-memory, and prioritize correlation with surrounding activity for the same `user.id` and `host.id`.\n\n- Scope the activity across time, hosts, and users:\n - Search for additional script blocks on the same `host.id` and `user.id` around `@timestamp` to identify preceding staging activity and follow-on behavior.\n - Hunt across the environment for the same `file.path`/`file.name` and for distinctive strings extracted from `powershell.file.script_block_text` to identify other impacted hosts.\n - Pivot on `user.id` to determine whether the same account executed similar PSReflect content on other endpoints.\n\n- Correlate with adjacent telemetry (if available) to confirm execution chain and impact:\n - Process telemetry: identify the PowerShell host process and its parent process to understand how the script was initiated (interactive, automated, or remote execution context).\n - Network telemetry: review DNS lookups and outbound connections near the alert time for evidence of staging, command-and-control, or lateral movement.\n - Endpoint changes: review file, service, scheduled task, and registry activity after the script execution to identify persistence, payload delivery, or privilege changes that align with the capabilities implied by the script text.\n - If Elastic Osquery response actions are available, collect DNS cache and service inventory to support scoping and to identify suspicious services or unsigned service binaries.\n\n### False positive analysis\n\n- False positives are possible in environments where administrators, developers, or internal tooling use PSReflect-style code to access native APIs from PowerShell.\n- Validate legitimacy by confirming that:\n - The executing account and host are expected to run advanced PowerShell code (`user.id`, `user.name`, `host.id`, `host.name`).\n - The script source is known and controlled when `file.path`/`file.name` are present (for example, approved repositories, deployment paths, or administrative script locations).\n - The script content and its imported APIs are consistent with a documented operational need and do not align with common attacker objectives (for example, credential access, injection, or persistence).\n- If the activity is recurring, baseline expected frequency and approved users/hosts to distinguish routine usage from anomalous execution.\n\n### Response and remediation\n\n- If malicious activity is confirmed or suspected:\n - Contain the affected host to prevent further execution and lateral movement, following your incident response procedures.\n - Preserve evidence: the fully reconstructed script (`powershell.file.script_block_id` with `powershell.sequence`/`powershell.total`), the raw script content (`powershell.file.script_block_text`), and any referenced file path details (`file.path`, `file.name`).\n - Use extracted identifiers (imported API names, helper function names, unique strings) to hunt for related activity across other hosts and users.\n - Investigate and remediate follow-on activity identified during correlation (persistence mechanisms, suspicious services, unexpected outbound connections, and any dropped or modified files).\n - If account compromise is suspected, reset credentials for the impacted user and review recent authentication activity to identify additional compromised assets.\n\n- If the activity is confirmed benign:\n - Document the legitimate script/tool, expected hosts/users, and the operational purpose to speed up future triage.\n - Where appropriate, improve controls around advanced PowerShell usage (least privilege for scripting accounts, controlled script distribution, code review, and continued logging coverage).\n", + "query": "event.category:process and host.os.type:windows and\n powershell.file.script_block_text:(\n \"New-InMemoryModule\" or\n \"Add-Win32Type\" or\n psenum or\n DefineDynamicAssembly or\n DefineDynamicModule or\n \"Reflection.TypeAttributes\" or\n \"Reflection.Emit.OpCodes\" or\n \"Reflection.Emit.CustomAttributeBuilder\" or\n \"Runtime.InteropServices.DllImportAttribute\"\n ) and\n not user.id : \"S-1-5-18\"\n", + "references": [ + "https://github.com/mattifestation/PSReflect/blob/master/PSReflect.psm1", + "https://github.com/atc-project/atc-data/blob/master/docs/Logging_Policies/LP_0109_windows_powershell_script_block_log.md" + ], + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.category", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_text", + "type": "unknown" + }, + { + "ecs": true, + "name": "user.id", + "type": "keyword" + } + ], + "risk_score": 73, + "rule_id": "56f2e9b5-4803-4e44-a0a4-a52dc79d57fe", + "setup": "## Setup\n\nPowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104).\nSetup instructions: https://ela.st/powershell-logging-setup\n", + "severity": "high", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Execution", + "Resources: Investigation Guide", + "Data Source: PowerShell Logs" + ], + "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": "T1106", + "name": "Native API", + "reference": "https://attack.mitre.org/techniques/T1106/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 317 + }, + "id": "56f2e9b5-4803-4e44-a0a4-a52dc79d57fe_317", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/56fdfcf1-ca7c-4fd9-951d-e215ee26e404_108.json b/packages/security_detection_engine/kibana/security_rule/56fdfcf1-ca7c-4fd9-951d-e215ee26e404_108.json new file mode 100644 index 00000000000..759219c63f3 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/56fdfcf1-ca7c-4fd9-951d-e215ee26e404_108.json @@ -0,0 +1,129 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "building_block_type": "default", + "description": "This rule identifies the execution of unsigned executables via service control manager (SCM). Adversaries may abuse SCM to execute malware or escalate privileges.", + "from": "now-9m", + "history_window_start": "now-5d", + "index": [ + "logs-endpoint.events.process-*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "Execution of an Unsigned Service", + "new_terms_fields": [ + "host.id", + "process.executable", + "user.id" + ], + "query": "host.os.type:windows and event.category:process and event.type:start and \nprocess.parent.executable:\"C:\\\\Windows\\\\System32\\\\services.exe\" and \n(process.code_signature.exists:false or process.code_signature.trusted:false) and\nnot process.code_signature.status : (errorCode_endpoint* or \"errorChaining\")\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.code_signature.exists", + "type": "boolean" + }, + { + "ecs": true, + "name": "process.code_signature.status", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.code_signature.trusted", + "type": "boolean" + }, + { + "ecs": true, + "name": "process.parent.executable", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "56fdfcf1-ca7c-4fd9-951d-e215ee26e404", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Execution", + "Tactic: Defense Evasion", + "Rule Type: BBR", + "Data Source: Elastic Defend" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1569", + "name": "System Services", + "reference": "https://attack.mitre.org/techniques/T1569/", + "subtechnique": [ + { + "id": "T1569.002", + "name": "Service Execution", + "reference": "https://attack.mitre.org/techniques/T1569/002/" + } + ] + } + ] + }, + { + "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/", + "subtechnique": [ + { + "id": "T1036.001", + "name": "Invalid Code Signature", + "reference": "https://attack.mitre.org/techniques/T1036/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "new_terms", + "version": 108 + }, + "id": "56fdfcf1-ca7c-4fd9-951d-e215ee26e404_108", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/5889760c-9858-4b4b-879c-e299df493295_1.json b/packages/security_detection_engine/kibana/security_rule/5889760c-9858-4b4b-879c-e299df493295_1.json new file mode 100644 index 00000000000..1c1f5d96daf --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/5889760c-9858-4b4b-879c-e299df493295_1.json @@ -0,0 +1,196 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects potential brute force attacks against a single Okta user account from multiple source IPs, indicating attackers rotating through proxy infrastructure to evade IP-based detection.", + "false_positives": [ + "Users with legitimate multi-location access (mobile + home + office) experiencing concurrent login issues.", + "Shared service accounts accessed from multiple legitimate infrastructure IPs." + ], + "from": "now-30m", + "language": "esql", + "license": "Elastic License v2", + "name": "Potential Okta Brute Force (Multi-Source)", + "note": "## Triage and analysis\n\n### Investigating Potential Okta Brute Force (Multi-Source)\n\nThis rule identifies a single user account receiving failed authentication attempts from multiple unique source IPs. This pattern indicates attackers rotating through proxy infrastructure to evade IP-based detection while targeting a specific account.\n\n#### Possible investigation steps\n- Identify the targeted user account and determine if it has elevated privileges or sensitive access.\n- Review the geographic distribution of source IPs for anomalies such as multiple countries or unusual locations.\n- Examine the ASN ownership of source IPs for signs of proxy, VPN, or cloud infrastructure.\n- Check if Okta flagged any of the sources as known threats or proxies.\n- Determine if any authentication attempts succeeded following the failed attempts.\n- Review the user's recent activity for signs of account compromise.\n\n### False positive analysis\n- Users traveling internationally with mobile devices may generate failed attempts from multiple locations.\n- Service accounts accessed from distributed legitimate infrastructure may trigger this rule.\n- Corporate VPN exit nodes spread across regions could appear as multiple IPs for a single user.\n\n### Response and remediation\n- If attack is confirmed, reset the user's password immediately.\n- Review and potentially reset MFA for the targeted account.\n- Block attacking IP addresses at the network perimeter.\n- Consider implementing geo-restrictions for the targeted account if dispersed access is not expected.\n- Monitor for any successful authentication that may indicate compromise.\n", + "query": "FROM logs-okta.system-* METADATA _id, _version, _index\n| WHERE event.dataset == \"okta.system\"\n AND (event.action LIKE \"user.authentication.*\" OR event.action == \"user.session.start\")\n AND okta.outcome.reason IN (\"INVALID_CREDENTIALS\", \"LOCKED_OUT\")\n AND okta.actor.alternate_id IS NOT NULL\n\n// Create source mapping for analyst context\n| EVAL Esql.source_info = CONCAT(\n \"{\\\"ip\\\":\\\"\", COALESCE(okta.client.ip::STRING, \"unknown\"),\n \"\\\",\\\"country\\\":\\\"\", COALESCE(client.geo.country_name, \"unknown\"),\n \"\\\",\\\"asn\\\":\\\"\", COALESCE(source.as.organization.name, \"unknown\"),\n \"\\\",\\\"user_agent\\\":\\\"\", COALESCE(okta.client.user_agent.raw_user_agent, \"unknown\"), \"\\\"}\"\n )\n\n| STATS\n Esql.unique_source_ips = COUNT_DISTINCT(okta.client.ip),\n Esql.total_attempts = COUNT(*),\n Esql.unique_user_agents = COUNT_DISTINCT(okta.client.user_agent.raw_user_agent),\n Esql.unique_dt_hashes = COUNT_DISTINCT(okta.debug_context.debug_data.dt_hash),\n Esql.unique_asns = COUNT_DISTINCT(source.as.number),\n Esql.unique_countries = COUNT_DISTINCT(client.geo.country_name),\n Esql.first_seen = MIN(@timestamp),\n Esql.last_seen = MAX(@timestamp),\n Esql.source_ip_values = VALUES(okta.client.ip),\n Esql.source_mapping = VALUES(Esql.source_info),\n Esql.event_action_values = VALUES(event.action),\n Esql.user_agent_values = VALUES(okta.client.user_agent.raw_user_agent),\n Esql.device_values = VALUES(okta.client.device),\n Esql.is_proxy_values = VALUES(okta.security_context.is_proxy),\n Esql.geo_country_values = VALUES(client.geo.country_name),\n Esql.geo_city_values = VALUES(client.geo.city_name),\n Esql.source_asn_values = VALUES(source.as.number),\n Esql.source_asn_org_values = VALUES(source.as.organization.name),\n Esql.threat_suspected_values = VALUES(okta.debug_context.debug_data.threat_suspected),\n Esql.risk_level_values = VALUES(okta.debug_context.debug_data.risk_level),\n Esql.risk_reasons_values = VALUES(okta.debug_context.debug_data.risk_reasons)\n BY okta.actor.alternate_id\n\n| EVAL\n Esql.attempts_per_ip = Esql.total_attempts * 1.0 / Esql.unique_source_ips,\n Esql.duration_seconds = DATE_DIFF(\"seconds\", Esql.first_seen, Esql.last_seen)\n\n| WHERE\n Esql.unique_source_ips >= 5\n AND Esql.total_attempts >= 10\n AND (\n Esql.unique_countries >= 2 OR\n Esql.unique_asns >= 3 OR\n Esql.unique_source_ips >= 8 OR\n Esql.unique_user_agents >= 3\n )\n\n| SORT Esql.unique_source_ips DESC\n| KEEP Esql.*, okta.actor.alternate_id\n", + "references": [ + "https://support.okta.com/help/s/article/Troubleshooting-Distributed-Brute-Force-andor-Password-Spray-attacks-in-Okta", + "https://www.okta.com/identity-101/brute-force/", + "https://developer.okta.com/docs/reference/api/event-types/", + "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy", + "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security", + "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta" + ], + "related_integrations": [ + { + "package": "okta", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.attempts_per_ip", + "type": "double" + }, + { + "ecs": false, + "name": "Esql.device_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.duration_seconds", + "type": "integer" + }, + { + "ecs": false, + "name": "Esql.event_action_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.first_seen", + "type": "date" + }, + { + "ecs": false, + "name": "Esql.geo_city_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.geo_country_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.is_proxy_values", + "type": "boolean" + }, + { + "ecs": false, + "name": "Esql.last_seen", + "type": "date" + }, + { + "ecs": false, + "name": "Esql.risk_level_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.risk_reasons_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.source_asn_org_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.source_asn_values", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.source_ip_values", + "type": "ip" + }, + { + "ecs": false, + "name": "Esql.source_mapping", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.threat_suspected_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.total_attempts", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.unique_asns", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.unique_countries", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.unique_dt_hashes", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.unique_source_ips", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.unique_user_agents", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.user_agent_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "okta.actor.alternate_id", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "5889760c-9858-4b4b-879c-e299df493295", + "setup": "The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.", + "severity": "medium", + "tags": [ + "Domain: Identity", + "Use Case: Identity and Access Audit", + "Use Case: Threat Detection", + "Data Source: Okta", + "Data Source: Okta System Logs", + "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": 1 + }, + "id": "5889760c-9858-4b4b-879c-e299df493295_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/5930658c-2107-4afc-91af-e0e55b7f7184_212.json b/packages/security_detection_engine/kibana/security_rule/5930658c-2107-4afc-91af-e0e55b7f7184_212.json new file mode 100644 index 00000000000..14cae678771 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/5930658c-2107-4afc-91af-e0e55b7f7184_212.json @@ -0,0 +1,96 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects the occurrence of emails reported as Phishing or Malware by Users. Security Awareness training is essential to stay ahead of scammers and threat actors, as security products can be bypassed, and the user can still receive a malicious message. Educating users to report suspicious messages can help identify gaps in security controls and prevent malware infections and Business Email Compromise attacks.", + "false_positives": [ + "Legitimate files reported by the users" + ], + "from": "now-9m", + "index": [ + "logs-o365.audit-*", + "filebeat-*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "Deprecated - M365 Security Compliance Email Reported by User as Malware or Phish", + "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 - M365 Security Compliance Email Reported by User as Malware or Phish\n\nMicrosoft 365's email services are integral to business communication, but they can be exploited by adversaries through phishing or malware-laden emails. Attackers may bypass security measures, reaching users who might unwittingly engage with malicious content. The detection rule leverages user reports of suspicious emails, correlating them with security events to identify potential threats, thus enhancing the organization's ability to respond to phishing attempts and malware distribution.\n\n### Possible investigation steps\n\n- Review the details of the alert triggered by the rule \"Email reported by user as malware or phish\" in the SecurityComplianceCenter to understand the context and specifics of the reported email.\n- Examine the event dataset from o365.audit to gather additional information about the email, such as sender, recipient, subject line, and any attachments or links included.\n- Correlate the reported email with other security events or alerts to identify any patterns or related incidents that might indicate a broader phishing campaign or malware distribution attempt.\n- Check the user's report against known phishing or malware indicators, such as suspicious domains or IP addresses, using threat intelligence sources to assess the credibility of the threat.\n- Investigate the user's activity following the receipt of the email to determine if any actions were taken that could have compromised the system, such as clicking on links or downloading attachments.\n- Assess the effectiveness of current security controls and awareness training by analyzing how the email bypassed existing defenses and was reported by the user.\n\n### False positive analysis\n\n- User-reported emails from trusted internal senders can trigger false positives. Encourage users to verify the sender's identity before reporting and consider adding these senders to an allowlist if they are consistently flagged.\n- Automated system notifications or newsletters may be mistakenly reported as phishing. Educate users on recognizing legitimate automated communications and exclude these sources from triggering alerts.\n- Emails containing marketing or promotional content from known vendors might be reported as suspicious. Train users to differentiate between legitimate marketing emails and phishing attempts, and create exceptions for verified vendors.\n- Frequent reports of emails from specific domains that are known to be safe can lead to unnecessary alerts. Implement domain-based exceptions for these trusted domains to reduce false positives.\n- Encourage users to provide detailed reasons for reporting an email as suspicious, which can help in refining detection rules and reducing false positives over time.\n\n### Response and remediation\n\n- Isolate the affected email account to prevent further interaction with potentially malicious content and to stop any ongoing unauthorized access.\n- Quarantine the reported email and any similar emails identified in the system to prevent other users from accessing them.\n- Conduct a thorough scan of the affected user's device and network for any signs of malware or unauthorized access, using endpoint detection and response tools.\n- Reset the credentials of the affected user account and any other accounts that may have been compromised to prevent further unauthorized access.\n- Notify the security team and relevant stakeholders about the incident, providing details of the threat and actions taken, to ensure coordinated response efforts.\n- Review and update email filtering and security policies to address any identified gaps that allowed the malicious email to bypass existing controls.\n- Monitor for any further suspicious activity related to the incident, using enhanced logging and alerting mechanisms to detect similar threats in the future.", + "query": "event.dataset:o365.audit and event.provider:SecurityComplianceCenter and event.action:AlertTriggered and rule.name:\"Email reported by user as malware or phish\"\n", + "references": [ + "https://support.microsoft.com/en-us/office/use-the-report-message-add-in-b5caa9f1-cdf3-4443-af8c-ff724ea719d2?ui=en-us&rs=en-us&ad=us" + ], + "related_integrations": [ + { + "package": "o365", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.provider", + "type": "keyword" + }, + { + "ecs": true, + "name": "rule.name", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "5930658c-2107-4afc-91af-e0e55b7f7184", + "setup": "The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Data Source: Microsoft 365", + "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": "T1566", + "name": "Phishing", + "reference": "https://attack.mitre.org/techniques/T1566/", + "subtechnique": [ + { + "id": "T1566.001", + "name": "Spearphishing Attachment", + "reference": "https://attack.mitre.org/techniques/T1566/001/" + }, + { + "id": "T1566.002", + "name": "Spearphishing Link", + "reference": "https://attack.mitre.org/techniques/T1566/002/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 212 + }, + "id": "5930658c-2107-4afc-91af-e0e55b7f7184_212", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/5bb4a95d-5a08-48eb-80db-4c3a63ec78a8_320.json b/packages/security_detection_engine/kibana/security_rule/5bb4a95d-5a08-48eb-80db-4c3a63ec78a8_320.json new file mode 100644 index 00000000000..4f9d1d96056 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/5bb4a95d-5a08-48eb-80db-4c3a63ec78a8_320.json @@ -0,0 +1,207 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects attempts to exploit privilege escalation vulnerabilities related to the Print Spooler service. For more information refer to the following CVE's - CVE-2020-1048, CVE-2020-1337 and CVE-2020-1300 and verify that the impacted system is patched.", + "filters": [ + { + "meta": { + "negate": false + }, + "query": { + "wildcard": { + "file.path": { + "case_insensitive": true, + "value": "?:\\\\Windows\\\\Sys?????\\\\*" + } + } + } + }, + { + "meta": { + "negate": true + }, + "query": { + "wildcard": { + "file.path": { + "case_insensitive": true, + "value": "?:\\\\Windows\\\\Sys?????\\\\PrintConfig.dll" + } + } + } + }, + { + "meta": { + "negate": true + }, + "query": { + "wildcard": { + "file.path": { + "case_insensitive": true, + "value": "?:\\\\Windows\\\\Sys?????\\\\x5lrs.dll" + } + } + } + }, + { + "meta": { + "negate": true + }, + "query": { + "wildcard": { + "file.path": { + "case_insensitive": true, + "value": "?:\\\\Windows\\\\system32\\\\spool\\\\DRIVERS\\\\x64\\\\*.dll" + } + } + } + }, + { + "meta": { + "negate": true + }, + "query": { + "wildcard": { + "file.path": { + "case_insensitive": true, + "value": "?:\\\\Windows\\\\system32\\\\spool\\\\DRIVERS\\\\W32X86\\\\*.dll" + } + } + } + }, + { + "meta": { + "negate": true + }, + "query": { + "wildcard": { + "file.path": { + "case_insensitive": true, + "value": "?:\\\\Windows\\\\system32\\\\spool\\\\PRTPROCS\\\\x64\\\\*.dll" + } + } + } + }, + { + "meta": { + "negate": true + }, + "query": { + "wildcard": { + "file.path": { + "case_insensitive": true, + "value": "?:\\\\Windows\\\\system32\\\\spool\\\\{????????-????-????-????-????????????}\\\\*.dll" + } + } + } + } + ], + "from": "now-9m", + "history_window_start": "now-5d", + "index": [ + "winlogbeat-*", + "logs-endpoint.events.file-*", + "logs-windows.sysmon_operational-*", + "endgame-*", + "logs-m365_defender.event-*", + "logs-sentinel_one_cloud_funnel.*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "Deprecated - Suspicious PrintSpooler Service Executable File Creation", + "new_terms_fields": [ + "host.id", + "file.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 Deprecated - Suspicious PrintSpooler Service Executable File Creation\n\nThe Print Spooler service in Windows manages print jobs, but vulnerabilities like CVE-2020-1048 can be exploited for privilege escalation. Adversaries may create malicious DLL files executed by the spooler to gain elevated privileges. The detection rule identifies such threats by monitoring file creation events linked to the spooler process, focusing on DLL files, which are common vectors for exploitation.\n\n### Possible investigation steps\n\n- Review the alert details to confirm the presence of a file creation event with the extension \"dll\" associated with the \"spoolsv.exe\" process on a Windows host.\n- Check the file path and name of the created DLL to determine if it matches known malicious patterns or locations typically used for exploitation.\n- Investigate the source of the spoolsv.exe process by examining the parent process and any associated user accounts to identify potential unauthorized access or activity.\n- Analyze recent system logs and security events for any other suspicious activities or anomalies around the time of the DLL creation, such as unexpected user logins or privilege changes.\n- Verify the patch status of the affected system against the vulnerabilities CVE-2020-1048, CVE-2020-1337, and CVE-2020-1300 to ensure it is up to date and not susceptible to known exploits.\n- If the DLL is confirmed to be malicious, isolate the affected system to prevent further exploitation and begin remediation efforts, including removing the malicious file and any associated threats.\n\n### False positive analysis\n\n- Legitimate DLL updates by trusted software can trigger the rule. Users should verify the source of the DLL and, if confirmed safe, add the software's update process to an exception list.\n- System maintenance activities, such as Windows updates, may create DLLs that match the rule's criteria. Users can exclude these activities by identifying the associated update processes and adding them to the exception list.\n- Custom in-house applications that interact with the Print Spooler service might generate DLLs during normal operation. Users should validate these applications and exclude their file creation events if they are deemed non-threatening.\n- Security software or monitoring tools that interact with the Print Spooler service could inadvertently create DLLs. Users should confirm the legitimacy of these tools and configure exceptions for their operations.\n\n### Response and remediation\n\n- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the adversary.\n- Terminate the spoolsv.exe process if it is confirmed to be executing a malicious DLL, to halt any ongoing malicious activity.\n- Remove the malicious DLL file from the system to prevent re-execution and further exploitation.\n- Apply the latest security patches and updates to the affected system, specifically addressing CVE-2020-1048, CVE-2020-1337, and CVE-2020-1300, to close the vulnerabilities exploited by the adversary.\n- Conduct a thorough review of user accounts and privileges on the affected system to ensure no unauthorized privilege escalation has occurred.\n- Monitor the network for any signs of similar exploitation attempts or related suspicious activity, using enhanced logging and alerting mechanisms.\n- Report the incident to the appropriate internal security team or external authorities if required, providing details of the exploit and actions taken for further investigation and response.", + "query": "event.category : \"file\" and host.os.type : \"windows\" and event.type : \"creation\" and\n process.name : \"spoolsv.exe\" and file.extension : \"dll\"\n", + "references": [ + "https://voidsec.com/cve-2020-1337-printdemon-is-dead-long-live-printdemon/", + "https://www.thezdi.com/blog/2020/7/8/cve-2020-1300-remote-code-execution-through-microsoft-windows-cab-files" + ], + "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.category", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.extension", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "5bb4a95d-5a08-48eb-80db-4c3a63ec78a8", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Privilege Escalation", + "Data Source: Elastic Endgame", + "Use Case: Vulnerability", + "Data Source: Elastic Defend", + "Data Source: Sysmon", + "Data Source: Microsoft Defender for Endpoint", + "Data Source: SentinelOne", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "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": "new_terms", + "version": 320 + }, + "id": "5bb4a95d-5a08-48eb-80db-4c3a63ec78a8_320", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/5e552599-ddec-4e14-bad1-28aa42404388_212.json b/packages/security_detection_engine/kibana/security_rule/5e552599-ddec-4e14-bad1-28aa42404388_212.json new file mode 100644 index 00000000000..69b41d831a0 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/5e552599-ddec-4e14-bad1-28aa42404388_212.json @@ -0,0 +1,95 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies when guest access is enabled in Microsoft Teams. Guest access in Teams allows people outside the organization to access teams and channels. An adversary may enable guest access to maintain persistence in an environment.", + "false_positives": [ + "Teams guest access may be enabled by a system or network administrator. Verify that the configuration change was expected. Exceptions can be added to this rule to filter expected behavior." + ], + "from": "now-9m", + "index": [ + "logs-o365.audit-*", + "filebeat-*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "Deprecated - M365 Teams Guest Access Enabled", + "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 - M365 Teams Guest Access Enabled\n\nMicrosoft Teams allows organizations to collaborate with external users through guest access, facilitating communication and teamwork. However, adversaries can exploit this feature to gain persistent access to sensitive environments by enabling guest access without authorization. The detection rule monitors audit logs for specific configurations that indicate guest access has been enabled, helping identify unauthorized changes and potential security breaches.\n\n### Possible investigation steps\n\n- Review the audit logs to confirm the event.action \"Set-CsTeamsClientConfiguration\" was successfully executed with the parameter o365.audit.Parameters.AllowGuestUser set to True.\n- Identify the user account responsible for enabling guest access by examining the event logs for the user ID or account name associated with the action.\n- Check the user's activity history to determine if there are any other suspicious actions or patterns, such as changes to other configurations or unusual login times.\n- Investigate the context of the change by reviewing any related communications or requests that might justify enabling guest access, ensuring it aligns with organizational policies.\n- Assess the potential impact by identifying which teams and channels now have guest access enabled and evaluate the sensitivity of the information accessible to external users.\n- Contact the user or their manager to verify if the change was authorized and necessary, and document their response for future reference.\n\n### False positive analysis\n\n- Legitimate collaboration with external partners may trigger alerts when guest access is enabled for business purposes. To manage this, create exceptions for known and approved external domains or specific projects that require guest access.\n- Routine administrative actions by IT staff to enable guest access for specific teams or channels can be mistaken for unauthorized changes. Implement a process to log and approve such changes internally, and exclude these from triggering alerts.\n- Automated scripts or third-party applications that configure Teams settings, including guest access, might cause false positives. Identify and whitelist these scripts or applications to prevent unnecessary alerts.\n- Changes made during scheduled maintenance windows can be misinterpreted as unauthorized. Define and exclude these time periods from monitoring to reduce false positives.\n\n### Response and remediation\n\n- Immediately disable guest access in Microsoft Teams by updating the Teams client configuration to prevent unauthorized external access.\n- Conduct a thorough review of recent audit logs to identify any unauthorized changes or suspicious activities related to guest access settings.\n- Notify the security team and relevant stakeholders about the potential breach to ensure awareness and initiate further investigation.\n- Revoke any unauthorized guest accounts that have been added to Teams to eliminate potential persistence mechanisms.\n- Implement additional monitoring on Teams configurations to detect any future unauthorized changes to guest access settings.\n- Escalate the incident to the organization's incident response team for a comprehensive investigation and to determine if further containment actions are necessary.\n- Review and update access control policies to ensure that enabling guest access requires appropriate authorization and oversight.", + "query": "event.dataset:o365.audit and event.provider:(SkypeForBusiness or MicrosoftTeams) and\nevent.category:web and event.action:\"Set-CsTeamsClientConfiguration\" and\no365.audit.Parameters.AllowGuestUser:True and event.outcome:success\n", + "references": [ + "https://docs.microsoft.com/en-us/powershell/module/skype/get-csteamsclientconfiguration?view=skype-ps" + ], + "related_integrations": [ + { + "package": "o365", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.category", + "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.Parameters.AllowGuestUser", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "5e552599-ddec-4e14-bad1-28aa42404388", + "setup": "The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Data Source: Microsoft 365", + "Use Case: Configuration 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/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 212 + }, + "id": "5e552599-ddec-4e14-bad1-28aa42404388_212", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/60f3adec-1df9-4104-9c75-b97d9f078b25_212.json b/packages/security_detection_engine/kibana/security_rule/60f3adec-1df9-4104-9c75-b97d9f078b25_212.json new file mode 100644 index 00000000000..34e321fe64e --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/60f3adec-1df9-4104-9c75-b97d9f078b25_212.json @@ -0,0 +1,91 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies when a Data Loss Prevention (DLP) policy is removed in Microsoft 365. An adversary may remove a DLP policy to evade existing DLP monitoring.", + "false_positives": [ + "A DLP policy may be removed by a system or network administrator. Verify that the configuration change was expected. Exceptions can be added to this rule to filter expected behavior." + ], + "from": "now-9m", + "index": [ + "logs-o365.audit-*", + "filebeat-*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "Deprecated - M365 Exchange DLP Policy Deleted", + "note": "## Triage and analysis\n\n### Investigating Deprecated - M365 Exchange DLP Policy Deleted\n\nData Loss Prevention (DLP) in Microsoft 365 Exchange is crucial for safeguarding sensitive information by monitoring and controlling data transfers. Adversaries may exploit this by removing DLP policies to bypass data monitoring, facilitating unauthorized data exfiltration. The detection rule identifies such actions by analyzing audit logs for specific events indicating successful DLP policy removal, thus alerting security teams to potential defense evasion tactics.\n\n### Possible investigation steps\n\n- Review the audit logs for the specific event.action \"Remove-DlpPolicy\" to identify the user account responsible for the action.\n- Check the event.outcome field to confirm the success of the DLP policy removal and gather additional context from related logs.\n- Investigate the user account's recent activities in Microsoft 365 to identify any other suspicious actions or anomalies.\n- Verify if the removed DLP policy was critical for protecting sensitive data and assess the potential impact of its removal.\n- Contact the user or their manager to confirm if the DLP policy removal was authorized and legitimate.\n- Examine any recent changes in permissions or roles for the user account to determine if they had the necessary privileges to remove the DLP policy.\n\n### False positive analysis\n\n- Routine administrative changes to DLP policies by authorized personnel can trigger alerts. To manage this, maintain a list of authorized users and correlate their activities with policy changes to verify legitimacy.\n- Scheduled updates or maintenance activities might involve temporary removal of DLP policies. Document these activities and create exceptions in the monitoring system for the duration of the maintenance window.\n- Automated scripts or third-party tools used for policy management can inadvertently trigger false positives. Ensure these tools are properly documented and their actions are logged to differentiate between legitimate and suspicious activities.\n- Changes in organizational policy or compliance requirements may necessitate the removal of certain DLP policies. Keep a record of such changes and adjust the monitoring rules to accommodate these legitimate actions.\n\n### Response and remediation\n\n- Immediately isolate the affected Microsoft 365 account to prevent further unauthorized actions and data exfiltration.\n- Review the audit logs to identify any additional unauthorized changes or suspicious activities associated with the account or related accounts.\n- Restore the removed DLP policy from a backup or recreate it based on the organization's standard configuration to re-enable data monitoring.\n- Conduct a thorough investigation to determine the scope of data exposure and identify any data that may have been exfiltrated during the period the DLP policy was inactive.\n- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional containment measures are necessary.\n- Implement enhanced monitoring and alerting for similar events, focusing on unauthorized changes to security policies and configurations.\n- Review and strengthen access controls and permissions for accounts with the ability to modify DLP policies to prevent unauthorized changes in the future.", + "query": "event.dataset:o365.audit and event.provider:Exchange and event.category:web and event.action:\"Remove-DlpPolicy\" and event.outcome:success\n", + "references": [ + "https://docs.microsoft.com/en-us/powershell/module/exchange/remove-dlppolicy?view=exchange-ps", + "https://docs.microsoft.com/en-us/microsoft-365/compliance/data-loss-prevention-policies?view=o365-worldwide" + ], + "related_integrations": [ + { + "package": "o365", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.category", + "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": "60f3adec-1df9-4104-9c75-b97d9f078b25", + "setup": "The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Data Source: Microsoft 365", + "Use Case: Configuration Audit", + "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/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 212 + }, + "id": "60f3adec-1df9-4104-9c75-b97d9f078b25_212", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/616b8d00-05f8-11f1-8f33-f661ea17fbce_1.json b/packages/security_detection_engine/kibana/security_rule/616b8d00-05f8-11f1-8f33-f661ea17fbce_1.json new file mode 100644 index 00000000000..bb831407658 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/616b8d00-05f8-11f1-8f33-f661ea17fbce_1.json @@ -0,0 +1,154 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies when a service principal authenticates using a federated identity credential for the first time in the historical window. This indicates that Entra ID validated a JWT token potentially against an external OIDC identity provider and issued an access token. While legitimate for CI/CD workflows (GitHub Actions, Azure DevOps), adversaries may abuse this by configuring rogue identity providers (BYOIDP) to authenticate as compromised applications. First-time federated credential usage for a service principal warrants investigation to determine if the external identity provider is legitimate.", + "false_positives": [ + "New CI/CD pipeline deployments using GitHub Actions, Azure DevOps, or Kubernetes OIDC will trigger this rule when federated authentication is first used. Validate the issuer URL against approved identity providers.", + "Application migrations or reconfigurations that switch from certificate/secret authentication to federated credentials will appear as new behavior. Confirm with application owners.", + "New workload identity federation configurations for legitimate automation will trigger on first use." + ], + "from": "now-9m", + "history_window_start": "now-5d", + "index": [ + "logs-azure.signinlogs-*" + ], + "investigation_fields": { + "field_names": [ + "azure.signinlogs.properties.service_principal_name", + "azure.signinlogs.properties.service_principal_id", + "azure.signinlogs.properties.app_id", + "azure.signinlogs.properties.app_display_name", + "azure.signinlogs.properties.app_owner_tenant_id", + "azure.signinlogs.properties.client_credential_type", + "azure.signinlogs.properties.service_principal_credential_thumbprint", + "azure.signinlogs.caller_ip_address", + "azure.signinlogs.properties.resource_display_name", + "azure.signinlogs.properties.unique_token_identifier", + "azure.correlation_id", + "azure.signinlogs.properties.session_id", + "source.geo.country_name", + "source.geo.city_name" + ] + }, + "language": "kuery", + "license": "Elastic License v2", + "name": "Entra ID Service Principal Federated Credential Authentication by Unusual Client", + "new_terms_fields": [ + "azure.signinlogs.properties.app_id" + ], + "note": "## Triage and analysis\n\n### Investigating Entra ID Service Principal Federated Credential Authentication by Unusual Client\n\nIf this rule triggers, it indicates that a service principal has authenticated using a federated identity credential for the first time within the historical window. This means that Entra ID validated a JWT token potentially issued by an external OIDC identity provider and issued an access token for the service principal. While this can be legitimate for CI/CD workflows (e.g., GitHub Actions, Azure DevOps, Kubernetes OIDC), it can also indicate abuse by adversaries who have configured rogue identity providers (BYOIDP) to authenticate as compromised applications. For BYOIDP attacks, this is the moment the adversary's rogue identity provider is used to authenticate as the\ncompromised application for the first time.\n\n### Possible investigation steps\n\n- Identify the service principal using `azure.signinlogs.properties.app_id` and `app_display_name`.\n- Critical: Check the application's federated credential configuration in Entra ID:\n - What is the issuer URL? Is it a known legitimate provider (GitHub Actions, Azure DevOps, Kubernetes)?\n - When was the federated credential added? Was it recent?\n - Who added the federated credential?\n- Review the `service_principal_credential_thumbprint` - does it match expected certificates?\n- Investigate the source IP (`azure.signinlogs.caller_ip_address`) - is it from expected CI/CD infrastructure?\n- Check what resources were accessed after authentication using `azure.signinlogs.properties.resource_display_name`.\n- Correlate with Graph Activity logs to see what API calls were made with this token.\n- Use the `correlation_id` to find related sign-in and activity events.\n- Review audit logs for recent changes to this application's federated credentials.\n\n### False positive analysis\n\n- Legitimate CI/CD pipelines using GitHub Actions, Azure DevOps, or Kubernetes OIDC will trigger this rule on first use.\n- New application deployments with workload identity federation are expected to show as new behavior.\n- Validate the issuer URL against approved identity providers before dismissing.\n- Create baseline of applications expected to use federated credentials.\n\n### Response and remediation\n\n- If this is unexpected federated auth for the application, immediately investigate the federated credential configuration.\n- Review the external IdP issuer URL configured on the application - is it legitimate?\n- If BYOIDP is confirmed:\n - Remove the malicious federated credential immediately.\n - Revoke active sessions and tokens for the affected service principal.\n - Audit what actions were performed using the compromised identity.\n - Investigate how the federated credential was added (compromised admin account).", + "query": "event.dataset: \"azure.signinlogs\"\n and azure.signinlogs.category: \"ServicePrincipalSignInLogs\"\n and azure.signinlogs.properties.client_credential_type: \"federatedIdentityCredential\"\n and azure.signinlogs.result_signature: \"SUCCESS\"\n and azure.signinlogs.properties.app_id: *\n and not azure.signinlogs.properties.app_owner_tenant_id: (\n \"f8cdef31-a31e-4b4a-93e4-5f571e91255a\" or\n \"72f988bf-86f1-41af-91ab-2d7cd011db47\"\n )\n", + "references": [ + "https://dirkjanm.io/persisting-with-federated-credentials-entra-apps-managed-identities/", + "https://learn.microsoft.com/en-us/entra/workload-id/workload-identity-federation", + "https://github.com/dirkjanm/ROADtools" + ], + "related_integrations": [ + { + "package": "azure", + "version": "^1.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "azure.signinlogs.category", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.signinlogs.properties.app_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.signinlogs.properties.app_owner_tenant_id", + "type": "unknown" + }, + { + "ecs": false, + "name": "azure.signinlogs.properties.client_credential_type", + "type": "unknown" + }, + { + "ecs": false, + "name": "azure.signinlogs.result_signature", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "616b8d00-05f8-11f1-8f33-f661ea17fbce", + "setup": "#### Required Microsoft Entra ID Sign-In Logs\nTo use this rule, ensure that Microsoft Entra ID Sign-In Logs are being collected and streamed into the Elastic Stack via the Azure integration.\n", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Domain: Identity", + "Data Source: Azure", + "Data Source: Microsoft Entra ID", + "Data Source: Microsoft Entra ID Sign-In Logs", + "Use Case: Identity and Access Audit", + "Tactic: Initial Access", + "Tactic: Defense Evasion", + "Tactic: Persistence", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0001", + "name": "Initial Access", + "reference": "https://attack.mitre.org/tactics/TA0001/" + }, + "technique": [ + { + "id": "T1078", + "name": "Valid Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/", + "subtechnique": [ + { + "id": "T1078.004", + "name": "Cloud Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/004/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "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": "new_terms", + "version": 1 + }, + "id": "616b8d00-05f8-11f1-8f33-f661ea17fbce_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/61ac3638-40a3-44b2-855a-985636ca985e_319.json b/packages/security_detection_engine/kibana/security_rule/61ac3638-40a3-44b2-855a-985636ca985e_319.json new file mode 100644 index 00000000000..52d70a34675 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/61ac3638-40a3-44b2-855a-985636ca985e_319.json @@ -0,0 +1,194 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects PowerShell scripts that references native Windows API functions commonly used for discovery of users, groups, shares, sessions, domain trusts, and service security. Attackers use these APIs for situational awareness and targeting prior to lateral movement or collection.", + "false_positives": [ + "Legitimate PowerShell scripts that make use of these functions." + ], + "filters": [ + { + "meta": { + "negate": true + }, + "query": { + "wildcard": { + "file.path": { + "case_insensitive": true, + "value": "?:\\\\ProgramData\\\\Microsoft\\\\Windows Defender Advanced Threat Protection\\\\DataCollection\\\\*" + } + } + } + } + ], + "from": "now-9m", + "index": [ + "winlogbeat-*", + "logs-windows.powershell*" + ], + "investigation_fields": { + "field_names": [ + "@timestamp", + "user.name", + "user.id", + "user.domain", + "powershell.file.script_block_text", + "powershell.file.script_block_id", + "powershell.sequence", + "powershell.total", + "file.path", + "file.directory", + "file.name", + "process.pid", + "host.name", + "host.id", + "powershell.file.script_block_length" + ] + }, + "language": "kuery", + "license": "Elastic License v2", + "name": "PowerShell Suspicious Discovery Related Windows API Functions", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This guide was created by humans with the assistance of generative AI. While its contents have been manually curated to include the most valuable information, always validate assumptions and adjust procedures to match your internal runbooks and incident triage and response policies.\n\n### Investigating PowerShell Suspicious Discovery Related Windows API Functions\n\nThis rule flags PowerShell script block content that references Windows API functions commonly used to enumerate users, groups, shares, sessions, domain trusts, and service security. These APIs are frequently accessed via native interop patterns (for example, runtime-compiled type definitions) and can be used to build an inventory of the environment before follow-on activity such as lateral movement or collection.\n\n#### Key alert fields to review\n\n- `user.name`, `user.domain`, `user.id`: Account execution context for correlation, prioritization, and scoping.\n- `host.name`, `host.id`: Host execution context for correlation, prioritization, and scoping.\n- `powershell.file.script_block_text`: Script block content that matched the detection logic.\n- `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`: Script block metadata to pivot to other fragments or reconstruct full script content when split across multiple events.\n- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file.\n- `powershell.file.script_block_length`: Script block length (size) context.\n\n#### Possible investigation steps\n\n- Establish context and expected behavior:\n - Review `host.name`/`host.id` to understand where the activity occurred and whether the host is expected to perform administrative discovery.\n - Review `user.name`, `user.domain`, and `user.id` to determine whether the executing identity aligns with expected administrative or automation activity for that host.\n - Use `powershell.file.script_block_length` (when present) as a quick indicator of complexity; unusually large blocks may indicate embedded helper libraries or inline compiled source.\n\n- Review, reconstruct, and characterize the script content:\n - Inspect `powershell.file.script_block_text` and identify which API function name(s) are present and what discovery objective they imply.\n - If the script is fragmented, reconstruct it by grouping events on `powershell.file.script_block_id` and ordering by `powershell.sequence` until `powershell.total` is reached. Capture the complete reconstructed content for case notes.\n - Look for indicators of native API invocation rather than standard cmdlets, such as embedded type definitions, interop attributes, or inline compiled source. This can increase confidence that the script was designed to directly call Windows APIs.\n - Identify additional capabilities in the same script block (or neighboring fragments) that may indicate follow-on behavior, such as credential access, remote execution logic, output staging, or data access from remote resources.\n\n- Map API functions to likely discovery intent:\n - Share and server discovery: `NetShareEnum`, `NetServerGetInfo`, `GetComputerNameEx`.\n - User and group discovery: `NetUserEnum`, `NetUserGetInfo`, `NetGroupEnum`, `NetGroupGetInfo`, `NetGroupGetUsers`, `NetLocalGroupEnum`, `NetLocalGroupGetMembers`, `GetUserNameEx`, `NetUserModalsGet`.\n - Session and workstation discovery: `NetSessionEnum`, `NetWkstaUserEnum`, `NetWkstaGetInfo`, `NetWkstaTransportEnum`, `WTSEnumerateSessionsEx`, `WTSQuerySessionInformation`, `LsaGetLogonSessionData`.\n - Domain trust and site discovery: `DsEnumerateDomainTrusts`, `LsaEnumerateTrustedDomains`, `DsGetSiteName`.\n - Service permission discovery: `QueryServiceObjectSecurity`.\n - Job discovery: `NetScheduleJobEnum`.\n\n- Determine discovery scope and targets from the content:\n - Extract any referenced hostnames, domain names, share names, or service names directly from `powershell.file.script_block_text` (when present) and record them as potential discovery targets.\n - Look for indications of remote enumeration (for example, multiple target strings, iteration constructs, or repeated API calls with varying targets) versus single-host local discovery.\n - Prioritize cases that include higher-impact reconnaissance (trust enumeration, session enumeration, logon session data, or service security descriptor queries), especially when the account or host context is unusual.\n\n- Validate script origin and execution source:\n - If file context is present, review `file.path`, `file.directory`, and `file.name` to understand whether the script block originated from an on-disk script and whether that location aligns with approved tooling.\n - Treat scripts originating from unexpected or user-writable locations, or scripts with unusual naming, as higher risk and scope for other related activity on the same host and by the same user.\n\n- Scope for related activity using alert-available pivots:\n - Search for other script blocks with the same `powershell.file.script_block_id` to ensure no fragments are missed and to identify repeated execution.\n - Search for additional hits of the same `file.path`/`file.name` across hosts to determine whether the script is broadly deployed or opportunistically introduced.\n - Identify other occurrences of similar discovery content by pivoting on distinctive substrings within `powershell.file.script_block_text` (such as specific API function names) and the same `user.id` to detect a broader reconnaissance pattern.\n\n- Correlate with adjacent telemetry (as available in your environment):\n - Process context: determine how PowerShell was started and whether the initiation method is consistent with expected activity for `user.name` on `host.name`.\n - Authentication and remote access: look for logons or remote session activity involving the same `user.name` around the alert time, especially if the script content suggests remote enumeration of servers or sessions.\n - Network and share access: review evidence of access to discovered targets (servers/shares) following the enumeration to identify potential collection from network shares.\n - Persistence or privilege escalation follow-on: if service security or job enumeration is present, look for subsequent changes consistent with service or scheduled job manipulation.\n\n### False positive analysis\n\n- Benign administrative discovery can occur during routine inventory, troubleshooting, or access validation, especially from dedicated administration hosts and by well-known administrative identities.\n- False positives are more likely when the same script content appears regularly, is consistently associated with the same `file.path`/`file.name`, and is executed by expected `user.name` accounts on expected hosts.\n- Prioritize as suspicious when the activity is new for the environment, originates from an unexpected script location, is executed by a non-administrative or unusual account, or appears across multiple hosts in a short period.\n\n### Response and remediation\n\n- If the activity is confirmed or strongly suspected malicious:\n - Contain the affected host and restrict the involved account to prevent further reconnaissance and follow-on actions.\n - Preserve evidence from the alert, including the fully reconstructed `powershell.file.script_block_text`, `powershell.file.script_block_id`, and any extracted target identifiers, along with `host.id` and `user.id` for reliable correlation.\n - Scope across the environment for additional executions using pivots on `user.id`, `host.id`, `file.path`/`file.name`, and distinctive content within `powershell.file.script_block_text`.\n - Review the enumerated targets (hosts, shares, users/groups, trusts, services, sessions) for unauthorized access attempts and follow-on activity such as network share access, credential misuse, or lateral movement.\n\n- If the activity is determined to be legitimate but unexpected:\n - Identify the script owner and document the business purpose, expected execution scope (hosts/users), and expected cadence.\n - Reduce future noise by baselining approved scripts and execution contexts, and ensure logging and monitoring coverage remains sufficient to investigate future occurrences.\n", + "query": "event.category:process and host.os.type:windows and\n powershell.file.script_block_text : (\n NetShareEnum or\n NetWkstaUserEnum or\n NetSessionEnum or\n NetLocalGroupEnum or\n NetLocalGroupGetMembers or\n DsGetSiteName or\n DsEnumerateDomainTrusts or\n WTSEnumerateSessionsEx or\n WTSQuerySessionInformation or\n LsaGetLogonSessionData or\n QueryServiceObjectSecurity or\n GetComputerNameEx or\n NetWkstaGetInfo or\n GetUserNameEx or\n NetUserEnum or\n NetUserGetInfo or\n NetGroupEnum or\n NetGroupGetInfo or\n NetGroupGetUsers or\n NetWkstaTransportEnum or\n NetServerGetInfo or\n LsaEnumerateTrustedDomains or\n NetScheduleJobEnum or\n NetUserModalsGet\n ) and\n not powershell.file.script_block_text : (\n (\"DsGetSiteName\" and (\"DiscoverWindowsComputerProperties.ps1\" and \"param($SourceType, $SourceId, $ManagedEntityId, $ComputerIdentity)\")) or\n (\"# Copyright: (c) 2018, Ansible Project\" and \"#Requires -Module Ansible.ModuleUtils.AddType\" and \"#AnsibleRequires -CSharpUtil Ansible.Basic\") or\n (\"Ansible.Windows.Setup\" and \"Ansible.Windows.Setup\" and \"NativeMethods.NetWkstaGetInfo(null, 100, out netBuffer);\")\n ) and\n not file.directory: \"C:\\Program Files (x86)\\Automox\\WDK\\Win32\\WinSession\"\n", + "references": [ + "https://github.com/BC-SECURITY/Empire/blob/9259e5106986847d2bb770c4289c0c0f1adf2344/data/module_source/situational_awareness/network/powerview.ps1#L21413", + "https://github.com/atc-project/atc-data/blob/master/docs/Logging_Policies/LP_0109_windows_powershell_script_block_log.md" + ], + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.category", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.directory", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_text", + "type": "unknown" + } + ], + "risk_score": 21, + "rule_id": "61ac3638-40a3-44b2-855a-985636ca985e", + "setup": "## Setup\n\nPowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104).\nSetup instructions: https://ela.st/powershell-logging-setup\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Discovery", + "Tactic: Collection", + "Tactic: Execution", + "Resources: Investigation Guide", + "Data Source: PowerShell Logs" + ], + "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/", + "subtechnique": [ + { + "id": "T1069.001", + "name": "Local Groups", + "reference": "https://attack.mitre.org/techniques/T1069/001/" + } + ] + }, + { + "id": "T1087", + "name": "Account Discovery", + "reference": "https://attack.mitre.org/techniques/T1087/", + "subtechnique": [ + { + "id": "T1087.001", + "name": "Local Account", + "reference": "https://attack.mitre.org/techniques/T1087/001/" + } + ] + }, + { + "id": "T1135", + "name": "Network Share Discovery", + "reference": "https://attack.mitre.org/techniques/T1135/" + }, + { + "id": "T1482", + "name": "Domain Trust Discovery", + "reference": "https://attack.mitre.org/techniques/T1482/" + } + ] + }, + { + "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": "T1106", + "name": "Native API", + "reference": "https://attack.mitre.org/techniques/T1106/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0009", + "name": "Collection", + "reference": "https://attack.mitre.org/tactics/TA0009/" + }, + "technique": [ + { + "id": "T1039", + "name": "Data from Network Shared Drive", + "reference": "https://attack.mitre.org/techniques/T1039/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 319 + }, + "id": "61ac3638-40a3-44b2-855a-985636ca985e_319", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/63c05204-339a-11ed-a261-0242ac120002_8.json b/packages/security_detection_engine/kibana/security_rule/63c05204-339a-11ed-a261-0242ac120002_8.json deleted file mode 100644 index 4ff5d68dc6d..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/63c05204-339a-11ed-a261-0242ac120002_8.json +++ /dev/null @@ -1,99 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "This rule detects a request to attach a controller service account to an existing or new pod running in the kube-system namespace. By default, controllers running as part of the API Server utilize admin-equivalent service accounts hosted in the kube-system namespace. Controller service accounts aren't normally assigned to running pods and could indicate adversary behavior within the cluster. An attacker that can create or modify pods or pod controllers in the kube-system namespace, can assign one of these admin-equivalent service accounts to a pod and abuse their powerful token to escalate privileges and gain complete cluster control.", - "false_positives": [ - "Controller service accounts aren't normally assigned to running pods, this is abnormal behavior with very few legitimate use-cases and should result in very few false positives." - ], - "index": [ - "logs-kubernetes.*" - ], - "language": "kuery", - "license": "Elastic License v2", - "name": "Kubernetes Suspicious Assignment of Controller Service Account", - "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Kubernetes Suspicious Assignment of Controller Service Account\n\nKubernetes uses service accounts to manage pod permissions, with controller service accounts in the kube-system namespace having elevated privileges. Adversaries may exploit this by assigning these accounts to pods, gaining admin-level access. The detection rule identifies such suspicious assignments by monitoring audit logs for pod creation events in the kube-system namespace with controller service accounts, flagging potential privilege escalation attempts.\n\n### Possible investigation steps\n\n- Review the audit logs to confirm the presence of a \"create\" event for a pod in the \"kube-system\" namespace with a service account name containing \"controller\".\n- Identify the source of the request by examining the user or service account that initiated the pod creation event in the audit logs.\n- Check the history of the involved service account to determine if it has been used in any other suspicious activities or unauthorized access attempts.\n- Investigate the pod's configuration and associated resources to understand its purpose and whether it aligns with expected operations within the cluster.\n- Assess the potential impact by evaluating the permissions and roles associated with the controller service account assigned to the pod.\n- Review recent changes or deployments in the \"kube-system\" namespace to identify any unauthorized modifications or anomalies.\n\n### False positive analysis\n\n- Routine maintenance tasks in the kube-system namespace may involve creating or modifying pods with elevated service accounts. Review the context of such actions to determine if they are part of scheduled maintenance or updates.\n- Automated deployment tools might temporarily assign controller service accounts to pods for configuration purposes. Verify if these actions align with known deployment processes and consider excluding these specific tools from triggering alerts.\n- Legitimate testing or debugging activities by cluster administrators could involve using controller service accounts. Ensure these activities are documented and consider creating exceptions for known testing environments.\n- Some monitoring or logging solutions might require elevated permissions and could inadvertently trigger this rule. Validate the necessity of these permissions and whitelist these solutions if they are deemed non-threatening.\n- Regularly review and update the list of known benign service account assignments to ensure that only unexpected or unauthorized assignments are flagged.\n\n### Response and remediation\n\n- Immediately isolate the affected pod by cordoning the node it is running on to prevent further scheduling of pods and drain the node if necessary to stop the pod from executing.\n- Revoke the service account token associated with the suspicious pod to prevent further unauthorized access or actions using the compromised credentials.\n- Conduct a thorough review of recent changes in the kube-system namespace to identify unauthorized modifications or deployments, focusing on the creation and modification of pods and service accounts.\n- Reset credentials and rotate keys for any service accounts that may have been compromised to ensure that any stolen credentials are rendered useless.\n- Implement network policies to restrict pod-to-pod communication within the kube-system namespace, limiting the potential lateral movement of an attacker.\n- Escalate the incident to the security operations team for further investigation and to determine if additional clusters or systems have been affected.\n- Enhance monitoring and alerting for similar activities by ensuring audit logs are comprehensive and that alerts are configured to detect unauthorized service account assignments promptly.", - "query": "event.dataset : \"kubernetes.audit_logs\"\n and kubernetes.audit.annotations.authorization_k8s_io/decision:\"allow\"\n and kubernetes.audit.verb : \"create\"\n and kubernetes.audit.objectRef.resource : \"pods\"\n and kubernetes.audit.objectRef.namespace : \"kube-system\"\n and kubernetes.audit.requestObject.spec.serviceAccountName:*controller\n", - "references": [ - "https://www.paloaltonetworks.com/apps/pan/public/downloadResource?pagePath=/content/pan/en_US/resources/whitepapers/kubernetes-privilege-escalation-excessive-permissions-in-popular-platforms" - ], - "related_integrations": [ - { - "package": "kubernetes", - "version": "^1.80.0" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "event.dataset", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.annotations.authorization_k8s_io/decision", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.objectRef.namespace", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.objectRef.resource", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.requestObject.spec.serviceAccountName", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.verb", - "type": "keyword" - } - ], - "risk_score": 47, - "rule_id": "63c05204-339a-11ed-a261-0242ac120002", - "setup": "The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule.", - "severity": "medium", - "tags": [ - "Data Source: Kubernetes", - "Tactic: Execution", - "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": "T1078", - "name": "Valid Accounts", - "reference": "https://attack.mitre.org/techniques/T1078/", - "subtechnique": [ - { - "id": "T1078.001", - "name": "Default Accounts", - "reference": "https://attack.mitre.org/techniques/T1078/001/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "query", - "version": 8 - }, - "id": "63c05204-339a-11ed-a261-0242ac120002_8", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/63c056a0-339a-11ed-a261-0242ac120002_7.json b/packages/security_detection_engine/kibana/security_rule/63c056a0-339a-11ed-a261-0242ac120002_7.json deleted file mode 100644 index 7d19a3bc50d..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/63c056a0-339a-11ed-a261-0242ac120002_7.json +++ /dev/null @@ -1,77 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "This rule detects when a service account makes an unauthorized request for resources from the API server. Service accounts follow a very predictable pattern of behavior. A service account should never send an unauthorized request to the API server. This behavior is likely an indicator of compromise or of a problem within the cluster. An adversary may have gained access to credentials/tokens and this could be an attempt to access or create resources to facilitate further movement or execution within the cluster.", - "false_positives": [ - "Unauthorized requests from service accounts are highly abnormal and more indicative of human behavior or a serious problem within the cluster. This behavior should be investigated further." - ], - "index": [ - "logs-kubernetes.*" - ], - "language": "kuery", - "license": "Elastic License v2", - "name": "Kubernetes Denied Service Account 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 Kubernetes Denied Service Account Request\n\nKubernetes service accounts are integral for managing pod permissions and accessing the API server. They typically follow strict access patterns. Adversaries may exploit compromised service account credentials to probe or manipulate cluster resources, potentially leading to unauthorized access or lateral movement. The detection rule identifies anomalies by flagging unauthorized API requests from service accounts, signaling possible security breaches or misconfigurations.\n\n### Possible investigation steps\n\n- Review the specific service account involved in the unauthorized request by examining the kubernetes.audit.user.username field to determine which service account was used.\n- Analyze the kubernetes.audit.annotations.authorization_k8s_io/decision field to confirm the request was indeed forbidden and identify the nature of the denied request.\n- Investigate the source of the request by checking the originating pod or node to understand where the unauthorized request was initiated.\n- Examine recent activity logs for the service account to identify any unusual patterns or deviations from its typical behavior.\n- Check for any recent changes or deployments in the cluster that might have affected service account permissions or configurations.\n- Assess whether there have been any recent security incidents or alerts related to the cluster that could be connected to this unauthorized request.\n\n### False positive analysis\n\n- Service accounts used for testing or development may generate unauthorized requests if they are not properly configured. Regularly review and update permissions for these accounts to ensure they align with their intended use.\n- Automated scripts or tools that interact with the Kubernetes API might trigger false positives if they use service accounts with insufficient permissions. Ensure these tools have the necessary permissions or adjust the detection rule to exclude known benign activities.\n- Misconfigured role-based access control (RBAC) settings can lead to legitimate service accounts being denied access. Conduct periodic audits of RBAC policies to verify that service accounts have appropriate permissions.\n- Temporary service accounts created for specific tasks might not have the correct permissions, leading to denied requests. Consider excluding these accounts from the rule if they are known to perform non-threatening activities.\n- Service accounts from third-party integrations or plugins may not have the required permissions, resulting in false positives. Validate the permissions needed for these integrations and adjust the rule to exclude their expected behavior.\n\n### Response and remediation\n\n- Immediately isolate the affected service account by revoking its access tokens and credentials to prevent further unauthorized API requests.\n- Conduct a thorough review of the audit logs to identify any other suspicious activities or unauthorized access attempts associated with the compromised service account.\n- Rotate credentials for the affected service account and any other potentially impacted accounts to mitigate the risk of further exploitation.\n- Assess and remediate any misconfigurations in role-based access control (RBAC) policies that may have allowed the unauthorized request, ensuring that service accounts have the minimum necessary permissions.\n- Escalate the incident to the security operations team for further investigation and to determine if additional containment measures are required.\n- Implement enhanced monitoring and alerting for similar unauthorized access attempts to improve detection and response times for future incidents.\n- Review and update incident response plans to incorporate lessons learned from this event, ensuring readiness for similar threats in the future.", - "query": "event.dataset: \"kubernetes.audit_logs\"\n and kubernetes.audit.user.username: system\\:serviceaccount\\:*\n and kubernetes.audit.annotations.authorization_k8s_io/decision: \"forbid\"\n", - "references": [ - "https://research.nccgroup.com/2021/11/10/detection-engineering-for-kubernetes-clusters/#part3-kubernetes-detections", - "https://kubernetes.io/docs/reference/access-authn-authz/authentication/#service-account-tokens" - ], - "related_integrations": [ - { - "package": "kubernetes", - "version": "^1.80.0" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "event.dataset", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.annotations.authorization_k8s_io/decision", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.user.username", - "type": "keyword" - } - ], - "risk_score": 47, - "rule_id": "63c056a0-339a-11ed-a261-0242ac120002", - "setup": "The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule.", - "severity": "medium", - "tags": [ - "Data Source: Kubernetes", - "Tactic: Discovery", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0007", - "name": "Discovery", - "reference": "https://attack.mitre.org/tactics/TA0007/" - }, - "technique": [ - { - "id": "T1613", - "name": "Container and Resource Discovery", - "reference": "https://attack.mitre.org/techniques/T1613/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "query", - "version": 7 - }, - "id": "63c056a0-339a-11ed-a261-0242ac120002_7", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/63c057cc-339a-11ed-a261-0242ac120002_8.json b/packages/security_detection_engine/kibana/security_rule/63c057cc-339a-11ed-a261-0242ac120002_8.json deleted file mode 100644 index d4d88ce3d62..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/63c057cc-339a-11ed-a261-0242ac120002_8.json +++ /dev/null @@ -1,90 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "This rule detects when an unauthenticated user request is authorized within the cluster. Attackers may attempt to use anonymous accounts to gain initial access to the cluster or to avoid attribution of their activities within the cluster. This rule excludes the /healthz, /livez and /readyz endpoints which are commonly accessed anonymously.", - "false_positives": [ - "Anonymous access to the API server is a dangerous setting enabled by default. Common anonymous connections (e.g., health checks) have been excluded from this rule. All other instances of authorized anonymous requests should be investigated." - ], - "index": [ - "logs-kubernetes.*" - ], - "language": "kuery", - "license": "Elastic License v2", - "name": "Kubernetes Anonymous Request Authorized", - "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 Kubernetes Anonymous Request Authorized\n\nKubernetes, a container orchestration platform, manages workloads and services. It uses authentication to control access. Adversaries might exploit anonymous access to perform unauthorized actions without leaving traces. The detection rule identifies unauthorized access by monitoring audit logs for anonymous requests that are allowed, excluding common health check endpoints, to flag potential misuse.\n\n### Possible investigation steps\n\n- Review the audit logs for the specific event.dataset:kubernetes.audit_logs to identify the context and details of the anonymous request.\n- Examine the kubernetes.audit.user.username field to confirm if the request was made by \"system:anonymous\" or \"system:unauthenticated\" and assess the potential risk associated with these accounts.\n- Analyze the kubernetes.audit.requestURI to determine the target of the request and verify if it is outside the excluded endpoints (/healthz, /livez, /readyz), which could indicate suspicious activity.\n- Investigate the source IP address and other network metadata associated with the request to identify the origin and assess if it aligns with known or expected traffic patterns.\n- Check for any subsequent or related activities in the audit logs that might indicate further unauthorized actions or attempts to exploit the cluster.\n\n### False positive analysis\n\n- Health check endpoints like /healthz, /livez, and /readyz are already excluded, but ensure any custom health check endpoints are also excluded to prevent false positives.\n- Regularly scheduled maintenance tasks or automated scripts that use anonymous access for legitimate purposes should be identified and excluded from the rule to avoid unnecessary alerts.\n- Some monitoring tools might use anonymous requests for gathering metrics; verify these tools and exclude their specific request patterns if they are known to be safe.\n- Development environments might have different access patterns compared to production; consider creating separate rules or exceptions for non-production clusters to reduce noise.\n- Review the audit logs to identify any recurring anonymous requests that are part of normal operations and adjust the rule to exclude these specific cases.\n\n### Response and remediation\n\n- Immediately isolate the affected Kubernetes cluster to prevent further unauthorized access and potential lateral movement by the adversary.\n- Revoke any anonymous access permissions that are not explicitly required for the operation of the cluster, ensuring that all access is authenticated and authorized.\n- Conduct a thorough review of the audit logs to identify any unauthorized actions performed by anonymous users and assess the impact on the cluster.\n- Reset credentials and access tokens for any accounts that may have been compromised or used in conjunction with the anonymous access.\n- Implement network segmentation to limit the exposure of the Kubernetes API server to only trusted networks and users.\n- Escalate the incident to the security operations team for further investigation and to determine if additional clusters or systems are affected.\n- Enhance monitoring and alerting for unauthorized access attempts, focusing on detecting and responding to similar threats in the future.", - "query": "event.dataset:kubernetes.audit_logs\n and kubernetes.audit.annotations.authorization_k8s_io/decision:allow\n and kubernetes.audit.user.username:(\"system:anonymous\" or \"system:unauthenticated\" or not *)\n and not kubernetes.audit.requestURI:(/healthz* or /livez* or /readyz*)\n", - "references": [ - "https://media.defense.gov/2022/Aug/29/2003066362/-1/-1/0/CTR_KUBERNETES_HARDENING_GUIDANCE_1.2_20220829.PDF" - ], - "related_integrations": [ - { - "package": "kubernetes", - "version": "^1.80.0" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "event.dataset", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.annotations.authorization_k8s_io/decision", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.requestURI", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.user.username", - "type": "keyword" - } - ], - "risk_score": 47, - "rule_id": "63c057cc-339a-11ed-a261-0242ac120002", - "setup": "The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule.", - "severity": "medium", - "tags": [ - "Data Source: Kubernetes", - "Tactic: Execution", - "Tactic: Initial Access", - "Tactic: Defense Evasion", - "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.001", - "name": "Default Accounts", - "reference": "https://attack.mitre.org/techniques/T1078/001/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "query", - "version": 8 - }, - "id": "63c057cc-339a-11ed-a261-0242ac120002_8", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/6482255d-f468-45ea-a5b3-d3a7de1331ae_107.json b/packages/security_detection_engine/kibana/security_rule/6482255d-f468-45ea-a5b3-d3a7de1331ae_107.json deleted file mode 100644 index 5a0ac82453b..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/6482255d-f468-45ea-a5b3-d3a7de1331ae_107.json +++ /dev/null @@ -1,94 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies changes to the Safari configuration using the built-in defaults command. Adversaries may attempt to enable or disable certain Safari settings, such as enabling JavaScript from Apple Events to ease in the hijacking of the users browser.", - "from": "now-9m", - "index": [ - "logs-endpoint.events.*" - ], - "language": "kuery", - "license": "Elastic License v2", - "name": "Modification of Safari Settings via Defaults Command", - "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 Safari Settings via Defaults Command\n\nThe 'defaults' command in macOS is a utility that allows users to read, write, and manage macOS application preferences, including Safari settings. Adversaries may exploit this command to alter Safari configurations, potentially enabling harmful features like JavaScript from Apple Events, which can facilitate browser hijacking. The detection rule monitors for suspicious 'defaults' command usage targeting Safari settings, excluding benign preference changes, to identify potential defense evasion attempts.\n\n### Possible investigation steps\n\n- Review the process execution details to confirm the use of the 'defaults' command with arguments targeting Safari settings, specifically looking for any suspicious or unauthorized changes.\n- Check the user account associated with the process execution to determine if the action was performed by a legitimate user or an unauthorized entity.\n- Investigate the system's recent activity logs to identify any other unusual or suspicious behavior around the time the 'defaults' command was executed.\n- Examine the Safari settings before and after the change to assess the impact and identify any potentially harmful configurations, such as enabling JavaScript from Apple Events.\n- Correlate the event with other security alerts or incidents to determine if this action is part of a broader attack or compromise attempt.\n\n### False positive analysis\n\n- Changes to Safari settings for legitimate user preferences can trigger alerts, such as enabling or disabling search suggestions. Users can create exceptions for these specific settings by excluding them from the detection rule.\n- System administrators may use the defaults command to configure Safari settings across multiple devices for compliance or user experience improvements. These actions can be whitelisted by identifying the specific process arguments used in these administrative tasks.\n- Automated scripts or management tools that adjust Safari settings as part of routine maintenance or updates may cause false positives. Users should identify these scripts and exclude their specific process arguments from the detection rule.\n- Developers testing Safari configurations might frequently change settings using the defaults command. Excluding known developer machines or user accounts from the rule can help reduce false positives.\n- Educational or training environments where users are instructed to modify Safari settings for learning purposes can lead to alerts. Identifying and excluding these environments or sessions can mitigate unnecessary alerts.\n\n### Response and remediation\n\n- Immediately isolate the affected macOS device from the network to prevent further malicious activity or data exfiltration.\n- Terminate any suspicious processes related to the 'defaults' command that are currently running on the affected device.\n- Revert any unauthorized changes made to Safari settings by restoring them to their default or previously known safe state.\n- Conduct a thorough scan of the affected device using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malware or malicious scripts.\n- Review and update the device's security settings to prevent unauthorized changes, including disabling unnecessary Apple Events and restricting the use of the 'defaults' command to authorized personnel only.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if other devices in the network are affected.\n- Implement enhanced monitoring and alerting for similar 'defaults' command usage across the network to detect and respond to future attempts promptly.", - "query": "event.category:process and host.os.type:macos and event.type:start and\n process.name:defaults and process.args:\n (com.apple.Safari and write and not\n (\n UniversalSearchEnabled or\n SuppressSearchSuggestions or\n WebKitTabToLinksPreferenceKey or\n ShowFullURLInSmartSearchField or\n com.apple.Safari.ContentPageGroupIdentifier.WebKit2TabsToLinks\n )\n )\n", - "references": [ - "https://objectivebythesea.com/v2/talks/OBTS_v2_Zohar.pdf" - ], - "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": 47, - "rule_id": "6482255d-f468-45ea-a5b3-d3a7de1331ae", - "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 macOS 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, for MacOS it is recommended to select \"Traditional Endpoints\".\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/current/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: 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": "query", - "version": 107 - }, - "id": "6482255d-f468-45ea-a5b3-d3a7de1331ae_107", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/64f17c52-6c6e-479e-ba72-236f3df18f3d_10.json b/packages/security_detection_engine/kibana/security_rule/64f17c52-6c6e-479e-ba72-236f3df18f3d_10.json new file mode 100644 index 00000000000..eb592745639 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/64f17c52-6c6e-479e-ba72-236f3df18f3d_10.json @@ -0,0 +1,212 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects PowerShell scripts with repeated invalid backtick escapes between word characters (letters, digits, underscore, or dash), splitting tokens while preserving execution. Attackers use this obfuscation to fragment keywords and evade pattern-based detection and AMSI.", + "from": "now-9m", + "investigation_fields": { + "field_names": [ + "@timestamp", + "user.name", + "user.id", + "user.domain", + "powershell.file.script_block_text", + "powershell.file.script_block_id", + "powershell.sequence", + "powershell.total", + "file.path", + "file.directory", + "file.name", + "process.pid", + "host.name", + "host.id", + "powershell.file.script_block_length" + ] + }, + "language": "esql", + "license": "Elastic License v2", + "name": "Potential PowerShell Obfuscation via Invalid Escape Sequences", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This guide was created by humans with the assistance of generative AI. While its contents have been manually curated to include the most valuable information, always validate assumptions and adjust procedures to match your internal runbooks and incident triage and response policies.\n\n### Investigating Potential PowerShell Obfuscation via Invalid Escape Sequences\n\nThis rule flags PowerShell script block content that repeatedly inserts invalid backtick escape sequences within otherwise contiguous word characters. This can fragment tokens (cmdlets, parameters, variable names, strings) while preserving execution and readability to the interpreter, which can hinder content inspection and pattern-based detections.\n\nAnalyst goals:\n- Reconstruct complete script block content when split across multiple events.\n- Normalize the content (remove or correct invalid escapes) to reveal the underlying logic.\n- Determine execution context (host, user, script origin) and correlate with adjacent activity to assess intent and impact.\n\n#### Key alert fields to review\n\n- `user.name`, `user.domain`, `user.id`: Account execution context for correlation, prioritization, and scoping.\n- `host.name`, `host.id`: Host execution context for correlation, prioritization, and scoping.\n- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file.\n- `powershell.file.script_block_text`: Script block content that matched the detection logic.\n- `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`: Script block metadata to pivot to other fragments or reconstruct full script content when split across multiple events.\n- `Esql.script_block_tmp`: Transformed script block where detection patterns replace original content with a marker to support scoring/counting and quickly spot match locations.\n- `Esql.script_block_pattern_count`: Count of matches for the detection pattern(s) observed in the script block content.\n- `powershell.file.script_block_entropy_bits`: Shannon entropy of the script block. Higher values may indicate obfuscation.\n- `powershell.file.script_block_surprisal_stdev`: Standard deviation of surprisal across the script block. Low values indicate uniform randomness. High values indicate mixed patterns and variability.\n- `powershell.file.script_block_unique_symbols`: Count of distinct characters present in the script block.\n- `powershell.file.script_block_length`: Script block length (size) context.\n\n#### Possible investigation steps\n\n- Establish timeline and ownership:\n - Anchor the activity using `@timestamp`, then record `host.name`, `host.id`, and `agent.id`.\n - Identify the execution context with `user.name`, `user.domain`, and `user.id`. Note whether the account is expected to run PowerShell on this host and whether the host is commonly used for scripting.\n\n- Assess the likelihood of intentional obfuscation:\n - Review `Esql.script_block_pattern_count` to understand how heavily the content is fragmented. Higher counts generally increase confidence that this is deliberate obfuscation rather than incidental escaping.\n - Use `powershell.file.script_block_length` as size context and review `powershell.file.script_block_entropy_bits`, `powershell.file.script_block_unique_symbols`, and `powershell.file.script_block_surprisal_stdev` to characterize the content (simple text vs. mixed/randomized payloads).\n - Compare `Esql.script_block_tmp` to `powershell.file.script_block_text` to understand where obfuscation is concentrated (localized string vs. widespread token fragmentation).\n\n- Reconstruct complete content when split across events:\n - If `powershell.total` is greater than 1, pivot on `powershell.file.script_block_id` and rebuild the script by ordering segments on `powershell.sequence`.\n - Validate the reconstructed set is complete (sequence 1 through `powershell.total`). Missing segments should be treated as an investigative gap and may require additional scoping.\n\n- Determine script origin and delivery:\n - If `file.path`, `file.directory`, and `file.name` are present, treat the script block as file-associated. Evaluate whether the location and naming are consistent with approved scripts or expected tooling for the endpoint.\n - If file fields are absent, treat the script as inline or dynamically generated content and prioritize correlation by `host.id`, `user.id`, and time.\n\n- Normalize and interpret the script content safely:\n - In a controlled analysis workflow, normalize the script by removing or correcting invalid backtick insertions so that split tokens become readable. Keep both the original and normalized versions for reporting.\n - Review the normalized text for behaviors that indicate malicious intent (secondary payload retrieval, dynamic execution, decoding/decompression, data collection, persistence logic, or remote interaction).\n - Extract and document indicators present in the content (network destinations, file paths/names, unique strings, or embedded encoded blobs) for scoping.\n\n- Correlate within PowerShell telemetry:\n - Pivot on `host.id` and `user.id` to identify additional `powershell.file.script_block_text` events shortly before and after the alert time to capture staging, follow-on commands, and potential cleanup.\n - Check for the same `powershell.file.script_block_id` appearing across hosts, or for repeated normalized strings, to identify automation reuse or broader activity.\n\n- Correlate with adjacent endpoint activity (if available in your environment):\n - Review process execution around `@timestamp` on `host.name` to identify the PowerShell host process and its parent, then assess whether the launch chain aligns with expected activity for the user and endpoint.\n - Review network activity around the alert time for connections that align with indicators extracted from the script content.\n - Review file and registry activity around the same time window for artifacts consistent with the script (new or modified scripts, dropped files, or persistence-related changes).\n - Review authentication activity associated with `user.id` around the alert time for suspicious logons or remote access that may align with script execution.\n\n- Scope impact:\n - Search for other alerts/events with similar obfuscation characteristics on the same host and for the same user to determine whether this is a one-off execution or a repeated pattern.\n - If multiple hosts are involved, prioritize investigation for critical assets and accounts with elevated privileges.\n\n### False positive analysis\n\n- Legitimate scripts can contain backticks for formatting, string construction, or content generation; however, repeated invalid escape sequences embedded inside alphanumeric tokens are uncommon. Validate whether the execution context (`host.id`, `user.id`) aligns with known administrative or developer activity.\n- Some commercial or internal tools intentionally obfuscate PowerShell to protect intellectual property. Confirm whether the script origin (`file.path` when present), account context, and prevalence across the environment match an approved application or workflow.\n- Copy/paste artifacts and encoding transformations can introduce unexpected characters. When suspected, compare the normalized content to known-good scripts and assess whether the obfuscation is systematic (repeating across many tokens) versus localized.\n\n### Response and remediation\n\n- If the activity is confirmed or strongly suspected malicious:\n - Contain affected host(s) to prevent further execution and lateral movement.\n - Preserve evidence: reconstructed `powershell.file.script_block_text`, `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`, and alert-derived fields (`Esql.script_block_tmp`, `Esql.script_block_pattern_count`, and the script block metrics).\n - If `file.path` is present, collect and quarantine the referenced script and review the surrounding directory for related artifacts.\n - Use indicators extracted from normalized content to scope related activity across endpoints (pivot on `host.id`, `user.id`, `file.path`, and unique strings from the script).\n - Coordinate credential remediation for affected accounts when remote execution, credential material, or post-exploitation behavior is suspected.\n\n- If the activity is benign but requires reduction:\n - Document the legitimate source (expected hosts/users and `file.path` when applicable).\n - Apply narrowly scoped tuning using stable attributes available in the alert (such as `host.id`, `user.id`, and `file.path`) and continue monitoring for deviations in script content and execution context.\n", + "query": "from logs-windows.powershell_operational* metadata _id, _version, _index\n| where event.code == \"4104\" and powershell.file.script_block_text like \"*`*\"\n\n// replace the patterns we are looking for with the \ud83d\udd25 emoji to enable counting them\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| eval Esql.script_block_tmp = replace(powershell.file.script_block_text, \"\"\"[A-Za-z0-9_-]`(?![rntb]|\\r|\\n|\\d)[A-Za-z0-9_-]\"\"\", \"\ud83d\udd25\")\n\n// count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| eval Esql.script_block_pattern_count = length(Esql.script_block_tmp) - length(replace(Esql.script_block_tmp, \"\ud83d\udd25\", \"\"))\n\n// keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| keep\n Esql.script_block_pattern_count,\n Esql.script_block_tmp,\n powershell.file.*,\n file.name,\n file.directory,\n file.path,\n powershell.sequence,\n powershell.total,\n _id,\n _version,\n _index,\n host.name,\n host.id,\n agent.id,\n user.id\n\n// Filter for scripts that match the pattern at least 20 times\n| where Esql.script_block_pattern_count >= 20\n\n| where file.name not like \"TSS_*.psm1\"\n // ESQL requires this condition, otherwise it only returns matches where file.name exists.\n or file.name is null\n\n// VSCode Shell integration\n| where not powershell.file.script_block_text like \"*$([char]0x1b)]633*\"\n\n| where not file.directory == \"C:\\\\Program Files\\\\MVPSI\\\\JAMS\\\\Agent\\\\Temp\"\n // ESQL requires this condition, otherwise it only returns matches where file.directory exists.\n or file.directory is null\n", + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.script_block_pattern_count", + "type": "integer" + }, + { + "ecs": false, + "name": "Esql.script_block_tmp", + "type": "keyword" + }, + { + "ecs": false, + "name": "_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "_index", + "type": "keyword" + }, + { + "ecs": false, + "name": "_version", + "type": "long" + }, + { + "ecs": true, + "name": "agent.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.directory", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.path", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.name", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_entropy_bits", + "type": "double" + }, + { + "ecs": false, + "name": "powershell.file.script_block_entropy_normalized", + "type": "double" + }, + { + "ecs": false, + "name": "powershell.file.script_block_hash", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_length", + "type": "long" + }, + { + "ecs": false, + "name": "powershell.file.script_block_surprisal_stdev", + "type": "double" + }, + { + "ecs": false, + "name": "powershell.file.script_block_text", + "type": "text" + }, + { + "ecs": false, + "name": "powershell.file.script_block_unique_symbols", + "type": "long" + }, + { + "ecs": false, + "name": "powershell.sequence", + "type": "long" + }, + { + "ecs": false, + "name": "powershell.total", + "type": "long" + }, + { + "ecs": true, + "name": "user.id", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "64f17c52-6c6e-479e-ba72-236f3df18f3d", + "setup": "## Setup\n\nPowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104).\nSetup instructions: https://ela.st/powershell-logging-setup\n", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: PowerShell Logs", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1027", + "name": "Obfuscated Files or Information", + "reference": "https://attack.mitre.org/techniques/T1027/" + }, + { + "id": "T1140", + "name": "Deobfuscate/Decode Files or Information", + "reference": "https://attack.mitre.org/techniques/T1140/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.001", + "name": "PowerShell", + "reference": "https://attack.mitre.org/techniques/T1059/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 10 + }, + "id": "64f17c52-6c6e-479e-ba72-236f3df18f3d_10", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/64f17c52-6c6e-479e-ba72-236f3df18f3d_6.json b/packages/security_detection_engine/kibana/security_rule/64f17c52-6c6e-479e-ba72-236f3df18f3d_6.json deleted file mode 100644 index 67393abb493..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/64f17c52-6c6e-479e-ba72-236f3df18f3d_6.json +++ /dev/null @@ -1,153 +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 the patterns we are looking for with the \ud83d\udd25 emoji to enable counting them\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| eval Esql.script_block_tmp = replace(powershell.file.script_block_text, \"\"\"[A-Za-z0-9_-]`(?![rntb]|\\r|\\n|\\d)[A-Za-z0-9_-]\"\"\", \"\ud83d\udd25\")\n\n// count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| eval Esql.script_block_pattern_count = length(Esql.script_block_tmp) - length(replace(Esql.script_block_tmp, \"\ud83d\udd25\", \"\"))\n\n// keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| keep\n Esql.script_block_pattern_count,\n Esql.script_block_tmp,\n powershell.file.script_block_text,\n powershell.file.script_block_id,\n file.name,\n file.directory,\n file.path,\n powershell.sequence,\n powershell.total,\n _id,\n _index,\n host.name,\n agent.id,\n user.id\n\n// Filter for scripts that match the pattern at least 10 times\n| where Esql.script_block_pattern_count >= 10\n\n| where file.name not like \"TSS_*.psm1\"\n // ESQL requires this condition, otherwise it only returns matches where file.name exists.\n or file.name is null\n\n// VSCode Shell integration\n| where not powershell.file.script_block_text like \"*$([char]0x1b)]633*\"\n\n| where not file.directory == \"C:\\\\Program Files\\\\MVPSI\\\\JAMS\\\\Agent\\\\Temp\"\n // ESQL requires this condition, otherwise it only returns matches where file.directory exists.\n or file.directory is null\n", - "related_integrations": [ - { - "package": "windows", - "version": "^3.0.0" - } - ], - "required_fields": [ - { - "ecs": false, - "name": "Esql.script_block_pattern_count", - "type": "integer" - }, - { - "ecs": false, - "name": "Esql.script_block_tmp", - "type": "keyword" - }, - { - "ecs": false, - "name": "_id", - "type": "keyword" - }, - { - "ecs": false, - "name": "_index", - "type": "keyword" - }, - { - "ecs": true, - "name": "agent.id", - "type": "keyword" - }, - { - "ecs": true, - "name": "file.directory", - "type": "keyword" - }, - { - "ecs": true, - "name": "file.name", - "type": "keyword" - }, - { - "ecs": true, - "name": "file.path", - "type": "keyword" - }, - { - "ecs": true, - "name": "host.name", - "type": "keyword" - }, - { - "ecs": false, - "name": "powershell.file.script_block_id", - "type": "keyword" - }, - { - "ecs": false, - "name": "powershell.file.script_block_text", - "type": "text" - }, - { - "ecs": false, - "name": "powershell.sequence", - "type": "long" - }, - { - "ecs": false, - "name": "powershell.total", - "type": "long" - }, - { - "ecs": true, - "name": "user.id", - "type": "keyword" - } - ], - "risk_score": 21, - "rule_id": "64f17c52-6c6e-479e-ba72-236f3df18f3d", - "setup": "## Setup\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nAdministrative Templates >\nWindows PowerShell >\nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n", - "severity": "low", - "tags": [ - "Domain: Endpoint", - "OS: Windows", - "Use Case: Threat Detection", - "Tactic: Defense Evasion", - "Data Source: PowerShell Logs", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0005", - "name": "Defense Evasion", - "reference": "https://attack.mitre.org/tactics/TA0005/" - }, - "technique": [ - { - "id": "T1027", - "name": "Obfuscated Files or Information", - "reference": "https://attack.mitre.org/techniques/T1027/" - }, - { - "id": "T1140", - "name": "Deobfuscate/Decode Files or Information", - "reference": "https://attack.mitre.org/techniques/T1140/" - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0002", - "name": "Execution", - "reference": "https://attack.mitre.org/tactics/TA0002/" - }, - "technique": [ - { - "id": "T1059", - "name": "Command and Scripting Interpreter", - "reference": "https://attack.mitre.org/techniques/T1059/", - "subtechnique": [ - { - "id": "T1059.001", - "name": "PowerShell", - "reference": "https://attack.mitre.org/techniques/T1059/001/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 6 - }, - "id": "64f17c52-6c6e-479e-ba72-236f3df18f3d_6", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/66883649-f908-4a5b-a1e0-54090a1d3a32_123.json b/packages/security_detection_engine/kibana/security_rule/66883649-f908-4a5b-a1e0-54090a1d3a32_123.json deleted file mode 100644 index d82d2005165..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/66883649-f908-4a5b-a1e0-54090a1d3a32_123.json +++ /dev/null @@ -1,159 +0,0 @@ -{ - "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/6926b708-7964-425f-bed8-6e006379df08_2.json b/packages/security_detection_engine/kibana/security_rule/6926b708-7964-425f-bed8-6e006379df08_2.json new file mode 100644 index 00000000000..92ca3e68626 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/6926b708-7964-425f-bed8-6e006379df08_2.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": "FortiGate SOCKS Traffic from an Unusual Process", + "note": "## Triage and analysis\n\n### Investigating FortiGate 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": 2 + }, + "id": "6926b708-7964-425f-bed8-6e006379df08_2", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/6ddb6c33-00ce-4acd-832a-24b251512023_5.json b/packages/security_detection_engine/kibana/security_rule/6ddb6c33-00ce-4acd-832a-24b251512023_5.json deleted file mode 100644 index e0b59fbbb07..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/6ddb6c33-00ce-4acd-832a-24b251512023_5.json +++ /dev/null @@ -1,153 +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", - "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Potential PowerShell Obfuscation via Special Character Overuse\n\nPowerShell is a powerful scripting language used for task automation and configuration management in Windows environments. Adversaries exploit PowerShell's flexibility to obfuscate scripts, using excessive special characters to evade detection. The detection rule identifies scripts with high special character density, indicating potential obfuscation, by analyzing script length and character patterns, thus aiding in uncovering malicious activities.\n\n### Possible investigation steps\n\n- Review the dedup_space_script_block field to understand the script's structure and identify any suspicious patterns or keywords that might indicate obfuscation techniques.\n- Analyze the replaced_with_fire field to assess the density and distribution of special characters, which can provide insights into the obfuscation methods used.\n- Examine the file.path and host.name fields to determine the origin and context of the script execution, which can help identify if the script was run on a critical system or by a privileged user.\n- Check the user.id and agent.id fields to verify the identity of the user or agent executing the script, which can help assess if the activity aligns with expected behavior or if it might be unauthorized.\n- Correlate the powershell.file.script_block_id with other logs or alerts to identify if similar scripts have been executed elsewhere in the environment, indicating a broader attack pattern.\n\n### False positive analysis\n\n- Scripts with legitimate use of special characters for formatting or encoding may trigger false positives. Review the script's purpose and context to determine if the use of special characters is justified.\n- Automated scripts that heavily rely on string manipulation or dynamic content generation might be flagged. Consider adding exceptions for known scripts or trusted sources to reduce unnecessary alerts.\n- PowerShell scripts used in development or testing environments often contain high special character density. Implement environment-based exclusions to prevent these from being flagged in non-production settings.\n- Scripts utilizing SecureString or other security-related encoding methods may appear obfuscated. Verify the script's origin and purpose, and whitelist these methods if they are part of standard security practices.\n- Regularly update the detection rule to refine the pattern matching and reduce false positives by incorporating feedback from security analysts and system administrators.\n\n### Response and remediation\n\n- Isolate the affected host immediately to prevent lateral movement and further execution of potentially malicious scripts.\n- Terminate any suspicious PowerShell processes identified by the alert to halt ongoing malicious activity.\n- Conduct a thorough review of the script block text and associated metadata to understand the intent and potential impact of the obfuscated script.\n- Remove any unauthorized or malicious scripts from the affected system to prevent re-execution.\n- Restore the system from a known good backup if the script has caused significant changes or damage to the system.\n- Update endpoint protection and intrusion detection systems to recognize and block similar obfuscation techniques in the future.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.\n", - "query": "from logs-windows.powershell_operational* metadata _id, _version, _index\n| where event.code == \"4104\"\n\n// replace repeated spaces used for formatting after a new line with a single space to reduce FPs\n| eval Esql.script_block_tmp = replace(powershell.file.script_block_text, \"\"\"\\n\\s+\"\"\", \"\\n \")\n\n// Look for scripts with more than 1000 chars\n| eval Esql.script_block_length = length(Esql.script_block_tmp)\n| where Esql.script_block_length > 1000\n\n// replace the patterns we are looking for with the \ud83d\udd25 emoji to enable counting them\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| eval Esql.script_block_tmp = replace(\n Esql.script_block_tmp,\n \"\"\"[\\s\\$\\{\\}\\+\\@\\=\\(\\)\\^\\\\\\\"~\\[\\]\\?\\.]\"\"\",\n \"\ud83d\udd25\"\n)\n\n// count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| eval Esql.script_block_count = Esql.script_block_length - length(replace(Esql.script_block_tmp, \"\ud83d\udd25\", \"\"))\n\n// Calculate the ratio of special characters to total length\n| eval Esql.script_block_ratio = Esql.script_block_count::double / Esql.script_block_length::double\n\n// keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| keep\n Esql.script_block_count,\n Esql.script_block_length,\n Esql.script_block_ratio,\n Esql.script_block_tmp,\n powershell.file.script_block_text,\n powershell.file.script_block_id,\n file.path,\n powershell.sequence,\n powershell.total,\n _id,\n _index,\n host.name,\n agent.id,\n user.id\n\n// Filter for scripts with high whitespace and special character ratio\n| where Esql.script_block_ratio > 0.75\n", - "related_integrations": [ - { - "package": "windows", - "version": "^3.0.0" - } - ], - "required_fields": [ - { - "ecs": false, - "name": "Esql.script_block_count", - "type": "integer" - }, - { - "ecs": false, - "name": "Esql.script_block_length", - "type": "integer" - }, - { - "ecs": false, - "name": "Esql.script_block_ratio", - "type": "double" - }, - { - "ecs": false, - "name": "Esql.script_block_tmp", - "type": "keyword" - }, - { - "ecs": false, - "name": "_id", - "type": "keyword" - }, - { - "ecs": false, - "name": "_index", - "type": "keyword" - }, - { - "ecs": true, - "name": "agent.id", - "type": "keyword" - }, - { - "ecs": true, - "name": "file.path", - "type": "keyword" - }, - { - "ecs": true, - "name": "host.name", - "type": "keyword" - }, - { - "ecs": false, - "name": "powershell.file.script_block_id", - "type": "keyword" - }, - { - "ecs": false, - "name": "powershell.file.script_block_text", - "type": "text" - }, - { - "ecs": false, - "name": "powershell.sequence", - "type": "long" - }, - { - "ecs": false, - "name": "powershell.total", - "type": "long" - }, - { - "ecs": true, - "name": "user.id", - "type": "keyword" - } - ], - "risk_score": 21, - "rule_id": "6ddb6c33-00ce-4acd-832a-24b251512023", - "setup": "## Setup\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nAdministrative Templates >\nWindows PowerShell >\nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n", - "severity": "low", - "tags": [ - "Domain: Endpoint", - "OS: Windows", - "Use Case: Threat Detection", - "Tactic: Defense Evasion", - "Data Source: PowerShell Logs", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0005", - "name": "Defense Evasion", - "reference": "https://attack.mitre.org/tactics/TA0005/" - }, - "technique": [ - { - "id": "T1027", - "name": "Obfuscated Files or Information", - "reference": "https://attack.mitre.org/techniques/T1027/" - }, - { - "id": "T1140", - "name": "Deobfuscate/Decode Files or Information", - "reference": "https://attack.mitre.org/techniques/T1140/" - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0002", - "name": "Execution", - "reference": "https://attack.mitre.org/tactics/TA0002/" - }, - "technique": [ - { - "id": "T1059", - "name": "Command and Scripting Interpreter", - "reference": "https://attack.mitre.org/techniques/T1059/", - "subtechnique": [ - { - "id": "T1059.001", - "name": "PowerShell", - "reference": "https://attack.mitre.org/techniques/T1059/001/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 5 - }, - "id": "6ddb6c33-00ce-4acd-832a-24b251512023_5", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/6ddb6c33-00ce-4acd-832a-24b251512023_9.json b/packages/security_detection_engine/kibana/security_rule/6ddb6c33-00ce-4acd-832a-24b251512023_9.json new file mode 100644 index 00000000000..47b8b843a31 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/6ddb6c33-00ce-4acd-832a-24b251512023_9.json @@ -0,0 +1,212 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects PowerShell scripts dominated by whitespace and special characters with low symbol diversity, a profile often produced by formatting or encoding obfuscation. Attackers use symbol-heavy encoding or formatting (for example, SecureString-style blobs or character-level transforms) to hide payloads and evade static analysis and AMSI.", + "from": "now-9m", + "investigation_fields": { + "field_names": [ + "@timestamp", + "user.name", + "user.id", + "user.domain", + "powershell.file.script_block_text", + "powershell.file.script_block_id", + "powershell.sequence", + "powershell.total", + "file.path", + "file.directory", + "file.name", + "process.pid", + "host.name", + "host.id", + "powershell.file.script_block_length" + ] + }, + "language": "esql", + "license": "Elastic License v2", + "name": "Potential PowerShell Obfuscation via Special Character Overuse", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This guide was created by humans with the assistance of generative AI. While its contents have been manually curated to include the most valuable information, always validate assumptions and adjust procedures to match your internal runbooks and incident triage and response policies.\n\n### Investigating Potential PowerShell Obfuscation via Special Character Overuse\n\nThis rule flags PowerShell script block content that is unusually long and dominated by whitespace and a narrow set of special characters. This profile is often associated with formatting or encoding obfuscation where payload logic is transformed into symbol-heavy strings and reconstructed at runtime. Use the steps below to validate execution context, reconstruct full content, determine likely intent, and scope related activity.\n\n#### Key alert fields to review\n\n- `user.name`, `user.domain`, `user.id`: Account execution context for correlation, prioritization, and scoping.\n- `host.name`, `host.id`: Host execution context for correlation, prioritization, and scoping.\n- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file.\n- `powershell.file.script_block_text`: Script block content that matched the detection logic.\n- `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`: Script block metadata to pivot to other fragments or reconstruct full script content when split across multiple events.\n- `Esql.script_block_tmp`: Transformed script block where detection patterns replace original content with a marker to support scoring/counting and quickly spot match locations.\n- `Esql.script_block_ratio`: Proportion of the script block's characters that match the alert's target character set, divided by total script length (0-1).\n- `Esql.script_block_pattern_count`: Count of matches for the detection pattern(s) observed in the script block content.\n- `powershell.file.script_block_entropy_bits`: Shannon entropy of the script block. Higher values may indicate obfuscation.\n- `powershell.file.script_block_surprisal_stdev`: Standard deviation of surprisal across the script block. Low values indicate uniform randomness. High values indicate mixed patterns and variability.\n- `powershell.file.script_block_unique_symbols`: Count of distinct characters present in the script block.\n- `powershell.file.script_block_length`: Script block length (size) context.\n\n#### Possible investigation steps\n\n- Review alert context and scope:\n - Use `@timestamp` to identify when the activity occurred and to bound the timeline for correlation.\n - Review `host.name` and `host.id` to understand which endpoint produced the script block.\n - Review `user.name`, `user.domain`, and `user.id` to determine whether the account is expected to run PowerShell on this host.\n - If multiple alerts are present, group by `host.id` and `user.id` to identify concentrated or repeat activity.\n\n- Analyze the script block content for obfuscation and intent:\n - Inspect `powershell.file.script_block_text` to understand what is being executed. Obfuscation commonly presents as large blocks of escaped characters, excessive punctuation, and character-level reassembly.\n - Use `Esql.script_block_tmp` to quickly locate symbol-dense regions, then interpret the corresponding content in `powershell.file.script_block_text`.\n - Use `Esql.script_block_ratio`, `powershell.file.script_block_unique_symbols`, `powershell.file.script_block_entropy_bits`, and `powershell.file.script_block_surprisal_stdev` to gauge how atypical the content is compared to known-good scripts in your environment.\n - Identify deobfuscation and runtime execution patterns such as repeated string replacement, concatenation, `[char]` casting, `-join`, formatting operators, reflection, and dynamic invocation (for example, `Invoke-Expression` or executing decoded strings).\n - Capture any embedded indicators from `powershell.file.script_block_text`, including URLs, hostnames, IP addresses, file paths, registry paths, or scheduled task/service names.\n\n- Reconstruct full script content when logged in chunks:\n - If `powershell.total` indicates multiple fragments, pivot on `powershell.file.script_block_id` and reassemble the script in `powershell.sequence` order.\n - Confirm completeness by comparing observed fragments to `powershell.total`. Missing segments can hide key decode or execution stages.\n\n- Validate script origin and expected usage:\n - Review `file.path`, `file.directory`, and `file.name` (when present) to determine whether the script originated from disk, a module path, or an unusual location.\n - If the script is file-backed, assess whether the file location and naming are consistent with approved administration and automation practices for the host and user.\n\n- Scope for related PowerShell activity:\n - Pivot on `powershell.file.script_block_hash` (when available) to identify repeated executions of the same content across hosts and users.\n - Review additional script blocks on the same `host.id` and `user.id` around the alert time for staging behavior (variable setup, decoding routines, or creation of additional script blocks).\n - Use stable substrings from `powershell.file.script_block_text` (unique function names or strings) to find related executions that may not match this specific obfuscation profile.\n\n- Correlate with adjacent telemetry to confirm execution chain and impact (if available):\n - Use `host.id`, `user.id`, and `@timestamp` to pivot into process telemetry and determine which process initiated PowerShell and whether the parent process is expected.\n - Review activity on the same host around the alert time for signs of follow-on behavior such as outbound connections, file creation/modification, registry changes, or persistence mechanisms consistent with the recovered script logic.\n\n### False positive analysis\n\n- Legitimate automation can embed large protected or serialized values (for example, encrypted configuration blobs or SecureString exports) that appear symbol-heavy.\n- Deployment and configuration tooling may generate templated PowerShell with extensive escaping or large here-strings, especially when embedding JSON/XML or code as data.\n- Authorized security testing may use obfuscation techniques that resemble this behavior.\n- To validate a benign source, confirm the script's provenance and repeatability:\n - Check whether `file.path` (when present) and `powershell.file.script_block_hash` consistently map to an approved script, owner, and expected execution pattern.\n - Compare the alerting `user.id` and `host.id` against known automation accounts and managed endpoints; unexpected combinations warrant escalation.\n\n### Response and remediation\n\n- If malicious or suspicious activity is confirmed:\n - Contain the affected host according to your incident response procedures to prevent additional execution and lateral movement.\n - Preserve evidence for triage and forensics, including `powershell.file.script_block_text` (and any reconstructed content), `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`, `powershell.file.script_block_hash` (if available), `file.path` (if present), and the execution context (`host.name`, `host.id`, `user.name`, `user.domain`, `user.id`, `agent.id`, `@timestamp`).\n - Scope the activity by searching for the same `powershell.file.script_block_hash` and any extracted indicators across the environment.\n - Identify and remediate follow-on actions associated with the script (downloaded payloads, dropped files, persistence changes, or credential access). Apply blocking controls for confirmed indicators where feasible.\n - If the script content indicates credential material handling or unauthorized automation, rotate affected credentials and review account activity for misuse.\n\n- If the activity is determined to be benign:\n - Document the script owner, purpose, and expected execution context (hosts, users, and schedule), using `file.path` and `powershell.file.script_block_hash` (when available) as stable identifiers.\n - Monitor for drift, such as execution by different users/hosts, unexpected file paths, or material changes in the script block content.\n", + "query": "from logs-windows.powershell_operational* metadata _id, _version, _index\n| where event.code == \"4104\"\n\n// filter for scripts with low unique symbol counts, which can indicate special character obfuscation\n| where powershell.file.script_block_unique_symbols < 50\n\n// replace repeated spaces used for formatting after a new line with a single space to reduce FPs\n| eval Esql.script_block_tmp = replace(powershell.file.script_block_text, \"\"\"\\n\\s+\"\"\", \"\\n \")\n\n// Look for scripts with more than 1000 chars\n| eval Esql.script_block_length = length(Esql.script_block_tmp)\n| where Esql.script_block_length > 1000\n\n// replace the patterns we are looking for with the \ud83d\udd25 emoji to enable counting them\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| eval Esql.script_block_tmp = replace(\n Esql.script_block_tmp,\n \"\"\"[\\s\\$\\{\\}\\+\\@\\=\\(\\)\\^\\\\\\\"~\\[\\]\\?\\./%#\\`\\'\\;\\-\\!\\*]\"\"\",\n \"\ud83d\udd25\"\n)\n\n// count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| eval Esql.script_block_count = Esql.script_block_length - length(replace(Esql.script_block_tmp, \"\ud83d\udd25\", \"\"))\n\n// Calculate the ratio of special characters to total length\n| eval Esql.script_block_ratio = Esql.script_block_count::double / Esql.script_block_length::double\n\n// keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| keep\n Esql.script_block_count,\n Esql.script_block_length,\n Esql.script_block_ratio,\n Esql.script_block_tmp,\n powershell.file.*,\n file.path,\n powershell.sequence,\n powershell.total,\n _id,\n _version,\n _index,\n host.name,\n host.id,\n agent.id,\n user.id\n\n// Filter for scripts with high whitespace and special character ratio\n| where Esql.script_block_ratio >= 0.75\n", + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.script_block_count", + "type": "integer" + }, + { + "ecs": false, + "name": "Esql.script_block_length", + "type": "integer" + }, + { + "ecs": false, + "name": "Esql.script_block_ratio", + "type": "double" + }, + { + "ecs": false, + "name": "Esql.script_block_tmp", + "type": "keyword" + }, + { + "ecs": false, + "name": "_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "_index", + "type": "keyword" + }, + { + "ecs": false, + "name": "_version", + "type": "long" + }, + { + "ecs": true, + "name": "agent.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.path", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.name", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_entropy_bits", + "type": "double" + }, + { + "ecs": false, + "name": "powershell.file.script_block_entropy_normalized", + "type": "double" + }, + { + "ecs": false, + "name": "powershell.file.script_block_hash", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_length", + "type": "long" + }, + { + "ecs": false, + "name": "powershell.file.script_block_surprisal_stdev", + "type": "double" + }, + { + "ecs": false, + "name": "powershell.file.script_block_text", + "type": "text" + }, + { + "ecs": false, + "name": "powershell.file.script_block_unique_symbols", + "type": "long" + }, + { + "ecs": false, + "name": "powershell.sequence", + "type": "long" + }, + { + "ecs": false, + "name": "powershell.total", + "type": "long" + }, + { + "ecs": true, + "name": "user.id", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "6ddb6c33-00ce-4acd-832a-24b251512023", + "setup": "## Setup\n\nPowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104).\nSetup instructions: https://ela.st/powershell-logging-setup\n\nThis rule uses the following fields that require the Windows Integration v3.3.0 and up: `powershell.file.script_block_unique_symbols`.\n", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: PowerShell Logs", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1027", + "name": "Obfuscated Files or Information", + "reference": "https://attack.mitre.org/techniques/T1027/" + }, + { + "id": "T1140", + "name": "Deobfuscate/Decode Files or Information", + "reference": "https://attack.mitre.org/techniques/T1140/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.001", + "name": "PowerShell", + "reference": "https://attack.mitre.org/techniques/T1059/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 9 + }, + "id": "6ddb6c33-00ce-4acd-832a-24b251512023_9", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/6e1a2cc4-d260-11ed-8829-f661ea17fbcc_111.json b/packages/security_detection_engine/kibana/security_rule/6e1a2cc4-d260-11ed-8829-f661ea17fbcc_111.json deleted file mode 100644 index 390f802e3bf..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/6e1a2cc4-d260-11ed-8829-f661ea17fbcc_111.json +++ /dev/null @@ -1,118 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Adversaries may install legitimate remote access tools (RAT) to compromised endpoints for further command-and-control (C2). Adversaries can rely on installed RATs for persistence, execution of native commands and more. This rule detects when a process is started whose name or code signature resembles commonly abused RATs. This is a New Terms rule type indicating the host has not seen this RAT process started before within the last 30 days.", - "from": "now-9m", - "history_window_start": "now-15d", - "index": [ - "logs-endpoint.events.process-*", - "endgame-*", - "winlogbeat-*", - "logs-windows.forwarded*", - "logs-windows.sysmon_operational-*", - "logs-system.security*" - ], - "language": "kuery", - "license": "Elastic License v2", - "name": "First Time Seen Commonly Abused Remote Access Tool Execution", - "new_terms_fields": [ - "host.id" - ], - "note": "## Triage and analysis\n\n### Investigating First Time Seen Commonly Abused Remote Access Tool Execution\n\nRemote access software is a class of tools commonly used by IT departments to provide support by connecting securely to users' computers. Remote access is an ever-growing market where new companies constantly offer new ways of quickly accessing remote systems.\n\nAt the same pace as IT departments adopt these tools, the attackers also adopt them as part of their workflow to connect into an interactive session, maintain access with legitimate software as a persistence mechanism, drop malicious software, etc.\n\nThis rule detects when a remote access tool is seen in the environment for the first time in the last 15 days, enabling analysts to investigate and enforce the correct usage of such tools.\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- Check if the execution of the remote access tool is approved by the organization's IT department.\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 - If the tool is not approved for use in the organization, the employee could have been tricked into installing it and providing access to a malicious third party. Investigate whether this third party could be attempting to scam the end-user or gain access to the environment through social engineering.\n- Investigate any abnormal behavior by the subject process, such as network connections, registry or file modifications, and any spawned child processes.\n\n### False positive analysis\n\n- If an authorized support person or administrator used the tool to conduct legitimate support or remote access, consider reinforcing that only tooling approved by the IT policy should be used. The analyst can dismiss the alert if no other suspicious behavior is observed involving the host or users.\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- Run a full scan using the antimalware tool in place. This scan can reveal additional artifacts left in the system, persistence mechanisms, and malware components.\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 an unauthorized third party did the access via social engineering, consider improvements to the security awareness program.\n- Enforce that only tooling approved by the IT policy should be used for remote access purposes and only by authorized staff.\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": "host.os.type: \"windows\" and\n\n event.category: \"process\" and event.type : \"start\" and\n\n (\n process.code_signature.subject_name : (\n \"Action1 Corporation\" or\n \"AeroAdmin LLC\" or\n \"Ammyy LLC\" or\n \"Atera Networks Ltd\" or\n \"AWERAY PTE. LTD.\" or\n \"BeamYourScreen GmbH\" or\n \"Bomgar Corporation\" or\n \"DUC FABULOUS CO.,LTD\" or\n \"DOMOTZ INC.\" or\n \"DWSNET O\u00dc\" or\n \"FleetDeck Inc\" or\n \"GlavSoft LLC\" or\n \"GlavSoft LLC.\" or\n \"Hefei Pingbo Network Technology Co. Ltd\" or\n \"IDrive, Inc.\" or\n \"IMPERO SOLUTIONS LIMITED\" or\n \"Instant Housecall\" or\n \"ISL Online Ltd.\" or\n \"LogMeIn, Inc.\" or\n \"Monitoring Client\" or\n \"MMSOFT Design Ltd.\" or\n \"Nanosystems S.r.l.\" or\n \"NetSupport Ltd\" or\n \"NinjaRMM, LLC\" or\n \"Parallels International GmbH\" or\n \"philandro Software GmbH\" or\n \"Pro Softnet Corporation\" or\n \"RealVNC\" or\n \"RealVNC Limited\" or\n \"BreakingSecurity.net\" or\n \"Remote Utilities LLC\" or\n \"Rocket Software, Inc.\" or\n \"SAFIB\" or\n \"Servably, Inc.\" or\n \"ShowMyPC INC\" or\n \"Splashtop Inc.\" or\n \"Superops Inc.\" or\n \"TeamViewer\" or\n \"TeamViewer GmbH\" or\n \"TeamViewer Germany GmbH\" or\n \"Techinline Limited\" or\n \"uvnc bvba\" or\n \"Yakhnovets Denis Aleksandrovich IP\" or\n \"Zhou Huabing\"\n ) or\n\n process.name.caseless : (\n AA_v*.exe or\n \"AeroAdmin.exe\" or\n \"AnyDesk.exe\" or\n \"apc_Admin.exe\" or\n \"apc_host.exe\" or\n \"AteraAgent.exe\" or\n aweray_remote*.exe or\n \"AweSun.exe\" or\n \"B4-Service.exe\" or\n \"BASupSrvc.exe\" or\n \"bomgar-scc.exe\" or\n \"domotzagent.exe\" or\n \"domotz-windows-x64-10.exe\" or\n \"dwagsvc.exe\" or\n \"DWRCC.exe\" or\n \"ImperoClientSVC.exe\" or\n \"ImperoServerSVC.exe\" or\n \"ISLLight.exe\" or\n \"ISLLightClient.exe\" or\n fleetdeck_commander*.exe or\n \"getscreen.exe\" or\n \"LMIIgnition.exe\" or\n \"LogMeIn.exe\" or\n \"ManageEngine_Remote_Access_Plus.exe\" or\n \"Mikogo-Service.exe\" or\n \"NinjaRMMAgent.exe\" or\n \"NinjaRMMAgenPatcher.exe\" or\n \"ninjarmm-cli.exe\" or\n \"r_server.exe\" or\n \"radmin.exe\" or\n \"radmin3.exe\" or\n \"RCClient.exe\" or\n \"RCService.exe\" or\n \"RemoteDesktopManager.exe\" or\n \"RemotePC.exe\" or\n \"RemotePCDesktop.exe\" or\n \"RemotePCService.exe\" or\n \"rfusclient.exe\" or\n \"ROMServer.exe\" or\n \"ROMViewer.exe\" or\n \"RPCSuite.exe\" or\n \"rserver3.exe\" or\n \"rustdesk.exe\" or\n \"rutserv.exe\" or\n \"rutview.exe\" or\n \"saazapsc.exe\" or\n ScreenConnect*.exe or\n \"smpcview.exe\" or\n \"spclink.exe\" or\n \"Splashtop-streamer.exe\" or\n \"SRService.exe\" or\n \"strwinclt.exe\" or\n \"Supremo.exe\" or\n \"SupremoService.exe\" or\n \"teamviewer.exe\" or\n \"TiClientCore.exe\" or\n \"TSClient.exe\" or\n \"tvn.exe\" or\n \"tvnserver.exe\" or\n \"tvnviewer.exe\" or\n UltraVNC*.exe or\n UltraViewer*.exe or\n \"vncserver.exe\" or\n \"vncviewer.exe\" or\n \"winvnc.exe\" or\n \"winwvc.exe\" or\n \"Zaservice.exe\" or\n \"ZohoURS.exe\"\n ) or\n process.name : (\n AA_v*.exe or\n \"AeroAdmin.exe\" or\n \"AnyDesk.exe\" or\n \"apc_Admin.exe\" or\n \"apc_host.exe\" or\n \"AteraAgent.exe\" or\n aweray_remote*.exe or\n \"AweSun.exe\" or\n \"B4-Service.exe\" or\n \"BASupSrvc.exe\" or\n \"bomgar-scc.exe\" or\n \"domotzagent.exe\" or\n \"domotz-windows-x64-10.exe\" or\n \"dwagsvc.exe\" or\n \"DWRCC.exe\" or\n \"ImperoClientSVC.exe\" or\n \"ImperoServerSVC.exe\" or\n \"ISLLight.exe\" or\n \"ISLLightClient.exe\" or\n fleetdeck_commander*.exe or\n \"getscreen.exe\" or\n \"LMIIgnition.exe\" or\n \"LogMeIn.exe\" or\n \"ManageEngine_Remote_Access_Plus.exe\" or\n \"Mikogo-Service.exe\" or\n \"NinjaRMMAgent.exe\" or\n \"NinjaRMMAgenPatcher.exe\" or\n \"ninjarmm-cli.exe\" or\n \"r_server.exe\" or\n \"radmin.exe\" or\n \"radmin3.exe\" or\n \"RCClient.exe\" or\n \"RCService.exe\" or\n \"RemoteDesktopManager.exe\" or\n \"RemotePC.exe\" or\n \"RemotePCDesktop.exe\" or\n \"RemotePCService.exe\" or\n \"rfusclient.exe\" or\n \"ROMServer.exe\" or\n \"ROMViewer.exe\" or\n \"RPCSuite.exe\" or\n \"rserver3.exe\" or\n \"rustdesk.exe\" or\n \"rutserv.exe\" or\n \"rutview.exe\" or\n \"saazapsc.exe\" or\n ScreenConnect*.exe or\n \"smpcview.exe\" or\n \"spclink.exe\" or\n \"Splashtop-streamer.exe\" or\n \"SRService.exe\" or\n \"strwinclt.exe\" or\n \"Supremo.exe\" or\n \"SupremoService.exe\" or\n \"teamviewer.exe\" or\n \"TiClientCore.exe\" or\n \"TSClient.exe\" or\n \"tvn.exe\" or\n \"tvnserver.exe\" or\n \"tvnviewer.exe\" or\n UltraVNC*.exe or\n UltraViewer*.exe or\n \"vncserver.exe\" or\n \"vncviewer.exe\" or\n \"winvnc.exe\" or\n \"winwvc.exe\" or\n \"Zaservice.exe\" or\n \"ZohoURS.exe\"\n )\n\t) and\n\n\tnot (process.pe.original_file_name : (\"G2M.exe\" or \"Updater.exe\" or \"powershell.exe\") and process.code_signature.subject_name : \"LogMeIn, Inc.\")\n", - "references": [ - "https://thedfirreport.com/2023/04/03/malicious-iso-file-leads-to-domain-wide-ransomware/", - "https://attack.mitre.org/techniques/T1219/", - "https://github.com/redcanaryco/surveyor/blob/master/definitions/remote-admin.json" - ], - "related_integrations": [ - { - "package": "endpoint", - "version": "^8.2.0" - }, - { - "package": "windows", - "version": "^2.0.0" - }, - { - "package": "system", - "version": "^1.6.4" - } - ], - "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.code_signature.subject_name", - "type": "keyword" - }, - { - "ecs": true, - "name": "process.name", - "type": "keyword" - }, - { - "ecs": false, - "name": "process.name.caseless", - "type": "unknown" - }, - { - "ecs": true, - "name": "process.pe.original_file_name", - "type": "keyword" - } - ], - "risk_score": 47, - "rule_id": "6e1a2cc4-d260-11ed-8829-f661ea17fbcc", - "severity": "medium", - "tags": [ - "Domain: Endpoint", - "OS: Windows", - "Use Case: Threat Detection", - "Tactic: Command and Control", - "Resources: Investigation Guide", - "Data Source: Elastic Defend", - "Data Source: Elastic Endgame", - "Data Source: Windows Security Event Logs", - "Data Source: Sysmon" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0011", - "name": "Command and Control", - "reference": "https://attack.mitre.org/tactics/TA0011/" - }, - "technique": [ - { - "id": "T1219", - "name": "Remote Access Software", - "reference": "https://attack.mitre.org/techniques/T1219/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "new_terms", - "version": 111 - }, - "id": "6e1a2cc4-d260-11ed-8829-f661ea17fbcc_111", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/6e92a21a-58e7-449a-9cfd-9f563f59ac88_2.json b/packages/security_detection_engine/kibana/security_rule/6e92a21a-58e7-449a-9cfd-9f563f59ac88_2.json new file mode 100644 index 00000000000..cb00389d735 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/6e92a21a-58e7-449a-9cfd-9f563f59ac88_2.json @@ -0,0 +1,95 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule correlates multiple security alerts associated with the same ATT&CK tactic on a single host within a defined time window. By requiring alerts from multiple distinct detection rules, this detection helps identify hosts exhibiting concentrated malicious behavior, which may indicate an active intrusion or post-compromise activity. The rule is intended to assist analysts in prioritizing triage toward hosts with higher likelihood of compromise rather than signaling a single discrete event.", + "from": "now-60m", + "interval": "30m", + "language": "esql", + "license": "Elastic License v2", + "name": "Multiple Alerts in Same ATT&CK Tactic 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 Multiple Alerts in Same ATT&CK Tactic by Host\n\nThe detection rule identifies hosts with alerts from the same ATT&CK tactic, indicating potential compromise. Adversaries exploit system vulnerabilities, moving through different tactics like execution, defense evasion, and credential access. This rule prioritizes hosts with high-risk.\n\n### Possible investigation steps\n\n- Review the alert details to identify the specific host involved and the different techniques 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 rules. Review and exclude known benign activities such as scheduled software updates or system maintenance.\n- Security tools running on the host might generate multiple alerts. 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| where kibana.alert.risk_score > 21 and\n kibana.alert.rule.name IS NOT NULL and\n host.id is not null and event.dataset is not null and\n\n // excluding ML and Threat Match rules as they tend to be noisy\n not kibana.alert.rule.type in (\"threat_match\", \"machine_learning\") and\n\n // excluding noisy tactics like Discovery, Persistence and Lateral Movement\n kibana.alert.rule.threat.tactic.name in (\"Credential Access\", \"Defense Evasion\", \"Execution\", \"Command and Control\") and\n\n // excluding some noisy rules\n not kibana.alert.rule.name in (\"Agent Spoofing - Mismatched Agent ID\", \"Process Termination followed by Deletion\") and\n not KQL(\"\"\"kibana.alert.rule.tags : \"Rule Type: Higher-Order Rule\" \"\"\")\n\n// extract unique counts and values by host.id and tactic name\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_technique_id_distinct_count = COUNT_DISTINCT(kibana.alert.rule.threat.technique.id),\n Esql.threat_technique_name_values = VALUES(kibana.alert.rule.threat.technique.name),\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, kibana.alert.rule.threat.tactic.name\n\n// filter for at least 3 unique rules and exclude noisy patterns like high count of alerts or processes often associated with noisy FPs\n| where Esql.kibana_alert_rule_name_distinct_count >= 3 and Esql.process_entity_id_distinct_count <= 10 and Esql.alerts_count <= 20\n\n// fields populated in the resulting alerts\n| Keep host.id, kibana.alert.rule.threat.tactic.name, Esql.*\n", + "required_fields": [ + { + "ecs": false, + "name": "Esql.alerts_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.event_module_distinct_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.event_module_values", + "type": "keyword" + }, + { + "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_entity_id_distinct_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.process_executable_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.process_parent_executable_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.threat_technique_id_distinct_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.threat_technique_name_values", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.id", + "type": "keyword" + }, + { + "ecs": false, + "name": "kibana.alert.rule.threat.tactic.name", + "type": "keyword" + } + ], + "risk_score": 73, + "rule_id": "6e92a21a-58e7-449a-9cfd-9f563f59ac88", + "severity": "high", + "tags": [ + "Use Case: Threat Detection", + "Rule Type: Higher-Order Rule", + "Resources: Investigation Guide" + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 2 + }, + "id": "6e92a21a-58e7-449a-9cfd-9f563f59ac88_2", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/6ee947e9-de7e-4281-a55d-09289bdf947e_114.json b/packages/security_detection_engine/kibana/security_rule/6ee947e9-de7e-4281-a55d-09289bdf947e_114.json new file mode 100644 index 00000000000..d1802ecff41 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/6ee947e9-de7e-4281-a55d-09289bdf947e_114.json @@ -0,0 +1,124 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule monitors for a set of Linux utilities that can be used for tunneling and port forwarding. Attackers can leverage tunneling and port forwarding techniques to bypass network defenses, establish hidden communication channels, and gain unauthorized access to internal resources, facilitating data exfiltration, lateral movement, and remote control.", + "from": "now-9m", + "index": [ + "endgame-*", + "logs-crowdstrike.fdr*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", + "auditbeat-*", + "logs-auditd_manager.auditd-*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Potential Linux Tunneling and/or Port Forwarding", + "note": "## Triage and analysis\n\n### Investigating Potential Linux Tunneling and/or Port Forwarding\n\nAttackers can leverage many utilities to clandestinely tunnel network communications and evade security measures, potentially gaining unauthorized access to sensitive systems.\n\nThis rule looks for several utilities that are capable of setting up tunnel network communications by analyzing process names or command line arguments. \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 [placeholder fields](https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html) to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run.\n\n#### Possible investigation steps\n\n- Identify any signs of suspicious network activity or anomalies that may indicate protocol tunneling. This could include unexpected traffic patterns or unusual network behavior.\n - Investigate listening ports and open sockets to look for potential protocol tunneling, reverse shells, or data exfiltration.\n - !{osquery{\"label\":\"Osquery - Retrieve Listening Ports\",\"query\":\"SELECT pid, address, port, socket, protocol, path FROM listening_ports\"}}\n - !{osquery{\"label\":\"Osquery - Retrieve Open Sockets\",\"query\":\"SELECT pid, family, remote_address, remote_port, socket, state FROM process_open_sockets\"}}\n- Identify the user account that performed the action, analyze it, and check whether it should perform this kind of action.\n - !{osquery{\"label\":\"Osquery - Retrieve Information for a Specific User\",\"query\":\"SELECT * FROM users WHERE username = {{user.name}}\"}}\n- Investigate whether the user is currently logged in and active.\n - !{osquery{\"label\":\"Osquery - Investigate the Account Authentication Status\",\"query\":\"SELECT * FROM logged_in_users WHERE user = {{user.name}}\"}}\n- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence and whether they are located in expected locations.\n - !{osquery{\"label\":\"Osquery - Retrieve Running Processes by User\",\"query\":\"SELECT pid, username, name FROM processes p JOIN users u ON u.uid = p.uid ORDER BY username\"}}\n - !{osquery{\"label\":\"Osquery - Retrieve Process Info\",\"query\":\"SELECT name, cmdline, parent, path, uid FROM processes\"}}\n- Investigate other alerts associated with the user/host during the past 48 hours.\n - If scripts or executables were dropped, retrieve the files and determine if they are malicious:\n - Use a private sandboxed malware analysis system to perform analysis.\n - Observe and collect information about the following activities:\n - Attempts to contact external domains and addresses.\n - Check if the domain is newly registered or unexpected.\n - Check the reputation of the domain or IP address.\n - File access, modification, and creation activities.\n\n### Related rules\n\n- Potential Linux Tunneling and/or Port Forwarding via Command Line - 8c8df61f-ed2a-4832-87b8-ee30812606e0\n- Potential Protocol Tunneling via Chisel Client - 3f12325a-4cc6-410b-8d4c-9fbbeb744cfd\n- Potential Protocol Tunneling via Chisel Server - ac8805f6-1e08-406c-962e-3937057fa86f\n- Potential Protocol Tunneling via EarthWorm - 9f1c4ca3-44b5-481d-ba42-32dc215a2769\n- Suspicious Utility Launched via ProxyChains - 6ace94ba-f02c-4d55-9f53-87d99b6f9af4\n- ProxyChains Activity - 4b868f1f-15ff-4ba3-8c11-d5a7a6356d37\n\n### False positive analysis\n\n- If this activity is related to new benign software installation activity, consider adding exceptions \u2014 preferably with a combination of user and command line conditions.\n- If this activity is related to a system administrator or developer who uses port tunneling/forwarding for benign purposes, consider adding exceptions for specific user accounts or hosts. \n- Try to understand the context of the execution by thinking about the user, machine, or business purpose. A small number of endpoints, such as servers with unique software, might appear unusual but satisfy a specific business need.\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, such as reverse shells, reverse proxies, or droppers, that attackers could use to reinfect the system.\n- Remove and block malicious artifacts identified during 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- 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- Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).\n", + "query": "process where host.os.type == \"linux\" and event.type == \"start\" and event.action in (\"exec\", \"exec_event\", \"start\", \"ProcessRollup2\", \"executed\", \"process_started\") and (\n (\n // gost & pivotnacci - spawned without process.parent.name\n (process.name == \"gost\" and process.args : (\"-L*\", \"-C*\", \"-R*\")) or (process.name == \"pivotnacci\")) or (\n // ssh\n (process.name == \"ssh\" and (\n (\n /* exact tunnel argument matching */\n process.args in (\"-R\", \"-L\", \"-D\", \"-w\") or\n /* single-dash token, first letter is NOT o/O, contains one of R/L/D/w/W somewhere later */\n process.args regex \"-[A-NP-Za-np-z][A-Za-z]*[RLDwW][A-Za-z]*\"\n ) and\n process.args_count >= 4 and \n not (\n process.args == \"chmod\" or process.command_line like \"*rungencmd*\"\n )\n )) or\n (process.name == \"ssh\" and process.args == \"-J\") or\n // sshuttle\n (process.name == \"sshuttle\" and process.args in (\"-r\", \"--remote\", \"-l\", \"--listen\") and process.args_count >= 4) or\n // socat\n (process.name == \"socat\" and process.args : (\"TCP4-LISTEN:*\", \"SOCKS*\") and process.args_count >= 3) or\n // chisel\n (process.name : \"chisel*\" and process.args in (\"client\", \"server\")) or\n // iodine(d), dnscat, hans, ptunnel-ng, ssf, 3proxy & ngrok \n (process.name in (\"iodine\", \"iodined\", \"dnscat\", \"hans\", \"hans-ubuntu\", \"ptunnel-ng\", \"ssf\", \"3proxy\", \"ngrok\", \"wstunnel\"))\n ) and process.parent.name in (\"bash\", \"dash\", \"ash\", \"sh\", \"tcsh\", \"csh\", \"zsh\", \"ksh\", \"fish\")\n)\n", + "references": [ + "https://blog.bitsadmin.com/living-off-the-foreign-land-windows-as-offensive-platform", + "https://book.hacktricks.xyz/generic-methodologies-and-resources/tunneling-and-port-forwarding" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "crowdstrike", + "version": "^3.0.0" + }, + { + "package": "sentinel_one_cloud_funnel", + "version": "^1.0.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.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": "6ee947e9-de7e-4281-a55d-09289bdf947e", + "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", + "Data Source: Elastic Endgame", + "Data Source: Crowdstrike", + "Data Source: SentinelOne", + "Data Source: Auditd Manager", + "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": 114 + }, + "id": "6ee947e9-de7e-4281-a55d-09289bdf947e_114", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/70fa1af4-27fd-4f26-bd03-50b6af6b9e24_107.json b/packages/security_detection_engine/kibana/security_rule/70fa1af4-27fd-4f26-bd03-50b6af6b9e24_107.json deleted file mode 100644 index 276d9d9da5a..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/70fa1af4-27fd-4f26-bd03-50b6af6b9e24_107.json +++ /dev/null @@ -1,113 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies attempts to unload the Elastic Endpoint Security kernel extension via the kextunload command.", - "from": "now-9m", - "index": [ - "logs-endpoint.events.*" - ], - "language": "kuery", - "license": "Elastic License v2", - "name": "Attempt to Unload Elastic Endpoint Security Kernel Extension", - "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 Attempt to Unload Elastic Endpoint Security Kernel Extension\n\nElastic Endpoint Security's kernel extension is crucial for monitoring and protecting macOS systems by intercepting and analyzing system-level events. Adversaries may attempt to unload this extension using the `kextunload` command to evade detection and impair defenses. The detection rule identifies such attempts by monitoring process events related to the `kextunload` command targeting the security extension, flagging potential defense evasion activities.\n\n### Possible investigation steps\n\n- Review the process event details to confirm the presence of the `kextunload` command targeting \"EndpointSecurity.kext\" in the process arguments.\n- Identify the user account associated with the process event to determine if the action was initiated by an authorized or suspicious user.\n- Check the host's recent activity logs for any other unusual or unauthorized actions that might indicate a broader attack or compromise.\n- Investigate the source of the command execution by examining the parent process and any related processes to understand how the `kextunload` command was initiated.\n- Assess the system for any signs of tampering or additional indicators of compromise, such as unauthorized file modifications or unexpected network connections.\n- Correlate this event with other alerts or logs from the same host or user to identify potential patterns or coordinated activities.\n\n### False positive analysis\n\n- System administrators performing routine maintenance may trigger the rule when testing or updating kernel extensions. To manage this, create exceptions for known maintenance activities by whitelisting specific user accounts or processes during scheduled maintenance windows.\n- Legitimate software updates or installations that require unloading the kernel extension might be flagged. To handle this, monitor and document regular update schedules and create exceptions for these activities, ensuring they align with expected update patterns.\n- Security testing or audits conducted by authorized personnel could also trigger the rule. Implement a process to temporarily disable the rule or whitelist specific testing tools and accounts during these audits to prevent false positives.\n- Development environments where kernel extensions are frequently loaded and unloaded for testing purposes may generate alerts. Consider setting up a separate monitoring profile for development systems with adjusted thresholds or exceptions to accommodate these activities.\n\n### Response and remediation\n\n- Immediately isolate the affected macOS system from the network to prevent further unauthorized actions or potential lateral movement by the adversary.\n- Terminate any unauthorized processes related to the `kextunload` command to stop the attempt to unload the Elastic Endpoint Security kernel extension.\n- Conduct a thorough review of system logs and process execution history to identify any additional suspicious activities or indicators of compromise associated with the adversary's attempt.\n- Restore the Elastic Endpoint Security kernel extension if it was successfully unloaded, ensuring that the system's protective measures are fully operational.\n- Update and patch the macOS system and all security software to the latest versions to mitigate any known vulnerabilities that could be exploited by adversaries.\n- Implement additional monitoring and alerting for any future attempts to execute the `kextunload` command, particularly targeting security-related kernel extensions.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if broader organizational defenses need to be adjusted.", - "query": "event.category:process and host.os.type:macos and event.type:(start or process_started) and\n process.name:kextunload and process.args:(\"/System/Library/Extensions/EndpointSecurity.kext\" or \"EndpointSecurity.kext\")\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": "70fa1af4-27fd-4f26-bd03-50b6af6b9e24", - "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 macOS 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, for MacOS it is recommended to select \"Traditional Endpoints\".\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/current/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: 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/" - } - ] - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0003", - "name": "Persistence", - "reference": "https://attack.mitre.org/tactics/TA0003/" - }, - "technique": [ - { - "id": "T1547", - "name": "Boot or Logon Autostart Execution", - "reference": "https://attack.mitre.org/techniques/T1547/", - "subtechnique": [ - { - "id": "T1547.006", - "name": "Kernel Modules and Extensions", - "reference": "https://attack.mitre.org/techniques/T1547/006/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "query", - "version": 107 - }, - "id": "70fa1af4-27fd-4f26-bd03-50b6af6b9e24_107", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/7164081a-3930-11ed-a261-0242ac120002_7.json b/packages/security_detection_engine/kibana/security_rule/7164081a-3930-11ed-a261-0242ac120002_7.json deleted file mode 100644 index 4693e1544fd..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/7164081a-3930-11ed-a261-0242ac120002_7.json +++ /dev/null @@ -1,110 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "This rule detects a container deployed with one or more dangerously permissive Linux capabilities. An attacker with the ability to deploy a container with added capabilities could use this for further execution, lateral movement, or privilege escalation within a cluster. The capabilities detected in this rule have been used in container escapes to the host machine.", - "false_positives": [ - "Some container images require the addition of privileged capabilities. This rule leaves space for the exception of trusted container images. To add an exception, add the trusted container image name to the query field, kubernetes.audit.requestObject.spec.containers.image." - ], - "index": [ - "logs-kubernetes.*" - ], - "language": "kuery", - "license": "Elastic License v2", - "name": "Kubernetes Container Created with Excessive Linux Capabilities", - "note": "## Triage and analysis\n\n### Investigating Kubernetes Container Created with Excessive Linux Capabilities\n\nLinux capabilities were designed to divide root privileges into smaller units. Each capability grants a thread just enough power to perform specific privileged tasks. In Kubernetes, containers are given a set of default capabilities that can be dropped or added to at the time of creation. Added capabilities entitle containers in a pod with additional privileges that can be used to change\ncore processes, change network settings of a cluster, or directly access the underlying host. The following have been used in container escape techniques:\n\nBPF - Allow creating BPF maps, loading BPF Type Format (BTF) data, retrieve JITed code of BPF programs, and more.\nDAC_READ_SEARCH - Bypass file read permission checks and directory read and execute permission checks.\nNET_ADMIN - Perform various network-related operations.\nSYS_ADMIN - Perform a range of system administration operations.\nSYS_BOOT - Use reboot(2) and kexec_load(2), reboot and load a new kernel for later execution.\nSYS_MODULE - Load and unload kernel modules.\nSYS_PTRACE - Trace arbitrary processes using ptrace(2).\nSYS_RAWIO - Perform I/O port operations (iopl(2) and ioperm(2)).\nSYSLOG - Perform privileged syslog(2) operations.\n\n### False positive analysis\n\n- While these capabilities are not included by default in containers, some legitimate images may need to add them. This rule leaves space for the exception of trusted container images. To add an exception, add the trusted container image name to the query field, kubernetes.audit.requestObject.spec.containers.image.", - "query": "event.dataset: kubernetes.audit_logs\n and kubernetes.audit.annotations.authorization_k8s_io/decision:\"allow\"\n and kubernetes.audit.verb: create\n and kubernetes.audit.objectRef.resource: pods\n and kubernetes.audit.requestObject.spec.containers.securityContext.capabilities.add: (\"BPF\" or \"DAC_READ_SEARCH\" or \"NET_ADMIN\" or \"SYS_ADMIN\" or \"SYS_BOOT\" or \"SYS_MODULE\" or \"SYS_PTRACE\" or \"SYS_RAWIO\" or \"SYSLOG\")\n and not kubernetes.audit.requestObject.spec.containers.image : (\"docker.elastic.co/beats/elastic-agent:8.4.0\" or \"rancher/klipper-lb:v0.3.5\" or \"\")\n", - "references": [ - "https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-capabilities-for-a-container", - "https://0xn3va.gitbook.io/cheat-sheets/container/escaping/excessive-capabilities", - "https://man7.org/linux/man-pages/man7/capabilities.7.html", - "https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities" - ], - "related_integrations": [ - { - "package": "kubernetes", - "version": "^1.80.0" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "event.dataset", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.annotations.authorization_k8s_io/decision", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.objectRef.resource", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.requestObject.spec.containers.image", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.requestObject.spec.containers.securityContext.capabilities.add", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.verb", - "type": "keyword" - } - ], - "risk_score": 47, - "rule_id": "7164081a-3930-11ed-a261-0242ac120002", - "setup": "The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule.", - "severity": "medium", - "tags": [ - "Data Source: Kubernetes", - "Tactic: Execution", - "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": "T1611", - "name": "Escape to Host", - "reference": "https://attack.mitre.org/techniques/T1611/" - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0002", - "name": "Execution", - "reference": "https://attack.mitre.org/tactics/TA0002/" - }, - "technique": [ - { - "id": "T1610", - "name": "Deploy Container", - "reference": "https://attack.mitre.org/techniques/T1610/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "query", - "version": 7 - }, - "id": "7164081a-3930-11ed-a261-0242ac120002_7", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/721999d0-7ab2-44bf-b328-6e63367b9b29_209.json b/packages/security_detection_engine/kibana/security_rule/721999d0-7ab2-44bf-b328-6e63367b9b29_209.json deleted file mode 100644 index 9ae2ff93255..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/721999d0-7ab2-44bf-b328-6e63367b9b29_209.json +++ /dev/null @@ -1,91 +0,0 @@ -{ - "attributes": { - "author": [ - "Austin Songer" - ], - "description": "Identifies when Microsoft Cloud App Security reports that a user has uploaded files to the cloud that might be infected with ransomware.", - "false_positives": [ - "If Cloud App Security identifies, for example, a high rate of file uploads or file deletion activities it may represent an adverse encryption process." - ], - "from": "now-30m", - "index": [ - "filebeat-*", - "logs-o365*" - ], - "language": "kuery", - "license": "Elastic License v2", - "name": "Microsoft 365 Potential ransomware 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 Microsoft 365 Potential ransomware activity\n\nMicrosoft 365's cloud services can be exploited by adversaries to distribute ransomware by uploading infected files. This detection rule leverages Microsoft Cloud App Security to identify suspicious uploads, focusing on successful events flagged as potential ransomware activity. By monitoring specific event datasets and actions, it helps security analysts pinpoint and mitigate ransomware threats, aligning with MITRE ATT&CK's impact tactics.\n\n### Possible investigation steps\n\n- Review the event details in the Microsoft Cloud App Security console to confirm the specific files and user involved in the \"Potential ransomware activity\" alert.\n- Check the event.dataset field for o365.audit logs to gather additional context about the user's recent activities and any other related events.\n- Investigate the event.provider field to ensure the alert originated from the SecurityComplianceCenter, confirming the source of the detection.\n- Analyze the event.category field to verify that the activity is categorized as web, which may indicate the method of file upload.\n- Assess the user's recent activity history and permissions to determine if the upload was intentional or potentially malicious.\n- Contact the user to verify the legitimacy of the uploaded files and gather any additional context or explanations for the activity.\n- If the files are confirmed or suspected to be malicious, initiate a response plan to contain and remediate any potential ransomware threat, including isolating affected systems and notifying relevant stakeholders.\n\n### False positive analysis\n\n- Legitimate file uploads by trusted users may trigger alerts if the files are mistakenly flagged as ransomware. To manage this, create exceptions for specific users or groups who frequently upload large volumes of files.\n- Automated backup processes that upload encrypted files to the cloud can be misidentified as ransomware activity. Exclude these processes by identifying and whitelisting the associated service accounts or IP addresses.\n- Certain file types or extensions commonly used in business operations might be flagged. Review and adjust the detection rule to exclude these file types if they are consistently identified as false positives.\n- Collaborative tools that sync files across devices may cause multiple uploads that appear suspicious. Monitor and exclude these tools by recognizing their typical behavior patterns and adjusting the rule settings accordingly.\n- Regularly review and update the list of exceptions to ensure that only verified non-threatening activities are excluded, maintaining the balance between security and operational efficiency.\n\n### Response and remediation\n\n- Immediately isolate the affected user account to prevent further uploads and potential spread of ransomware within the cloud environment.\n- Quarantine the uploaded files flagged as potential ransomware to prevent access and further distribution.\n- Conduct a thorough scan of the affected user's devices and cloud storage for additional signs of ransomware or other malicious activity.\n- Notify the security operations team to initiate a deeper investigation into the source and scope of the ransomware activity, leveraging MITRE ATT&CK techniques for guidance.\n- Restore any affected files from secure backups, ensuring that the backups are clean and free from ransomware.\n- Review and update access controls and permissions for the affected user and related accounts to minimize the risk of future incidents.\n- Escalate the incident to senior security management and, if necessary, involve legal or compliance teams to assess any regulatory implications.", - "query": "event.dataset:o365.audit and event.provider:SecurityComplianceCenter and event.category:web and event.action:\"Potential ransomware activity\" and event.outcome:success\n", - "references": [ - "https://docs.microsoft.com/en-us/cloud-app-security/anomaly-detection-policy", - "https://docs.microsoft.com/en-us/cloud-app-security/policy-template-reference" - ], - "related_integrations": [ - { - "package": "o365", - "version": "^2.0.0" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "event.action", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.category", - "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": "721999d0-7ab2-44bf-b328-6e63367b9b29", - "setup": "The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.", - "severity": "medium", - "tags": [ - "Domain: Cloud", - "Data Source: Microsoft 365", - "Use Case: Configuration Audit", - "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": "query", - "version": 209 - }, - "id": "721999d0-7ab2-44bf-b328-6e63367b9b29_209", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/721999d0-7ab2-44bf-b328-6e63367b9b29_213.json b/packages/security_detection_engine/kibana/security_rule/721999d0-7ab2-44bf-b328-6e63367b9b29_213.json new file mode 100644 index 00000000000..92f0fe67fe5 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/721999d0-7ab2-44bf-b328-6e63367b9b29_213.json @@ -0,0 +1,94 @@ +{ + "attributes": { + "author": [ + "Elastic", + "Austin Songer" + ], + "description": "Identifies when Microsoft Cloud App Security flags potential ransomware activity in Microsoft 365. This rule detects events where the Security Compliance Center reports a \"Ransomware activity\" or \"Potential ransomware activity\" alert, which may indicate file encryption, mass file modifications, or uploads of ransomware-infected files to cloud services such as SharePoint or OneDrive.", + "false_positives": [ + "If Cloud App Security identifies, for example, a high rate of file uploads or file deletion activities it may represent an adverse encryption process." + ], + "from": "now-9m", + "index": [ + "logs-o365.audit-*", + "filebeat-*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "Deprecated - M365 Security Compliance Potential Ransomware Activity", + "note": "## Triage and analysis\n\n### Investigating Deprecated - M365 Security Compliance Potential Ransomware Activity\n\nMicrosoft 365's cloud services can be exploited by adversaries to distribute ransomware by uploading infected files. This detection rule leverages Microsoft Cloud App Security to identify suspicious uploads, focusing on successful events flagged as potential ransomware activity. By monitoring specific event datasets and actions, it helps security analysts pinpoint and mitigate ransomware threats, aligning with MITRE ATT&CK's impact tactics.\n\n### Possible investigation steps\n\n- Identify the affected user account and review their recent file activity in Microsoft 365 for signs of mass file encryption, renaming with unusual extensions, or rapid file modifications.\n- Examine the file names, extensions, and metadata of the flagged uploads to determine if they match known ransomware patterns (e.g., `.encrypted`, `.locked`, or ransom note files like `README.txt` or `DECRYPT_INSTRUCTIONS.html`).\n- Correlate this alert with other security events from the same user or source IP, such as impossible travel, failed login attempts, or suspicious inbox rules, to identify potential account compromise.\n- Check whether the affected user's endpoint shows signs of ransomware execution, such as high CPU usage, mass file system changes, or known ransomware process names.\n- Review SharePoint or OneDrive file version history to determine the scope of encrypted or modified files and whether recovery via version rollback is possible.\n- Contact the user to verify whether the activity is legitimate or if their account or device may have been compromised.\n\n### False positive analysis\n\n- Legitimate file uploads by trusted users may trigger alerts if the files are mistakenly flagged as ransomware. To manage this, create exceptions for specific users or groups who frequently upload large volumes of files.\n- Automated backup processes that upload encrypted files to the cloud can be misidentified as ransomware activity. Exclude these processes by identifying and whitelisting the associated service accounts or IP addresses.\n- Certain file types or extensions commonly used in business operations might be flagged. Review and adjust the detection rule to exclude these file types if they are consistently identified as false positives.\n- Collaborative tools that sync files across devices may cause multiple uploads that appear suspicious. Monitor and exclude these tools by recognizing their typical behavior patterns and adjusting the rule settings accordingly.\n\n### Response and remediation\n\n- Immediately isolate the affected user account to prevent further uploads and potential spread of ransomware within the cloud environment.\n- Quarantine the uploaded files flagged as potential ransomware to prevent access and further distribution.\n- Conduct a thorough scan of the affected user's devices and cloud storage for additional signs of ransomware or other malicious activity.\n- Notify the security operations team to initiate a deeper investigation into the source and scope of the ransomware activity.\n- Restore any affected files from secure backups, ensuring that the backups are clean and free from ransomware.\n- Review and update access controls and permissions for the affected user and related accounts to minimize the risk of future incidents.\n- Escalate the incident to senior security management and, if necessary, involve legal or compliance teams to assess any regulatory implications.\n", + "query": "event.dataset:o365.audit and\n event.provider:SecurityComplianceCenter and\n event.category:web and\n rule.name:(\"Ransomware activity\" or \"Potential ransomware activity\") and\n event.outcome:success\n", + "references": [ + "https://docs.microsoft.com/en-us/cloud-app-security/anomaly-detection-policy", + "https://docs.microsoft.com/en-us/cloud-app-security/policy-template-reference", + "https://www.microsoft.com/en-us/security/blog/threat-intelligence/ransomware/" + ], + "related_integrations": [ + { + "package": "o365", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.category", + "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": "rule.name", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "721999d0-7ab2-44bf-b328-6e63367b9b29", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Domain: SaaS", + "Data Source: Microsoft 365", + "Data Source: Microsoft 365 Audit 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": "T1486", + "name": "Data Encrypted for Impact", + "reference": "https://attack.mitre.org/techniques/T1486/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 213 + }, + "id": "721999d0-7ab2-44bf-b328-6e63367b9b29_213", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/737b5532-cf2e-4d40-9209-d7aec9dd25d5_1.json b/packages/security_detection_engine/kibana/security_rule/737b5532-cf2e-4d40-9209-d7aec9dd25d5_1.json new file mode 100644 index 00000000000..a826fdb22af --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/737b5532-cf2e-4d40-9209-d7aec9dd25d5_1.json @@ -0,0 +1,153 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies PowerShell script blocks with high entropy and non-uniform character distributions. Attackers may obfuscate PowerShell scripts using encoding, encryption, or compression techniques to evade signature-based detections and hinder manual analysis by security analysts.", + "false_positives": [ + "Legitimate large or encoded PowerShell scripts (automation frameworks, installers, or admin tooling) can exhibit high entropy or uneven character distributions." + ], + "filters": [ + { + "meta": { + "negate": true + }, + "query": { + "wildcard": { + "file.path": { + "case_insensitive": true, + "value": "?:\\\\ProgramData\\\\Microsoft\\\\Windows Defender Advanced Threat Protection\\\\DataCollection\\\\*" + } + } + } + } + ], + "from": "now-9m", + "index": [ + "logs-windows.powershell*" + ], + "investigation_fields": { + "field_names": [ + "@timestamp", + "host.name", + "host.id", + "user.name", + "user.id", + "powershell.file.script_block_text", + "powershell.file.script_block_id", + "powershell.file.script_block_entropy_bits", + "powershell.file.script_block_surprisal_stdev", + "powershell.file.script_block_unique_symbols", + "powershell.file.script_block_length", + "file.path", + "file.directory", + "file.name", + "process.pid" + ] + }, + "language": "kuery", + "license": "Elastic License v2", + "name": "Potential PowerShell Obfuscated Script via High Entropy", + "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 Obfuscated Script via High Entropy\n\nThis alert flags a large PowerShell script block with statistical characteristics consistent with obfuscated content (for example, encoded, compressed, or encrypted data embedded in a script). Triage should focus on establishing execution context (who/where), reconstructing the complete script content, identifying whether the high-entropy data is a benign embedded resource or a staged payload, and scoping for related activity.\n\n#### Key alert fields to review\n\n- `user.name`, `user.domain`, `user.id`: Account execution context for correlation, prioritization, and scoping.\n- `host.name`, `host.id`: Host execution context for correlation, prioritization, and scoping.\n- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file.\n- `powershell.file.script_block_text`: Script block content that matched the detection logic.\n- `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`: Script block metadata to pivot to other fragments or reconstruct full script content when split across multiple events.\n- `powershell.file.script_block_entropy_bits`: Shannon entropy of the script block. Higher values may indicate obfuscation.\n- `powershell.file.script_block_surprisal_stdev`: Standard deviation of surprisal across the script block. Low values indicate uniform randomness. High values indicate mixed patterns and variability.\n- `powershell.file.script_block_unique_symbols`: Count of distinct characters present in the script block.\n- `powershell.file.script_block_length`: Script block length (size) context.\n\n#### Possible investigation steps\n\n- Triage the execution context and initial severity:\n - Review `@timestamp` to identify when the script block executed and align pivots to the same timeframe.\n - Review `host.name` and `host.id` to identify the endpoint and validate whether PowerShell use is expected for its role.\n - Review `user.name`, `user.domain`, and `user.id` to determine whether the account is expected to run PowerShell on this host and whether it is privileged, shared, or an automation/service identity.\n - Review `powershell.file.script_block_length`, `powershell.file.script_block_entropy_bits`, and `powershell.file.script_block_surprisal_stdev` to understand whether the alert is driven by a large embedded blob (often staging) or more mixed script content (often a wrapper/loader plus embedded data).\n\n- Determine script provenance (file-backed vs. dynamic/interactive):\n - If `file.path` is present, review `file.directory` and `file.name` to understand where the script originated.\n - Assess whether `file.directory` is consistent with approved administrative tooling locations for this host and user, or whether it appears user-writable, temporary, or otherwise unusual.\n - If `file.path` is absent, treat the script block as potentially interactive or dynamically generated and prioritize reconstructing the full script content and identifying the launch source via process correlation.\n\n- Reconstruct the full script content when fragmented:\n - Pivot on `powershell.file.script_block_id` to collect all fragments associated with the script block.\n - Order fragments using `powershell.sequence` and validate completeness using `powershell.total`.\n - Analyze the reconstructed content as a whole to avoid missing small loader logic that precedes a large encoded/encrypted payload.\n\n- Perform structured content review of `powershell.file.script_block_text`:\n - Identify large contiguous strings, byte arrays, or character arrays that may represent encoded or packed data; use `powershell.file.script_block_unique_symbols` to help distinguish limited-alphabet encodings from broader character sets.\n - Look for transformation and staging patterns (for example, decode/decrypt/decompress routines) and whether transformed content is immediately executed (for example, dynamic invocation, in-memory loading, or secondary script evaluation).\n - Extract any embedded indicators (domains, URLs, IPs, file paths/names, registry paths, scheduled task/service names, or distinctive strings) and retain them for scoping and containment.\n\n- Establish the execution chain and initiating source:\n - Use `process.pid` with `host.id` and `@timestamp` to pivot to process telemetry for the PowerShell host instance that generated the script block.\n - Identify the parent process and initiating mechanism (interactive shell, scheduled execution, remote management, document/script host, or other launcher). Treat unexpected launch sources or unusual timing for the host role as higher risk.\n - Check whether the same `process.pid` generated additional suspicious script blocks around the alert time, and whether `user.id` and `host.id` align with expected administrative behavior.\n\n- Correlate for follow-on activity on the same host and account:\n - Correlate on `host.id` and `@timestamp` to identify adjacent events that indicate impact (outbound connections, file writes, module downloads, persistence changes, or unusual authentication activity).\n - When `file.path` is present, correlate on that path and timeframe for file creation/modification patterns that may indicate initial staging or subsequent cleanup.\n\n- Scope the activity across the environment:\n - Search for other high-entropy script blocks on the same `host.id` and `user.id` before and after the alert to identify repeated execution or iterative staging.\n - Search across hosts for the same `file.name` and `file.path` (when present) and compare `powershell.file.script_block_text` structure to identify reuse.\n - Use distinctive substrings from `powershell.file.script_block_text` as pivots to find related script blocks even when paths or accounts differ.\n\n### False positive analysis\n\n- Benign scripts can trigger this alert when they legitimately embed packed data (for example, compressed resources, serialized configuration blobs, embedded certificates/keys, or packaged modules) that increase entropy and appear non-uniform.\n- Indicators supporting a benign determination:\n - `file.path` and `file.name` consistently map to an approved internal tool or vendor-managed automation across multiple hosts.\n - `user.id` represents an expected administrative or automation identity with predictable host targeting and execution timing.\n - Reconstructed `powershell.file.script_block_text` shows a stable, repeatable structure over time, and any decoded content aligns with known operational functionality rather than staging and immediate secondary execution.\n- Indicators supporting suspicion:\n - Unusual `file.directory` for the host role or account, or absence of `file.path` combined with evidence of dynamic staging behavior.\n - Reconstructed content includes clear execution of transformed data, in-memory loading patterns, or embedded external destinations not associated with known tooling.\n- If determined benign, document the owning tool/team, expected `user.id` usage, and expected `file.path`/`file.name` (when present). Use those stable attributes for future baselining and noise reduction while preserving detection for new paths, new users, or materially different script structures.\n\n### Response and remediation\n\n- If suspicious or malicious activity is confirmed:\n - Contain the affected host to prevent further execution and lateral movement.\n - Preserve relevant evidence from the alert, including full reconstructed script content (via `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`), and associated context (`@timestamp`, `host.*`, `user.*`, `file.*`, `process.pid`, and entropy metrics).\n - Use extracted indicators from `powershell.file.script_block_text` to hunt across hosts and accounts, and to identify additional affected systems.\n - Investigate and remediate follow-on activity identified during correlation (downloaded payloads, dropped files, persistence mechanisms, or unauthorized network access) and remove malicious artifacts from affected endpoints.\n - If account compromise is suspected for `user.id` / `user.name`, initiate credential reset and review recent authentication activity and access paths associated with that identity.\n\n- If benign activity is confirmed:\n - Record the justification and expected behavior (who runs it, where it runs, and expected `file.path` when present).\n - Monitor for deviations from the established baseline, including new `user.id`, new `host.id`, new `file.path`, or significant changes in `powershell.file.script_block_text` structure or entropy characteristics.\n", + "query": "event.category:process and host.os.type:windows and powershell.file.script_block_length > 1000 and\n powershell.file.script_block_entropy_bits >= 5.3 and powershell.file.script_block_surprisal_stdev > 0.7 and\n not file.directory: \"C:\\Program Files (x86)\\Microsoft Intune Management Extension\\Content\\DetectionScripts\"\n", + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.category", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.directory", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_entropy_bits", + "type": "unknown" + }, + { + "ecs": false, + "name": "powershell.file.script_block_length", + "type": "unknown" + }, + { + "ecs": false, + "name": "powershell.file.script_block_surprisal_stdev", + "type": "unknown" + } + ], + "risk_score": 21, + "rule_id": "737b5532-cf2e-4d40-9209-d7aec9dd25d5", + "setup": "## Setup\n\nPowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104).\nSetup instructions: https://ela.st/powershell-logging-setup\n\nThis rule uses the following fields that require the Windows Integration v3.3.0 and up: `powershell.file.script_block_entropy_bits`, `powershell.file.script_block_surprisal_stdev`, and `powershell.file.script_block_length`.\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": "query", + "version": 1 + }, + "id": "737b5532-cf2e-4d40-9209-d7aec9dd25d5_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/764c8437-a581-4537-8060-1fdb0e92c92d_206.json b/packages/security_detection_engine/kibana/security_rule/764c8437-a581-4537-8060-1fdb0e92c92d_206.json deleted file mode 100644 index 0c399b80ae4..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/764c8437-a581-4537-8060-1fdb0e92c92d_206.json +++ /dev/null @@ -1,109 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "This rule detects an attempt to create or modify a pod using the host IPC namespace. This gives access to data used by any pod that also use the hosts IPC namespace. If any process on the host or any processes in a pod uses the hosts inter-process communication mechanisms (shared memory, semaphore arrays, message queues, etc.), an attacker can read/write to those same mechanisms. They may look for files in /dev/shm or use ipcs to check for any IPC facilities being used.", - "false_positives": [ - "An administrator or developer may want to use a pod that runs as root and shares the host's IPC, Network, and PID namespaces for debugging purposes. If something is going wrong in the cluster and there is no easy way to SSH onto the host nodes directly, a privileged pod of this nature can be useful for viewing things like iptable rules and network namespaces from the host's perspective. Add exceptions for trusted container images using the query field \"kubernetes.audit.requestObject.spec.container.image\"" - ], - "index": [ - "logs-kubernetes.*" - ], - "language": "kuery", - "license": "Elastic License v2", - "name": "Kubernetes Pod Created With HostIPC", - "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 Kubernetes Pod Created With HostIPC\n\nKubernetes allows pods to share the host's IPC namespace, enabling inter-process communication. While useful for legitimate applications, adversaries can exploit this to access shared memory and IPC mechanisms, potentially leading to data exposure or privilege escalation. The detection rule identifies suspicious pod creation or modification events that enable host IPC, excluding known benign images, to flag potential security threats.\n\n### Possible investigation steps\n\n- Review the Kubernetes audit logs to identify the specific pod creation or modification event that triggered the alert, focusing on the event.dataset field with the value \"kubernetes.audit_logs\".\n- Examine the kubernetes.audit.annotations.authorization_k8s_io/decision field to confirm that the action was allowed, and verify the identity of the user or service account that initiated the request.\n- Investigate the kubernetes.audit.objectRef.resource field to ensure the resource involved is indeed a pod, and check the kubernetes.audit.verb field to determine if the action was a create, update, or patch operation.\n- Analyze the kubernetes.audit.requestObject.spec.hostIPC field to confirm that host IPC was enabled, and cross-reference with the kubernetes.audit.requestObject.spec.containers.image field to ensure the image is not part of the known benign list.\n- Check for any other pods or processes on the host that might be using the host's IPC namespace, and assess if there is any unauthorized access or data exposure risk.\n- Look for any suspicious activity or anomalies in the /dev/shm directory or use the ipcs command to identify any IPC facilities that might be exploited.\n\n### False positive analysis\n\n- Pods using hostIPC for legitimate inter-process communication may trigger alerts. Review the pod's purpose and verify if hostIPC is necessary for its function.\n- Known benign images, such as monitoring or logging agents, might use hostIPC. Update the exclusion list to include these images if they are verified as non-threatening.\n- Development or testing environments often use hostIPC for debugging purposes. Consider excluding these environments from the rule or creating a separate rule with a higher threshold for alerts.\n- Automated deployment tools might temporarily use hostIPC during setup. Ensure these tools are recognized and excluded if they are part of a controlled and secure process.\n- Regularly review and update the exclusion list to reflect changes in your environment, ensuring that only verified and necessary uses of hostIPC are excluded.\n\n### Response and remediation\n\n- Immediately isolate the affected pod to prevent further access to the host's IPC namespace. This can be done by cordoning the node or deleting the pod if necessary.\n- Review and revoke any unnecessary permissions or roles that allowed the pod to be created or modified with hostIPC enabled. Ensure that only trusted entities have the capability to modify pod specifications.\n- Conduct a thorough audit of other pods and configurations in the cluster to identify any additional instances where hostIPC is enabled without a valid justification.\n- Implement network policies to restrict communication between pods and the host, limiting the potential impact of any unauthorized access to the host's IPC mechanisms.\n- Escalate the incident to the security operations team for further investigation and to determine if any data exposure or privilege escalation occurred.\n- Update security policies and configurations to prevent the use of hostIPC in future pod deployments unless explicitly required and approved.\n- Enhance monitoring and alerting to detect similar attempts in the future, ensuring that any unauthorized use of hostIPC is promptly flagged and addressed.", - "query": "event.dataset : \"kubernetes.audit_logs\"\n and kubernetes.audit.annotations.authorization_k8s_io/decision:\"allow\"\n and kubernetes.audit.objectRef.resource:\"pods\"\n and kubernetes.audit.verb:(\"create\" or \"update\" or \"patch\")\n and kubernetes.audit.requestObject.spec.hostIPC:true\n and not kubernetes.audit.requestObject.spec.containers.image: (\"docker.elastic.co/beats/elastic-agent:8.4.0\")\n", - "references": [ - "https://research.nccgroup.com/2021/11/10/detection-engineering-for-kubernetes-clusters/#part3-kubernetes-detections", - "https://kubernetes.io/docs/concepts/security/pod-security-policy/#host-namespaces", - "https://bishopfox.com/blog/kubernetes-pod-privilege-escalation" - ], - "related_integrations": [ - { - "package": "kubernetes", - "version": "^1.80.0" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "event.dataset", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.annotations.authorization_k8s_io/decision", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.objectRef.resource", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.requestObject.spec.containers.image", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.requestObject.spec.hostIPC", - "type": "boolean" - }, - { - "ecs": false, - "name": "kubernetes.audit.verb", - "type": "keyword" - } - ], - "risk_score": 47, - "rule_id": "764c8437-a581-4537-8060-1fdb0e92c92d", - "setup": "The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule.", - "severity": "medium", - "tags": [ - "Data Source: Kubernetes", - "Tactic: Execution", - "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": "T1611", - "name": "Escape to Host", - "reference": "https://attack.mitre.org/techniques/T1611/" - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0002", - "name": "Execution", - "reference": "https://attack.mitre.org/tactics/TA0002/" - }, - "technique": [ - { - "id": "T1610", - "name": "Deploy Container", - "reference": "https://attack.mitre.org/techniques/T1610/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "query", - "version": 206 - }, - "id": "764c8437-a581-4537-8060-1fdb0e92c92d_206", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/7d02c440-52a8-4854-ad3f-71af7fbb4fc6_2.json b/packages/security_detection_engine/kibana/security_rule/7d02c440-52a8-4854-ad3f-71af7fbb4fc6_2.json new file mode 100644 index 00000000000..a6ecde5c6a7 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/7d02c440-52a8-4854-ad3f-71af7fbb4fc6_2.json @@ -0,0 +1,105 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule uses alert data to determine when multiple alerts from different integrations with unique event categories and involving the same source.ip are triggered. Analysts can use this to prioritize triage and response, as these IP addresses are more likely to be related to a compromise.", + "from": "now-60m", + "interval": "30m", + "language": "esql", + "license": "Elastic License v2", + "name": "Alerts From Multiple Integrations by Source Address", + "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 From Multiple Integrations by Source Address\n\nThe detection rule uses alert data to determine when multiple alerts from different integrations involving the same source.ip are triggered.\n\n### Possible investigation steps\n\n- Review the alert details to identify the specific host involved and the different modules and rules that triggered the alert.\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.*\n\n// any alerts excluding low severity and the noisy ones\n| where kibana.alert.rule.name is not null and source.ip is not null and kibana.alert.risk_score > 21 and\n not kibana.alert.rule.type in (\"threat_match\", \"machine_learning\") and\n not KQL(\"\"\"kibana.alert.rule.tags : \"Rule Type: Higher-Order Rule\" \"\"\")\n\n// group alerts by source.ip and extract values of interest for alert triage\n| stats Esql.event_module_distinct_count = COUNT_DISTINCT(event.module),\n Esql.rule_name_distinct_count = COUNT_DISTINCT(kibana.alert.rule.name),\n Esql.event_category_distinct_count = COUNT_DISTINCT(event.category),\n Esql.rule_risk_score_distinct_count = COUNT_DISTINCT(kibana.alert.risk_score),\n Esql.event_module_values = VALUES(event.module),\n Esql.rule_name_values = VALUES(kibana.alert.rule.name),\n Esql.message_values = VALUES(message),\n Esql.event_category_values = VALUES(event.category),\n Esql.event_action_values = VALUES(event.action),\n Esql.destination_ip_values = VALUES(destination.ip),\n Esql.host_id_values = VALUES(host.id),\n Esql.agent_id_values = VALUES(agent.id),\n Esql.user_name_values = VALUES(user.name),\n Esql.rule_severity_values = VALUES(kibana.alert.risk_score) by source.ip\n\n// filter for alerts from same source.ip reported by different integrations with unique categories and with different severity levels\n| where Esql.event_module_distinct_count >= 2 and Esql.event_category_distinct_count >= 2 and (Esql.rule_risk_score_distinct_count >= 2 or Esql.rule_severity_values == 73 or Esql.rule_severity_values == 99)\n| keep source.ip, Esql.*\n", + "required_fields": [ + { + "ecs": false, + "name": "Esql.agent_id_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.destination_ip_values", + "type": "ip" + }, + { + "ecs": false, + "name": "Esql.event_action_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.event_category_distinct_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.event_category_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.event_module_distinct_count", + "type": "long" + }, + { + "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_distinct_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.rule_name_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.rule_risk_score_distinct_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.rule_severity_values", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.user_name_values", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.ip", + "type": "ip" + } + ], + "risk_score": 73, + "rule_id": "7d02c440-52a8-4854-ad3f-71af7fbb4fc6", + "severity": "high", + "tags": [ + "Use Case: Threat Detection", + "Rule Type: Higher-Order Rule", + "Resources: Investigation Guide" + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 2 + }, + "id": "7d02c440-52a8-4854-ad3f-71af7fbb4fc6_2", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/7f3521dd-fb80-4548-a7eb-8db37b898dc2_1.json b/packages/security_detection_engine/kibana/security_rule/7f3521dd-fb80-4548-a7eb-8db37b898dc2_1.json new file mode 100644 index 00000000000..5bce46c1d4c --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/7f3521dd-fb80-4548-a7eb-8db37b898dc2_1.json @@ -0,0 +1,101 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies a process started by Notepad after opening a Markdown file. This may indicate successful exploitation of a Notepad markdown parsing vulnerability (CVE-2026-20841) that can lead to arbitrary code execution.", + "from": "now-9m", + "index": [ + "endgame-*", + "logs-endpoint.events.process-*", + "logs-m365_defender.event-*", + "logs-sentinel_one_cloud_funnel.*", + "logs-windows.sysmon_operational-*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Potential Notepad Markdown RCE Exploitation", + "note": "## Triage and analysis\n\n### Investigating Potential Notepad Markdown RCE Exploitation\n\nThis rule detects a new child process launched by `notepad.exe` when Notepad was opened with a Markdown (`.md`) file.\nThis behavior can indicate exploitation of a Notepad remote code execution vulnerability where crafted Markdown content\ntriggers unintended process execution.\n\n### Possible investigation steps\n\n- Validate the parent-child relationship and confirm `notepad.exe` is the direct parent of the suspicious process.\n- Review the full command line of both parent and child processes, including the Markdown file path in `process.parent.args`.\n- Identify the Markdown file source (email attachment, browser download, chat client, removable media, or network share).\n- Inspect process ancestry and descendants for additional payload execution, script interpreters, or LOLBIN activity.\n- Correlate with file, registry, and network events around the same timestamp to identify follow-on behavior.\n- Determine whether the child process and its execution path are expected in your environment.\n\n### False positive analysis\n\n- Legitimate automation or editor extensions may occasionally spawn helper processes from Notepad workflows.\n- User-driven workflows that invoke external tools from Markdown previews can trigger this behavior.\n- If benign, tune by excluding known-safe child process names, hashes, signed binaries, and approved file paths.\n\n### Response and remediation\n\n- Isolate affected endpoints until scope is understood.\n- Terminate suspicious child and descendant processes initiated from `notepad.exe`.\n- Quarantine and preserve the triggering Markdown file for forensic analysis.\n- Run endpoint malware scans and collect volatile artifacts (running processes, network connections, autoruns).\n- Patch Windows/Notepad to the latest security update level addressing the vulnerability.\n- Hunt for the same parent-child pattern across other hosts to identify additional impacted systems.\n", + "query": "process where host.os.type == \"windows\" and event.type == \"start\" and\n process.parent.name : \"notepad.exe\" and process.parent.args : \"*.md\"\n", + "references": [ + "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-20841" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "windows", + "version": "^3.0.0" + }, + { + "package": "m365_defender", + "version": "^3.0.0" + }, + { + "package": "sentinel_one_cloud_funnel", + "version": "^1.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.args", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.name", + "type": "keyword" + } + ], + "risk_score": 73, + "rule_id": "7f3521dd-fb80-4548-a7eb-8db37b898dc2", + "severity": "high", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Execution", + "Data Source: Elastic Endgame", + "Data Source: Elastic Defend", + "Data Source: Microsoft Defender for Endpoint", + "Data Source: Sysmon", + "Data Source: SentinelOne", + "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": "7f3521dd-fb80-4548-a7eb-8db37b898dc2_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/7f89afef-9fc5-4e7b-bf16-75ffdf27f8db_105.json b/packages/security_detection_engine/kibana/security_rule/7f89afef-9fc5-4e7b-bf16-75ffdf27f8db_105.json new file mode 100644 index 00000000000..18e14042d35 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/7f89afef-9fc5-4e7b-bf16-75ffdf27f8db_105.json @@ -0,0 +1,101 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "building_block_type": "default", + "description": "Identifies the use of built-in tools attackers can use to check for Internet connectivity on compromised systems. These results may be used to determine communication capabilities with C2 servers, or to identify routes, redirectors, and proxy servers.", + "from": "now-9m", + "history_window_start": "now-7d", + "index": [ + "logs-endpoint.events.*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "Discovery of Internet Capabilities via Built-in Tools", + "new_terms_fields": [ + "host.id", + "user.id", + "process.command_line" + ], + "query": "host.os.type:windows and event.category:process and event.type:start and \nprocess.name.caseless:(\"ping.exe\" or \"tracert.exe\" or \"pathping.exe\") and\nnot process.args:(\"127.0.0.1\" or \"0.0.0.0\" or \"localhost\" or \"::1\" or 192.168.*) and\nprocess.command_line:*.*\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.command_line", + "type": "wildcard" + }, + { + "ecs": false, + "name": "process.name.caseless", + "type": "unknown" + } + ], + "risk_score": 21, + "rule_id": "7f89afef-9fc5-4e7b-bf16-75ffdf27f8db", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Discovery", + "Rule Type: BBR", + "Data Source: Elastic Defend" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0007", + "name": "Discovery", + "reference": "https://attack.mitre.org/tactics/TA0007/" + }, + "technique": [ + { + "id": "T1016", + "name": "System Network Configuration Discovery", + "reference": "https://attack.mitre.org/techniques/T1016/", + "subtechnique": [ + { + "id": "T1016.001", + "name": "Internet Connection Discovery", + "reference": "https://attack.mitre.org/techniques/T1016/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "new_terms", + "version": 105 + }, + "id": "7f89afef-9fc5-4e7b-bf16-75ffdf27f8db_105", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/7fda9bb2-fd28-11ee-85f9-f661ea17fbce_10.json b/packages/security_detection_engine/kibana/security_rule/7fda9bb2-fd28-11ee-85f9-f661ea17fbce_10.json new file mode 100644 index 00000000000..21c5b03cd50 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/7fda9bb2-fd28-11ee-85f9-f661ea17fbce_10.json @@ -0,0 +1,125 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies potential ransomware note being uploaded to an AWS S3 bucket. This rule detects the PutObject S3 API call with an object name commonly associated with ransomware notes. The keywords detected here rarely overlap with common file names and have been attributed to ransomware notes with high-confidence. Adversaries with access to a misconfigured S3 bucket may retrieve, delete, and replace objects with ransom notes to extort victims.", + "false_positives": [ + "This rule uses matches regex patterns for common ransom note file names. Ensure that the uploaded file is not part of a legitimate operation before taking action." + ], + "from": "now-6m", + "index": [ + "filebeat-*", + "logs-aws.cloudtrail-*" + ], + "investigation_fields": { + "field_names": [ + "@timestamp", + "user.name", + "user_agent.original", + "source.ip", + "aws.cloudtrail.user_identity.arn", + "aws.cloudtrail.user_identity.type", + "aws.cloudtrail.user_identity.access_key_id", + "aws.cloudtrail.resources.arn", + "aws.cloudtrail.resources.type", + "tls.client.server_name", + "event.action", + "event.outcome", + "cloud.account.id", + "cloud.region", + "aws.cloudtrail.request_parameters", + "aws.cloudtrail.response_elements" + ] + }, + "language": "eql", + "license": "Elastic License v2", + "name": "Potential AWS S3 Bucket Ransomware Note Uploaded", + "note": "## Triage and analysis\n\n### Investigating Potential AWS S3 Bucket Ransomware Note Uploaded\n\nThis rule detects a successful `PutObject` to S3 where the object key matches common ransomware-note patterns (for example, `readme`, `decrypt`, `ransom`, and combinations with `file`). Attackers who obtain credentials or abuse overly-permissive bucket policies can upload ransom notes (often after deleting or encrypting data).\n\n### Possible investigation steps\n\n**Confirm the actor and session details** \n- Review `aws.cloudtrail.user_identity.*` (ARN, type, access key, session context), `source.ip`, `user.agent`, and `tls.client.server_name` to identify who performed the upload and from where. Validate whether this principal typically writes to this bucket. \n\n**Inspect the object key and bucket context** \n- From `aws.cloudtrail.request_parameters`, capture the exact `key` and `bucketName`. Check whether the key is publicly readable (ACL), whether the bucket is internet-exposed, and whether replication or lifecycle rules could propagate or remove related objects. \n\n**Pivot to related S3 activity around the same time** \n- Look for `DeleteObject`/`DeleteObjects`, mass `PutObject` spikes, `PutBucketPolicy`, `PutPublicAccessBlock`, `PutBucketVersioning`, and `PutBucketLifecycleConfiguration` events on the same bucket or by the same actor to determine if data destruction, policy tampering, or guard-rail changes occurred. \n\n**Assess blast radius across the account** \n- Search recent CloudTrail for the same actor/IP touching other buckets, KMS keys used by those buckets, and IAM changes (new access keys, policy attachments, role assumptions) that could indicate broader compromise paths consistent with ransomware playbooks. \n\n**Check protections and recovery posture on the bucket** \n- Verify whether S3 Versioning and (if in use) Object Lock legal hold are enabled; note prior versions available for the affected key, and whether lifecycle rules might expire them. \n\n**Correlate with threat signals** \n- Review other related alerts, GuardDuty S3-related findings, AWS Config drift on the bucket and its policy, and any SOAR/IR runbook executions tied to ransomware triage. \n\n### False positive analysis\n- Planned tests or red-team exercises\n- Benign automation naming. Some data-migration or backup tools may use \u201creadme\u201d/\u201crecovery\u201d-style filenames; validate by `user.agent`, principal, and target environment (dev vs prod). \n\n\n### Response and remediation\n\n**Immediate, low-risk actions (safe for most environments)**\n- **Preserve context** : Export the triggering `PutObject` CloudTrail record(s), plus 15\u201330 min before/after, to an evidence bucket (restricted access). \n- **Snapshot configuration** : Record current bucket settings (Block Public Access, Versioning, Object Lock, Bucket Policy, Lifecycle rules) and any KMS keys used.\n- **Quiet the spread** : Pause destructive automation: disable/bypass lifecycle rules that would expire/delete object versions; temporarily pause data pipelines targeting the bucket.\n- **Notify owners** : Inform the bucket/application owner(s) and security leadership.\n\n**Containment options (choose the least disruptive first)**\n- **Harden exposure** : If not already enforced, enable `Block Public Access` for the bucket.\n- **Targeted deny policy (temporary)** : Add a restrictive bucket policy allowing only IR/admin roles while you scope impact. Reconfirm critical workload dependencies before applying.\n- **Credential risk reduction** : If a specific IAM user/key or role is implicated, rotate access keys; for roles, remove risky policy attachments or temporarily restrict with an SCP/deny statement.\n\n**Evidence preservation**\n- Export relevant CloudTrail events, S3 server/access logs (if enabled), AWS Config history for the bucket/policy, and the suspicious object plus its previous versions (if Versioning is enabled).\n- Document actor ARN, source IPs, user agent(s), exact `bucketName`/`key`, and timestamps. Maintain a simple chain-of-custody note for collected artifacts.\n\n**Scope and hunting (same actor/time window)**\n- Look for `DeleteObject(s)`, unusual `PutObject` volume, `PutBucketPolicy`, `PutPublicAccessBlock`, `PutBucketVersioning` changes, `PutBucketLifecycleConfiguration`, and cross-account access.\n- Cross reference other buckets touched by the same actor/IP; recent IAM changes (new keys, policy/role edits); GuardDuty findings tied to S3/credentials.\n\n**Recovery (prioritize data integrity)**\n- If Versioning is enabled, restore last known-good versions for impacted objects. Consider applying Object Lock legal hold to clean versions during recovery if configured.\n- If Versioning is not enabled, recover from backups (AWS Backup, replication targets). Enable Versioning going forward on critical buckets; evaluate Object Lock for high-value data.\n- Carefully remove any temporary deny policy only after credentials are rotated, policies re-validated, and no ongoing destructive activity is observed.\n\n**Post-incident hardening**\n- Enforce `Block Public Access`, enable Versioning (and MFA-Delete where appropriate), and review bucket policies for least privilege.\n- Ensure continuous CloudTrail data events for S3 are enabled in covered regions; enable/verify GuardDuty S3 protections and alerts routing.\n- Add detections for related behaviors (policy tampering, bulk deletes, versioning/lifecycle toggles) and create allowlists for known maintenance windows.\n\n\n### Additional information\n\n- For 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.\n- [AWS IRP\u2014Ransomware](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/IRP-Ransomware.md) (NIST-aligned template for evidence, containment, eradication, recovery, post-incident). \n- [AWS Customer Playbook\u2014Ransom Response (S3)](https://github.com/aws-samples/aws-customer-playbook-framework/blob/a8c7b313636b406a375952ac00b2d68e89a991f2/docs/Ransom_Response_S3.md) (bucket-level response steps: public access blocks, temporary deny, versioning/object lock, lifecycle considerations, recovery). \n", + "query": "file where\n event.dataset == \"aws.cloudtrail\" and\n event.provider == \"s3.amazonaws.com\" and\n event.action == \"PutObject\" and\n event.outcome == \"success\" and\n /* Apply regex to match patterns only after the bucket name */\n /* common ransom note file name keywords */\n aws.cloudtrail.resources.arn regex~ \"arn:aws:s3:::[^/]+/.*?(how|decrypt|restor|help|instruct|read|get|recov|save|encrypt|info|ransom).*\"\n and not aws.cloudtrail.resources.arn regex~ \".*(AWSLogs|CloudTrail|access-logs).*\"\n and not aws.cloudtrail.user_identity.type == \"AWSService\"\n", + "references": [ + "https://stratus-red-team.cloud/attack-techniques/AWS/aws.impact.s3-ransomware-batch-deletion/", + "https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/", + "https://www.mdpi.com/2073-431X/10/11/145#computers-10-00145-f002" + ], + "related_integrations": [ + { + "integration": "cloudtrail", + "package": "aws", + "version": "^4.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "aws.cloudtrail.resources.arn", + "type": "keyword" + }, + { + "ecs": false, + "name": "aws.cloudtrail.user_identity.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.outcome", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.provider", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "7fda9bb2-fd28-11ee-85f9-f661ea17fbce", + "setup": "AWS S3 data types need to be enabled in the CloudTrail trail configuration to capture PutObject API calls.", + "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": "T1485", + "name": "Data Destruction", + "reference": "https://attack.mitre.org/techniques/T1485/" + }, + { + "id": "T1486", + "name": "Data Encrypted for Impact", + "reference": "https://attack.mitre.org/techniques/T1486/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 10 + }, + "id": "7fda9bb2-fd28-11ee-85f9-f661ea17fbce_10", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/7fda9bb2-fd28-11ee-85f9-f661ea17fbce_6.json b/packages/security_detection_engine/kibana/security_rule/7fda9bb2-fd28-11ee-85f9-f661ea17fbce_6.json deleted file mode 100644 index e774c83eb25..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/7fda9bb2-fd28-11ee-85f9-f661ea17fbce_6.json +++ /dev/null @@ -1,57 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies potential ransomware note being uploaded to an AWS S3 bucket. This rule detects the `PutObject` S3 API call with a common ransomware note file extension such as `.ransom`, or `.lock`. Adversaries with access to a misconfigured S3 bucket may retrieve, delete, and replace objects with ransom notes to extort victims.", - "false_positives": [ - "Administrators may legitimately access, delete, and replace objects in S3 buckets. Ensure that the sequence of events is not part of a legitimate operation before taking action." - ], - "from": "now-9m", - "language": "esql", - "license": "Elastic License v2", - "name": "Potential AWS S3 Bucket Ransomware Note Uploaded", - "note": "## Triage and analysis\n\n### Investigating Potential AWS S3 Bucket Ransomware Note Uploaded\n\nThis rule detects the `PutObject` S3 API call with a common ransomware note file extension such as `.ransom`, or `.lock`. Adversaries with access to a misconfigured S3 bucket may retrieve, delete, and replace objects with ransom notes to extort victims.\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 `PutObject` action. 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 ransom note was uploaded. Changes during non-business hours or outside regular maintenance windows might require further scrutiny.\n- **Inspect the Ransom Note**: Review the `aws.cloudtrail.request_parameters` for the `PutObject` action to identify the characteristics of the uploaded ransom note. Look for common ransomware file extensions such as `.txt`, `.note`, `.ransom`, or `.html`.\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 before placing the ransom note.\n\n### False Positive Analysis:\n\n- **Legitimate Administrative Actions**: Confirm if the `PutObject` 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- **Verify through Outcomes**: Check the `aws.cloudtrail.response_elements` and the `event.outcome` to confirm if the upload was successful and intended according to policy.\n\n### Response and Remediation:\n\n- **Immediate Review and Reversal if Necessary**: If the activity was unauthorized, remove the uploaded ransom notes from the 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 `PutObject` 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- [AWS S3 Ransomware Batch Deletion](https://stratus-red-team.cloud/attack-techniques/AWS/aws.impact.s3-ransomware-batch-deletion/)\n- [S3 Ransomware Part 1: Attack Vector](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)\n", - "query": "from logs-aws.cloudtrail-*\n\n// any successful uploads via S3 API requests\n| where\n event.dataset == \"aws.cloudtrail\"\n and event.provider == \"s3.amazonaws.com\"\n and event.action == \"PutObject\"\n and event.outcome == \"success\"\n\n// extract object key from API request parameters\n| dissect aws.cloudtrail.request_parameters \"%{?ignore_values}key=%{Esql.aws_cloudtrail_request_parameters_object_key}}\"\n\n// regex match against common ransomware naming patterns\n| where\n Esql.aws_cloudtrail_request_parameters_object_key rlike \"(.*)(ransom|lock|crypt|enc|readme|how_to_decrypt|decrypt_instructions|recovery|datarescue)(.*)\"\n and not Esql.aws_cloudtrail_request_parameters_object_key rlike \"(.*)(AWSLogs|CloudTrail|access-logs)(.*)\"\n\n// keep relevant ECS and derived fields\n| keep\n tls.client.server_name,\n aws.cloudtrail.user_identity.arn,\n Esql.aws_cloudtrail_request_parameters_object_key\n\n// aggregate by server name, actor, and object key\n| stats\n Esql.event_count = count(*)\n by\n tls.client.server_name,\n aws.cloudtrail.user_identity.arn,\n Esql.aws_cloudtrail_request_parameters_object_key\n\n// filter for rare single uploads (likely test/detonation)\n| where Esql.event_count == 1\n", - "references": [ - "https://s3.amazonaws.com/bizzabo.file.upload/PtZzA0eFQwV2RA5ysNeo_ERMETIC%20REPORT%20-%20AWS%20S3%20Ransomware%20Exposure%20in%20the%20Wild.pdf", - "https://stratus-red-team.cloud/attack-techniques/AWS/aws.impact.s3-ransomware-batch-deletion/", - "https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/" - ], - "risk_score": 47, - "rule_id": "7fda9bb2-fd28-11ee-85f9-f661ea17fbce", - "setup": "AWS S3 data 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", - "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/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 6 - }, - "id": "7fda9bb2-fd28-11ee-85f9-f661ea17fbce_6", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/8025db49-c57c-4fc0-bd86-7ccd6d10a35a_109.json b/packages/security_detection_engine/kibana/security_rule/8025db49-c57c-4fc0-bd86-7ccd6d10a35a_109.json new file mode 100644 index 00000000000..7f29a4a15a0 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/8025db49-c57c-4fc0-bd86-7ccd6d10a35a_109.json @@ -0,0 +1,146 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies scripts that contain patterns and known methods that obfuscate PowerShell code. Attackers can use obfuscation techniques to bypass PowerShell security protections such as Antimalware Scan Interface (AMSI).", + "filters": [ + { + "meta": { + "negate": true + }, + "query": { + "wildcard": { + "file.directory": { + "case_insensitive": true, + "value": "?:\\\\Program Files\\\\WindowsPowerShell\\\\Modules\\\\*" + } + } + } + }, + { + "meta": { + "negate": true + }, + "query": { + "wildcard": { + "file.directory": { + "case_insensitive": true, + "value": "?:\\\\Program Files (x86)\\\\WindowsPowerShell\\\\Modules\\\\*" + } + } + } + }, + { + "meta": { + "negate": true + }, + "query": { + "wildcard": { + "file.path": { + "case_insensitive": true, + "value": "?:\\\\ProgramData\\\\Microsoft\\\\Windows Defender Advanced Threat Protection\\\\Downloads\\\\*" + } + } + } + } + ], + "from": "now-9m", + "index": [ + "winlogbeat-*", + "logs-windows.powershell*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "Deprecated - Potential PowerShell Obfuscated Script", + "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 - Potential PowerShell Obfuscated Script\n\nPowerShell is a powerful scripting language used for task automation and configuration management in Windows environments. Adversaries exploit its flexibility to obfuscate scripts, evading security measures like AMSI. The detection rule identifies obfuscation patterns, such as string manipulation and encoding techniques, to flag potentially malicious scripts, aiding in defense evasion detection.\n\n### Possible investigation steps\n\n- Review the PowerShell script block text captured in the alert to identify any suspicious patterns or obfuscation techniques, such as string manipulation or encoding methods like \"[string]::join\" or \"-Join\".\n- Check the process execution details, including the parent process and command line arguments, to understand the context in which the PowerShell script was executed.\n- Investigate the source and destination of the script execution by examining the host and user details to determine if the activity aligns with expected behavior or if it originates from an unusual or unauthorized source.\n- Analyze any network connections or file modifications associated with the PowerShell process to identify potential data exfiltration or lateral movement activities.\n- Correlate the alert with other security events or logs, such as Windows Event Logs or network traffic logs, to gather additional context and identify any related suspicious activities.\n- Assess the risk and impact of the detected activity by considering the severity and risk score provided in the alert, and determine if immediate remediation actions are necessary.\n\n### False positive analysis\n\n- Legitimate administrative scripts may use string manipulation and encoding techniques for benign purposes, such as data processing or configuration management. Review the context of the script execution and verify the source and intent before flagging it as malicious.\n- Scripts that automate complex tasks might use obfuscation-like patterns to handle data securely or efficiently. Consider whitelisting known scripts or trusted sources to reduce false positives.\n- Development and testing environments often run scripts with obfuscation patterns for testing purposes. Exclude these environments from the rule or create exceptions for specific users or groups involved in development.\n- Security tools and monitoring solutions might generate PowerShell scripts with obfuscation patterns as part of their normal operation. Identify these tools and exclude their activities from triggering the rule.\n- Regularly update the list of exceptions and whitelisted scripts to ensure that new legitimate scripts are not mistakenly flagged as threats.\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 detection rule to halt ongoing malicious activity.\n- Conduct a thorough review of the PowerShell script block logs to identify and remove any obfuscated scripts or malicious code remnants.\n- Restore the system from a known good backup if malicious activity is confirmed and system integrity is compromised.\n- Update and patch the affected system to ensure all security vulnerabilities are addressed, reducing the risk of exploitation.\n- Monitor the system and network for any signs of re-infection or similar obfuscation patterns to ensure the threat has been fully mitigated.\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.", + "query": "event.category:process and host.os.type:windows and\n powershell.file.script_block_text : (\n \"[string]::join\" or\n \"-Join\" or\n \"[convert]::toint16\" or\n \"[char][int]$_\" or\n (\"ConvertTo-SecureString\" and \"PtrToStringAuto\") or\n \"-BXor\" or\n (\"replace\" and \"char\") or\n \"[array]::reverse\" or\n \"-replace\"\n ) and\n powershell.file.script_block_text : (\n (\"$pSHoMe[\" and \"+$pSHoMe[\") or\n (\"$ShellId[\" and \"+$ShellId[\") or\n (\"$env:ComSpec[4\" and \"25]-Join\") or\n ((\"Set-Variable\" or \"SV\" or \"Set-Item\") and \"OFS\") or\n (\"*MDR*\" and \"Name[3,11,2]\") or\n (\"$VerbosePreference\" and \"[1,3]+'X'-Join''\") or\n (\"rahc\" or \"ekovin\" or \"gnirts\" or \"ecnereferpesobrev\" or \"ecalper\" or \"cepsmoc\" or \"dillehs\") or\n (\"System.Management.Automation.$([cHAr]\" or \"System.$([cHAr]\" or \")+[cHAR]([byte]\")\n ) and\n not powershell.file.script_block_text : (\n (\"Copyright (c) 2018 Ansible Project\" or \"Export-ModuleMember -Function Add-CSharpType\") and\n (\"[Object]$AnsibleModule\" or \"$AnsibleModule.Tmpdir\")\n )\n", + "references": [ + "https://github.com/danielbohannon/Invoke-Obfuscation" + ], + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.category", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_text", + "type": "unknown" + } + ], + "risk_score": 21, + "rule_id": "8025db49-c57c-4fc0-bd86-7ccd6d10a35a", + "setup": "## Setup\n\nPowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104).\nSetup instructions: https://ela.st/powershell-logging-setup\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": "query", + "version": 109 + }, + "id": "8025db49-c57c-4fc0-bd86-7ccd6d10a35a_109", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/814d96c7-2068-42aa-ba8e-fe0ddd565e2e_8.json b/packages/security_detection_engine/kibana/security_rule/814d96c7-2068-42aa-ba8e-fe0ddd565e2e_8.json new file mode 100644 index 00000000000..a8956b33ab6 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/814d96c7-2068-42aa-ba8e-fe0ddd565e2e_8.json @@ -0,0 +1,63 @@ +{ + "attributes": { + "anomaly_threshold": 70, + "author": [ + "Elastic" + ], + "description": "An anomaly detection job has detected a remote file transfer with a rare extension, which could indicate potential lateral movement activity on the host.", + "from": "now-90m", + "interval": "15m", + "license": "Elastic License v2", + "machine_learning_job_id": "lmd_rare_file_extension_remote_transfer", + "name": "Unusual Remote File Extension", + "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 Remote File Extension\n\nThe detection of unusual remote file extensions leverages machine learning to identify anomalies in file transfers, which may suggest lateral movement by adversaries. Attackers often exploit remote services to transfer files with uncommon extensions, bypassing standard security measures. This rule flags such anomalies, aiding in early detection of potential threats by correlating rare file extensions with known lateral movement tactics.\n\n### Possible investigation steps\n\n- Review the alert details to identify the specific file extension and the source and destination of the file transfer.\n- Check the historical data for the identified file extension to determine if it has been used previously in legitimate activities or if it is indeed rare.\n- Investigate the source host to identify any recent changes or suspicious activities, such as new user accounts or unusual login patterns.\n- Examine the destination host for any signs of compromise or unauthorized access, focusing on recent file modifications or unexpected processes.\n- Correlate the file transfer event with other security alerts or logs to identify potential patterns of lateral movement or exploitation of remote services.\n- Consult threat intelligence sources to determine if the rare file extension is associated with known malware or adversary tactics.\n\n### False positive analysis\n\n- Common internal file transfers with rare extensions may trigger false positives. Review and whitelist known benign file extensions used by internal applications or processes.\n- Automated backup or synchronization tools might use uncommon file extensions. Identify these tools and create exceptions for their typical file extensions to prevent unnecessary alerts.\n- Development environments often generate files with unique extensions. Collaborate with development teams to understand these patterns and exclude them from detection if they are verified as non-threatening.\n- Security tools or scripts that transfer diagnostic or log files with unusual extensions can be mistaken for lateral movement. Document these tools and adjust the rule to ignore their specific file extensions.\n- Regularly review and update the list of excluded extensions to ensure it reflects current operational practices and does not inadvertently allow malicious activity.\n\n### Response and remediation\n\n- Isolate the affected host immediately to prevent further lateral movement and contain the potential threat.\n- Review and terminate any suspicious remote sessions or connections identified on the host to cut off unauthorized access.\n- Conduct a thorough scan of the affected system for malware or unauthorized software that may have been transferred using the unusual file extension.\n- Restore the affected system from a known good backup if any malicious activity or compromise is confirmed.\n- Update and patch all software and systems on the affected host to close any vulnerabilities that may have been exploited.\n- Monitor network traffic for any further unusual file transfers or connections, focusing on rare file extensions and remote service exploitation patterns.\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.", + "references": [ + "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html", + "https://docs.elastic.co/en/integrations/lmd", + "https://www.elastic.co/blog/detecting-lateral-movement-activity-a-new-kibana-integration", + "https://www.elastic.co/blog/remote-desktop-protocol-connections-elastic-security" + ], + "related_integrations": [ + { + "package": "lmd", + "version": "^2.0.0" + }, + { + "package": "endpoint", + "version": "^8.2.0" + } + ], + "risk_score": 21, + "rule_id": "814d96c7-2068-42aa-ba8e-fe0ddd565e2e", + "setup": "## Setup\n\nThis rule requires the `host.ip` field to be populated.\nFor **Elastic Defend** events on versions **8.18 and above**, this field is **disabled by default**.\n\nIf you are using **Elastic Defend**, ensure host IP collection is enabled by following the configuration steps in the\n[helper guide](https://www.elastic.co/docs/solutions/security/configure-elastic-defend/configure-data-volume-for-elastic-endpoint#host-fields).\n\nThe rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration.\n\n### Lateral Movement Detection Setup\nThe Lateral Movement Detection integration detects lateral movement activity by identifying abnormalities in file and Windows RDP events. Anomalies are detected using Elastic's Anomaly Detection feature.\n\n#### Prerequisite Requirements:\n- Fleet is required for Lateral Movement Detection.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n- File events collected by the [Elastic Defend](https://docs.elastic.co/en/integrations/endpoint) integration.\n- To install Elastic Defend, refer to the [documentation](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n\n#### The following steps should be executed to install assets associated with the Lateral Movement Detection integration:\n- Go to the Kibana homepage. Under Management, click Integrations.\n- In the query bar, search for Lateral Movement Detection and select the integration to see more details about it.\n- Follow the instructions under the **Installation** section.\n- For this rule to work, complete the instructions through **Add preconfigured anomaly detection jobs**.\n", + "severity": "low", + "tags": [ + "Use Case: Lateral Movement Detection", + "Rule Type: ML", + "Rule Type: Machine Learning", + "Tactic: Lateral Movement", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0008", + "name": "Lateral Movement", + "reference": "https://attack.mitre.org/tactics/TA0008/" + }, + "technique": [ + { + "id": "T1210", + "name": "Exploitation of Remote Services", + "reference": "https://attack.mitre.org/techniques/T1210/" + } + ] + } + ], + "type": "machine_learning", + "version": 8 + }, + "id": "814d96c7-2068-42aa-ba8e-fe0ddd565e2e_8", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/818e23e6-2094-4f0e-8c01-22d30f3506c6_315.json b/packages/security_detection_engine/kibana/security_rule/818e23e6-2094-4f0e-8c01-22d30f3506c6_315.json new file mode 100644 index 00000000000..f9b804c853b --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/818e23e6-2094-4f0e-8c01-22d30f3506c6_315.json @@ -0,0 +1,140 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects registry changes that disable PowerShell Script Block Logging. Attackers may disable this logging to conceal their activities in the host and evade detection.", + "from": "now-9m", + "index": [ + "winlogbeat-*", + "logs-endpoint.events.registry-*", + "logs-windows.sysmon_operational-*", + "endgame-*", + "logs-m365_defender.event-*", + "logs-sentinel_one_cloud_funnel.*", + "logs-crowdstrike.fdr*" + ], + "investigation_fields": { + "field_names": [ + "@timestamp", + "registry.path", + "registry.value", + "registry.data.strings", + "process.executable", + "process.entity_id", + "host.name", + "host.id", + "user.name", + "user.id", + "user.domain" + ] + }, + "language": "eql", + "license": "Elastic License v2", + "name": "PowerShell Script Block Logging Disabled", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This guide was created by humans with the assistance of generative AI. While its contents have been manually curated to include the most valuable information, always validate assumptions and adjust procedures to match your internal runbooks and incident triage and response policies.\n\n### Investigating PowerShell Script Block Logging Disabled\n\nThis alert indicates a registry modification that set `EnableScriptBlockLogging` to a disabled value (`registry.data.strings` of `0` or `0x00000000`). Disabling Script Block Logging reduces visibility into PowerShell execution and is commonly used to evade detection, especially when followed by script-driven activity.\n\n#### Key alert fields to review\n\n- `process.executable`: The process responsible for modifying the registry value.\n- `registry.value`: The registry value name that was changed (`EnableScriptBlockLogging`).\n- `registry.data.strings`: The new data indicating the setting was disabled.\n- `registry.path`: The full registry path of the modified value.\n- `user.name`, `user.domain`, `user.id`: Account execution context for correlation, prioritization, and scoping.\n- `host.name`, `host.id`: Host execution context for correlation, prioritization, and scoping.\n\n#### Possible investigation steps\n\n- Establish the affected endpoint and time window:\n - Use `host.name`, `host.id`, and `@timestamp` to identify the impacted endpoint and define a review window (include activity immediately before and after the change).\n - Prioritize based on endpoint role and criticality (for example, servers and admin workstations).\n\n- Validate the registry change and its scope:\n - Review `registry.path`, `registry.value`, and `registry.data.strings` to confirm the setting was disabled and to understand where it was applied.\n - Compare `registry.path` to common policy locations for Script Block Logging (for example, `HKEY_LOCAL_MACHINE\\Software\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\\EnableScriptBlockLogging`).\n - Determine whether the change is likely machine-wide or user-scoped based on the hive reflected in `registry.path`, and assess the blast radius accordingly.\n - Check for repeated changes (toggling) to the same `registry.path` and `registry.value` around the alert time, which can indicate attempted evasion or policy enforcement conflicts.\n\n- Identify the modifying process and execution context:\n - Review `process.executable` for legitimacy (expected binary name, expected install path) and whether it typically performs configuration changes.\n - Pivoting using `process.entity_id`, review `process.command_line` to understand how the value was set and whether the command line suggests interactive administration, scripts, or automation.\n - Using nearby endpoint process telemetry on the same host, reconstruct the process tree to identify the initiating process (parent) and any immediate follow-on execution that may have benefited from reduced PowerShell logging.\n\n- Assess the user context and authorization:\n - Review `user.name`, `user.domain`, and `user.id` to determine whether the account is expected to manage logging or policy settings on this endpoint.\n - If the change is attributed to a service or system context, identify the associated service, scheduled activity, or management workflow that could have performed the modification.\n - Scope the user across other hosts for similar activity during the same window to identify potential credential misuse.\n\n- Hunt for related activity that may be masked by reduced logging:\n - Review host activity immediately before the change for suspicious behavior that could explain the need to disable Script Block Logging (initial access, privilege escalation, or tool staging).\n - Review host activity after the change for suspicious process launches, script interpreter activity, persistence attempts, credential access behavior, or lateral movement indicators.\n - Review network activity from the host around the change for connections consistent with payload retrieval, remote access, or command and control.\n - Review other registry changes around the same time that may further impair visibility or weaken defenses.\n\n- Scope and impact assessment across the environment:\n - Search for other instances where `registry.value` is `EnableScriptBlockLogging` and `registry.data.strings` indicates a disabled state to determine whether this is isolated or widespread.\n - Pivot on `process.executable` and `user.id` to identify other endpoints where the same process or account modified this setting.\n - Identify whether the setting was later restored on the same host by looking for subsequent changes to the same `registry.path` and `registry.value`.\n\n### False positive analysis\n\n- Authorized policy, baseline, or hardening changes that intentionally modify PowerShell logging settings, supported by change records and consistent execution by expected accounts and tooling.\n- Provisioning or imaging workflows where configuration changes occur during early host lifecycle stages and are consistent across a known deployment batch.\n- Short-lived administrative troubleshooting where the setting is temporarily changed and promptly restored, with supporting documentation.\n\n### Response and remediation\n\n- If the change is unexpected or suspicious:\n - Treat as potential defense evasion and escalate according to incident response procedures.\n - Contain the endpoint if there are indicators of follow-on malicious activity in the surrounding timeframe.\n - Preserve evidence related to the change, including `process.executable`, `process.command_line`, user context, and any correlated endpoint telemetry.\n\n- Restore and enforce PowerShell visibility:\n - Re-enable Script Block Logging using approved administrative processes and verify the setting persists through policy enforcement.\n - Monitor for repeated attempts to disable Script Block Logging, especially from the same user or originating process.\n\n- Remediate root cause and reduce recurrence:\n - Identify and remove unauthorized tooling or persistence associated with the modifying process.\n - Investigate potential account compromise for the associated user and take appropriate actions (credential reset and access review), prioritizing privileged accounts.\n - Hunt for additional endpoints impacted by the same user or process and remediate as needed.\n - Apply least-privilege controls to limit who can modify logging-related registry settings and improve alerting for additional defense impairment behaviors observed during the investigation window.\n", + "query": "registry where host.os.type == \"windows\" and event.type == \"change\" and\n registry.value : \"EnableScriptBlockLogging\" and\n registry.data.strings : (\"0\", \"0x00000000\") and\n not process.executable : (\n \"?:\\\\Windows\\\\System32\\\\svchost.exe\",\n \"?:\\\\Windows\\\\System32\\\\DeviceEnroller.exe\",\n \"?:\\\\Windows\\\\system32\\\\omadmclient.exe\",\n \"?:\\\\Program Files\\\\Trend Micro\\\\Cloud Endpoint\\\\CloudEndpointService.exe\",\n \"?:\\\\Program Files (x86)\\\\N-able Technologies\\\\AutomationManagerAgent\\\\AutomationManager.AgentService.exe\",\n \n /* Crowdstrike specific exclusion as it uses NT Object paths */\n \"\\\\Device\\\\HarddiskVolume*\\\\Windows\\\\System32\\\\svchost.exe\",\n \"\\\\Device\\\\HarddiskVolume*\\\\Windows\\\\System32\\\\DeviceEnroller.exe\",\n \"\\\\Device\\\\HarddiskVolume*\\\\Windows\\\\system32\\\\omadmclient.exe\",\n \"\\\\Device\\\\HarddiskVolume*\\\\Program Files\\\\Trend Micro\\\\Cloud Endpoint\\\\CloudEndpointService.exe\",\n \"\\\\Device\\\\HarddiskVolume*\\\\Program Files (x86)\\\\N-able Technologies\\\\AutomationManagerAgent\\\\AutomationManager.AgentService.exe\"\n )\n", + "references": [ + "https://admx.help/?Category=Windows_10_2016&Policy=Microsoft.Policies.PowerShell::EnableScriptBlockLogging" + ], + "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" + }, + { + "package": "crowdstrike", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.executable", + "type": "keyword" + }, + { + "ecs": true, + "name": "registry.data.strings", + "type": "wildcard" + }, + { + "ecs": true, + "name": "registry.value", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "818e23e6-2094-4f0e-8c01-22d30f3506c6", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Resources: Investigation Guide", + "Data Source: Elastic Endgame", + "Data Source: Elastic Defend", + "Data Source: Sysmon", + "Data Source: Microsoft Defender for Endpoint", + "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": "T1112", + "name": "Modify Registry", + "reference": "https://attack.mitre.org/techniques/T1112/" + }, + { + "id": "T1562", + "name": "Impair Defenses", + "reference": "https://attack.mitre.org/techniques/T1562/", + "subtechnique": [ + { + "id": "T1562.002", + "name": "Disable Windows Event Logging", + "reference": "https://attack.mitre.org/techniques/T1562/002/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 315 + }, + "id": "818e23e6-2094-4f0e-8c01-22d30f3506c6_315", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/81fe9dc6-a2d7-4192-a2d8-eed98afc766a_318.json b/packages/security_detection_engine/kibana/security_rule/81fe9dc6-a2d7-4192-a2d8-eed98afc766a_318.json new file mode 100644 index 00000000000..4bd4a148316 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/81fe9dc6-a2d7-4192-a2d8-eed98afc766a_318.json @@ -0,0 +1,149 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies PowerShell script block content that combines Base64 decoding with .NET decompression (Deflate/GZip). Attackers use this pattern to deobfuscate and reconstruct payloads in memory to evade defenses.", + "false_positives": [ + "Legitimate PowerShell Scripts which makes use of compression and encoding." + ], + "filters": [ + { + "meta": { + "negate": true + }, + "query": { + "wildcard": { + "file.path": { + "case_insensitive": true, + "value": "?:\\\\ProgramData\\\\Microsoft\\\\Windows Defender Advanced Threat Protection\\\\Downloads\\\\*" + } + } + } + } + ], + "from": "now-9m", + "index": [ + "winlogbeat-*", + "logs-windows.powershell*" + ], + "investigation_fields": { + "field_names": [ + "@timestamp", + "user.name", + "user.id", + "user.domain", + "powershell.file.script_block_text", + "powershell.file.script_block_id", + "powershell.sequence", + "powershell.total", + "file.path", + "file.directory", + "file.name", + "process.pid", + "host.name", + "host.id", + "powershell.file.script_block_length" + ] + }, + "language": "kuery", + "license": "Elastic License v2", + "name": "PowerShell Suspicious Payload Encoded and Compressed", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This guide was created by humans with the assistance of generative AI. While its contents have been manually curated to include the most valuable information, always validate assumptions and adjust procedures to match your internal runbooks and incident triage and response policies.\n\n### Investigating PowerShell Suspicious Payload Encoded and Compressed\n\nThis rule flags PowerShell script blocks that decode Base64 data and decompress it using .NET Deflate or GZip streams. This pattern is frequently used to conceal secondary script content or payloads until runtime. Focus on reconstructing the full script, recovering the decoded content, and identifying any follow-on execution on the host.\n\n#### Key alert fields to review\n\n- `user.name`, `user.domain`, `user.id`: Account execution context for correlation, prioritization, and scoping.\n- `host.name`, `host.id`: Host execution context for correlation, prioritization, and scoping.\n- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file.\n- `powershell.file.script_block_text`: Script block content that matched the detection logic.\n- `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`: Script block metadata to pivot to other fragments or reconstruct full script content when split across multiple events.\n- `powershell.file.script_block_entropy_bits`: Shannon entropy of the script block. Higher values may indicate obfuscation.\n- `powershell.file.script_block_surprisal_stdev`: Standard deviation of surprisal across the script block. Low values indicate uniform randomness. High values indicate mixed patterns and variability.\n- `powershell.file.script_block_unique_symbols`: Count of distinct characters present in the script block.\n- `powershell.file.script_block_length`: Script block length (size) context.\n\n#### Possible investigation steps\n\n- Establish scope and priority using alert context:\n - Review `host.name` / `host.id` to identify the affected endpoint and its role (workstation, server, jump host).\n - Review `user.name` / `user.domain` / `user.id` to determine whether the account is expected to run PowerShell on this host and whether it is privileged or widely used.\n - Check whether this user-host pairing is common or rare in your environment to help prioritize.\n\n- Identify script provenance and how it was introduced:\n - Review `file.path`, `file.directory`, and `file.name` to determine whether the script block was sourced from an on-disk file.\n - If `file.path` is present, assess whether the location aligns with normal administrative or automation activity for this host, or whether it appears user-writable, temporary, or otherwise unusual for the account and system role.\n - If `file.path` is not present or is not informative, treat the content as potentially interactive or dynamically generated and prioritize reconstructing full script content.\n\n- Interpret the entropy indicators to guide analysis focus:\n - Use `powershell.file.script_block_length` with `powershell.file.script_block_entropy_bits` to understand whether the alert is driven by a large embedded blob versus smaller obfuscation fragments.\n - Use `powershell.file.script_block_surprisal_stdev` to distinguish between:\n - Uniformly random-looking blocks (often consistent with compressed/encrypted data).\n - Mixed content (often consistent with a readable wrapper that transforms and then executes an embedded payload).\n - Use `powershell.file.script_block_unique_symbols` to identify whether the content resembles a limited alphabet encoding (for example, Base64-like) versus broader character sets.\n\n- Review and reconstruct script content before making a determination:\n - Review `powershell.file.script_block_text` to identify:\n - Large contiguous encoded strings, byte arrays, or character arrays.\n - Transform routines (decode, decrypt, decompress) that produce secondary content.\n - Secondary execution patterns where transformed content is immediately evaluated or invoked.\n - Embedded external references (URLs, domains, IPs) or instructions to write content to disk.\n\n- Rebuild full content when script blocks are split across events:\n - Pivot on `powershell.file.script_block_id` to collect all related fragments.\n - Order fragments using `powershell.sequence` and validate completeness using `powershell.total`.\n - Perform content review on the reconstructed output, not on individual fragments, to avoid missing loader logic or the embedded payload boundaries.\n\n- Extract indicators and correlate with adjacent telemetry to confirm impact:\n - From `powershell.file.script_block_text` (and any safely decoded or decompressed content), extract indicators such as domains, URLs, IPs, file names/paths, and distinctive strings.\n - Correlate on the same `host.id` and approximate timeframe with available endpoint telemetry to identify the PowerShell host process and its launch source (parent process or initiating mechanism). Use that context to assess whether execution is user-initiated, automation-driven, or suspicious.\n - Correlate on the same `host.id` and timeframe with available network, file, registry, and authentication telemetry to identify follow-on activity consistent with script execution (downloads, file writes, persistence changes, or unusual sign-ins).\n\n- Expand scope to detect related activity:\n - Search for additional high-entropy script blocks on the same `host.id` and `user.id` before and after the alert.\n - Identify other hosts where the same `file.name` / `file.path` appears with similar suspicious content characteristics.\n - Look for repeated substrings or structural similarities in `powershell.file.script_block_text` across different alerts to identify shared tooling or campaigns.\n\n### False positive analysis\n\n- Benign activity can produce high-entropy script blocks when scripts embed packaged resources or data blobs (for example, installers, large configuration payloads, certificates, or compressed content used by administrative tooling).\n- Indicators that support a benign determination:\n - Consistent `file.path` / `file.name` associated with a known internal automation package or vendor tool across many hosts.\n - Stable and expected `user.name` / `user.id` usage (for example, dedicated automation accounts) with predictable host targeting.\n - Repeated, consistent script structure over time where decoding or decompression results in recognizable administrative logic rather than staging or secondary execution.\n- If the alert is verified benign:\n - Document the owning team/tool, expected hosts, and typical execution cadence.\n - Suppress recurring noise by scoping on stable attributes available in the alert (for example, `user.id`, `host.id`, and `file.path`) while preserving visibility for new or unusual sources.\n\n### Response and remediation\n\n- If malicious or suspicious activity is confirmed:\n - Contain the affected host to limit further execution and lateral movement.\n - Preserve evidence from the alert, including `powershell.file.script_block_text`, reconstructed content (using `powershell.file.script_block_id` / `powershell.sequence` / `powershell.total`), and associated context (`user.*`, `host.*`, `file.*`, and entropy metrics).\n - Use extracted indicators from the script content to hunt for related activity across the environment and to identify additional affected hosts or accounts.\n - Remediate any identified persistence or staging artifacts associated with the activity and remove malicious content from affected systems.\n - If account compromise is suspected, reset credentials for `user.id` / `user.name` and review access paths and recent authentication activity for that account.\n\n- If benign activity is confirmed:\n - Record the business justification and expected behavior for the script source, including the relevant `file.path` (when present) and the associated `user.id`.\n - Monitor for deviations from the established benign baseline, such as new script sources, new hosts, or materially different `powershell.file.script_block_text` structure or entropy characteristics.\n", + "query": "event.category:process and host.os.type:windows and\n powershell.file.script_block_entropy_bits >= 4.5 and\n powershell.file.script_block_text : (\n (\n \"System.IO.Compression.DeflateStream\" or\n \"System.IO.Compression.GzipStream\" or\n \"IO.Compression.DeflateStream\" or\n \"IO.Compression.GzipStream\"\n ) and\n FromBase64String\n ) and\n not user.id : \"S-1-5-18\"\n", + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.category", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_entropy_bits", + "type": "unknown" + }, + { + "ecs": false, + "name": "powershell.file.script_block_text", + "type": "unknown" + }, + { + "ecs": true, + "name": "user.id", + "type": "keyword" + } + ], + "risk_score": 73, + "rule_id": "81fe9dc6-a2d7-4192-a2d8-eed98afc766a", + "setup": "## Setup\n\nPowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104).\nSetup instructions: https://ela.st/powershell-logging-setup\n\nThis rule uses the following fields that require the Windows Integration v3.3.0 and up: `powershell.file.script_block_entropy_bits`.\n", + "severity": "high", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Resources: Investigation Guide", + "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": "query", + "version": 318 + }, + "id": "81fe9dc6-a2d7-4192-a2d8-eed98afc766a_318", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/83bf249e-4348-47ba-9741-1202a09556ad_211.json b/packages/security_detection_engine/kibana/security_rule/83bf249e-4348-47ba-9741-1202a09556ad_211.json new file mode 100644 index 00000000000..4c14642e5f5 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/83bf249e-4348-47ba-9741-1202a09556ad_211.json @@ -0,0 +1,144 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies the execution of PowerShell with suspicious argument values. This behavior is often observed during malware installation leveraging PowerShell.", + "from": "now-9m", + "index": [ + "logs-endpoint.events.process-*", + "logs-crowdstrike.fdr*", + "logs-m365_defender.event-*", + "logs-sentinel_one_cloud_funnel.*", + "logs-system.security*", + "logs-windows.forwarded*", + "logs-windows.sysmon_operational-*", + "winlogbeat-*", + "endgame-*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Suspicious Windows Powershell Arguments", + "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 Windows Powershell Arguments\n\nPowerShell is a powerful scripting language and command-line shell used for task automation and configuration management in Windows environments. Adversaries exploit PowerShell's capabilities to execute malicious scripts, download payloads, and obfuscate commands. The detection rule identifies unusual PowerShell arguments indicative of such abuse, focusing on patterns like encoded commands, suspicious downloads, and obfuscation techniques, thereby flagging potential threats for further investigation.\n\n### Possible investigation steps\n\n- Review the process command line and arguments to identify any encoded or obfuscated content, such as Base64 strings or unusual character sequences, which may indicate malicious intent.\n- Check the parent process of the PowerShell execution, especially if it is explorer.exe or cmd.exe, to determine if the PowerShell instance was launched from a suspicious or unexpected source.\n- Investigate any network activity associated with the PowerShell process, particularly looking for connections to known malicious domains or IP addresses, or the use of suspicious commands like DownloadFile or DownloadString.\n- Examine the user account associated with the PowerShell execution to determine if it aligns with expected behavior or if it might be compromised.\n- Correlate the event with other security alerts or logs from the same host or user to identify patterns or additional indicators of compromise.\n- Assess the risk and impact of the detected activity by considering the context of the environment, such as the presence of sensitive data or critical systems that might be affected.\n\n### False positive analysis\n\n- Legitimate administrative scripts may use encoded commands for obfuscation to protect sensitive data. Review the script's source and purpose to determine if it is authorized. If confirmed, add the script's hash or specific command pattern to an allowlist.\n- Automated software deployment tools might use PowerShell to download and execute scripts from trusted internal sources. Verify the source and destination of the download. If legitimate, exclude the specific tool or process from the detection rule.\n- System maintenance tasks often involve PowerShell scripts that manipulate files or system settings. Identify routine maintenance scripts and exclude their specific command patterns or file paths from triggering the rule.\n- Security software may use PowerShell for scanning or remediation tasks, which can mimic suspicious behavior. Confirm the software's legitimacy and add its processes to an exception list to prevent false alerts.\n- Developers might use PowerShell for testing or development purposes, which can include obfuscation techniques. Validate the developer's activities and exclude their specific development environments or scripts from the rule.\n\n### Response and remediation\n\n- Immediately isolate the affected system from the network to prevent further spread or communication with potential command and control servers.\n- Terminate any suspicious PowerShell processes identified by the detection rule to halt ongoing malicious activities.\n- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious payloads or scripts.\n- Review and clean up any unauthorized changes to system configurations or scheduled tasks that may have been altered by the malicious PowerShell activity.\n- Restore any affected files or system components from known good backups to ensure system integrity and functionality.\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- Implement additional monitoring and logging for PowerShell activities across the network to enhance detection of similar threats in the future.", + "query": "process where host.os.type == \"windows\" and event.type == \"start\" and\n process.name : \"powershell.exe\" and\n\n not (\n ?user.id == \"S-1-5-18\" and\n /* Don't apply the user.id exclusion to Sysmon for compatibility */\n not event.dataset : (\"windows.sysmon_operational\", \"windows.sysmon\")\n ) and\n\n not process.parent.executable : (\n \"?:\\\\Program Files\\\\*.exe\",\n \"?:\\\\Program Files (x86)\\\\*.exe\"\n ) and\n\n (\n process.command_line : (\n \"*^*^*^*^*^*^*^*^*^*\",\n \"*`*`*`*`*\",\n \"*+*+*+*+*+*+*\",\n \"*[char[]](*)*-join*\",\n \"*Base64String*\",\n \"*[*Convert]*\",\n \"*.Compression.*\",\n \"*-join($*\",\n \"*.replace*\",\n \"*MemoryStream*\",\n \"*WriteAllBytes*\",\n \"* -enc *\",\n \"* -ec *\",\n \"* /e *\",\n \"* /enc *\",\n \"* /ec *\",\n \"*WebClient*\",\n \"*DownloadFile*\",\n \"*DownloadString*\",\n \"* iex*\",\n \"* iwr*\",\n \"* aQB3AHIAIABpA*\",\n \"*Reflection.Assembly*\",\n \"*Assembly.GetType*\",\n \"*$env:temp\\\\*start*\",\n \"*powercat*\",\n \"*nslookup -q=txt*\",\n \"*$host.UI.PromptForCredential*\",\n \"*Net.Sockets.TCPClient*\",\n \"*curl *;Start*\",\n \"powershell.exe \\\"<#*\",\n \"*ssh -p *\",\n \"*http*|iex*\",\n \"*@SSL\\\\DavWWWRoot\\\\*.ps1*\",\n \"*.lnk*.Seek(0x*\",\n \"*[string]::join(*\",\n \"*[Array]::Reverse($*\",\n \"* hidden $(gc *\",\n \"*=wscri& set*\",\n \"*http'+'s://*\",\n \"*.content|i''Ex*\",\n \"*//:sptth*\",\n \"*//:ptth*\",\n \"*h''t''t''p*\",\n \"*'tp'':''/'*\",\n \"*$env:T\\\"E\\\"MP*\",\n \"*;cmd /c $?\",\n \"*s''t''a''r*\",\n \"*$*=Get-Content*AppData*.SubString(*$*\",\n \"*=cat *AppData*.substring(*);*$*\",\n \"*-join'';*|powershell*\",\n \"*.Content;sleep *|powershell*\",\n \"*h\\''t\\''tp:\\''*\",\n \"*-e aQB3AHIAIABp*\",\n \"*iwr *https*).Content*\",\n \"*$env:computername*http*\",\n \"*;InVoKe-ExpRESsIoN $COntent.CONTENt;*\",\n \"*WebClient*example.com*\",\n \"*=iwr $*;iex $*\",\n \"*ServerXmlHttp*IEX*\",\n \"*XmlDocument*IEX*\"\n ) or\n\n (process.args : \"-c\" and process.args : \"&{'*\") or\n\n (process.args : \"-Outfile\" and process.args : \"Start*\") or\n\n (process.args : \"-bxor\" and process.args : \"0x*\") or\n\n process.args : \"$*$*;set-alias\" or\n\n process.args == \"-e\" or\n\n // ATHPowerShellCommandLineParameter\n process.args : (\"-EncodedCommandParamVariation\", \"-UseEncodedArguments\", \"-CommandParamVariation\") or\n\n (\n process.parent.name : (\"explorer.exe\", \"cmd.exe\") and\n process.command_line : (\"*-encodedCommand*\", \"*Invoke-webrequest*\", \"*WebClient*\", \"*Reflection.Assembly*\"))\n ) and\n not process.command_line : (\n \"*Use-Icinga -Minimal*\",\n \"*& {$j = sajb {Add-Type -AssemblyName*\"\n )\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "windows", + "version": "^3.0.0" + }, + { + "package": "system", + "version": "^2.0.0" + }, + { + "package": "sentinel_one_cloud_funnel", + "version": "^1.0.0" + }, + { + "package": "m365_defender", + "version": "^3.0.0" + }, + { + "package": "crowdstrike", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.dataset", + "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" + }, + { + "ecs": true, + "name": "user.id", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "83bf249e-4348-47ba-9741-1202a09556ad", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Execution", + "Data Source: Windows Security Event Logs", + "Data Source: Elastic Defend", + "Data Source: Sysmon", + "Data Source: SentinelOne", + "Data Source: Microsoft Defender for Endpoint", + "Data Source: Crowdstrike", + "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": "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": "eql", + "version": 211 + }, + "id": "83bf249e-4348-47ba-9741-1202a09556ad_211", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/846fe13f-6772-4c83-bd39-9d16d4ad1a81_110.json b/packages/security_detection_engine/kibana/security_rule/846fe13f-6772-4c83-bd39-9d16d4ad1a81_110.json new file mode 100644 index 00000000000..1d41defae03 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/846fe13f-6772-4c83-bd39-9d16d4ad1a81_110.json @@ -0,0 +1,164 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "building_block_type": "default", + "description": "Identifies the use of Cmdlets and methods related to Microsoft Exchange Transport Agents install. Adversaries may leverage malicious Microsoft Exchange Transport Agents to execute tasks in response to adversary-defined criteria, establishing persistence.", + "filters": [ + { + "meta": { + "negate": true + }, + "query": { + "wildcard": { + "file.path": { + "case_insensitive": true, + "value": "?:\\\\Users\\\\*\\\\AppData\\\\Roaming\\\\Microsoft\\\\Exchange\\\\RemotePowerShell\\\\*" + } + } + } + }, + { + "meta": { + "negate": true + }, + "query": { + "wildcard": { + "file.path": { + "case_insensitive": true, + "value": "?:\\\\Users\\\\*\\\\AppData\\\\Local\\\\Temp\\\\tmp_????????.???\\\\tmp_????????.???.ps?1" + } + } + } + }, + { + "meta": { + "negate": true + }, + "query": { + "wildcard": { + "file.path": { + "case_insensitive": true, + "value": "?:\\\\Windows\\\\TEMP\\\\tmp_????????.???\\\\tmp_????????.???.ps?1" + } + } + } + }, + { + "meta": { + "negate": true + }, + "query": { + "wildcard": { + "file.path": { + "case_insensitive": true, + "value": "?:\\\\Users\\\\*\\\\AppData\\\\Local\\\\Temp\\\\*\\\\tmp_????????.???\\\\tmp_????????.???.ps?1" + } + } + } + } + ], + "from": "now-119m", + "index": [ + "winlogbeat-*", + "logs-windows.powershell*" + ], + "interval": "60m", + "language": "kuery", + "license": "Elastic License v2", + "name": "Deprecated - Microsoft Exchange Transport Agent Install Script", + "query": "event.category: \"process\" and host.os.type:windows and\n powershell.file.script_block_text : (\n (\n \"Install-TransportAgent\" or\n \"Enable-TransportAgent\"\n )\n ) and\n not user.id : \"S-1-5-18\" and\n not powershell.file.script_block_text : (\n \"'Install-TransportAgent', 'Invoke-MonitoringProbe', 'Mount-Database', 'Move-ActiveMailboxDatabase',\" or\n \"'Enable-TransportAgent', 'Enable-TransportRule', 'Export-ActiveSyncLog', 'Export-AutoDiscoverConfig',\" or\n (\"scriptCmd.GetSteppablePipeline\" and \"ForwardHelpTargetName Install-TransportAgent\")\n )\n", + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.category", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_text", + "type": "unknown" + }, + { + "ecs": true, + "name": "user.id", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "846fe13f-6772-4c83-bd39-9d16d4ad1a81", + "setup": "## Setup\n\nPowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104).\nSetup instructions: https://ela.st/powershell-logging-setup\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Persistence", + "Data Source: PowerShell Logs", + "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.002", + "name": "Transport Agent", + "reference": "https://attack.mitre.org/techniques/T1505/002/" + } + ] + } + ] + }, + { + "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": "query", + "version": 110 + }, + "id": "846fe13f-6772-4c83-bd39-9d16d4ad1a81_110", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/85e2d45e-a3df-4acf-83d3-21805f564ff4_4.json b/packages/security_detection_engine/kibana/security_rule/85e2d45e-a3df-4acf-83d3-21805f564ff4_4.json deleted file mode 100644 index c29736ee24d..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/85e2d45e-a3df-4acf-83d3-21805f564ff4_4.json +++ /dev/null @@ -1,143 +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", - "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Potential PowerShell Obfuscation via Character Array Reconstruction\n\nPowerShell, a powerful scripting language, is often targeted by adversaries for obfuscation to bypass security measures. By reconstructing strings from character arrays, attackers evade static analysis and detection. The detection rule identifies scripts using such obfuscation by searching for patterns indicative of character array manipulation, thus flagging potential threats for further investigation.\n\n### Possible investigation steps\n\n- Review the powershell.file.script_block_text field to understand the content and intent of the script, focusing on the obfuscated parts indicated by the presence of the \"char\" keyword and the \ud83d\udd25 character.\n- Examine the file.path and host.name fields to determine the origin and location of the script execution, which can provide context about the environment and potential risk.\n- Check the user.id and agent.id fields to identify the user and agent responsible for executing the script, which can help assess whether the activity is expected or suspicious.\n- Analyze the powershell.file.script_block_id and powershell.sequence fields to trace the execution sequence and correlate it with other related script blocks, providing a broader view of the script's behavior.\n- Investigate the count field to assess the extent of obfuscation, as a higher count may indicate more complex or extensive obfuscation techniques being used.\n\n### False positive analysis\n\n- Scripts used for legitimate administrative tasks may use character arrays for performance optimization or to handle special characters. Review the script's purpose and context to determine if it aligns with known administrative functions.\n- PowerShell scripts from trusted sources or vendors might use character arrays for legitimate obfuscation to protect intellectual property. Verify the script's origin and check for digital signatures or hashes to confirm authenticity.\n- Automated scripts generated by development tools or frameworks could include character array manipulation as part of their standard output. Identify and whitelist these tools if they are commonly used in your environment.\n- Security tools or monitoring solutions might use character arrays in their scripts for legitimate purposes. Cross-reference with known security software and consider excluding these from the detection rule if they are verified as safe.\n- Regularly update the exclusion list to include new trusted scripts or tools as they are introduced into the environment, ensuring that legitimate activities are not flagged as false positives.\n\n### Response and remediation\n\n- Isolate the affected host immediately to prevent further spread of potentially malicious scripts or unauthorized access.\n- Terminate any suspicious PowerShell processes identified by the alert to halt ongoing obfuscation activities.\n- Conduct a thorough review of the script block text and associated logs to identify any malicious payloads or commands executed.\n- Remove any identified malicious scripts or files from the affected system to prevent re-execution.\n- Reset credentials for any user accounts involved in the alert to mitigate potential credential compromise.\n- Update endpoint protection and ensure that AMSI and other security features are fully enabled and configured to detect similar threats.\n- Escalate the incident to the security operations center (SOC) for further analysis and to determine if additional systems are affected.\n", - "query": "from logs-windows.powershell_operational* metadata _id, _version, _index\n| where event.code == \"4104\"\n\n// Filter for scripts that contain the \"char\" keyword using MATCH, boosts the query performance\n| where powershell.file.script_block_text : \"char\"\n\n// replace the patterns we are looking for with the \ud83d\udd25 emoji to enable counting them\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| eval Esql.script_block_tmp = replace(\n powershell.file.script_block_text,\n \"\"\"(char\\[\\]\\]\\(\\d+,\\d+[^)]+|(\\s?\\(\\[char\\]\\d+\\s?\\)\\+){2,})\"\"\",\n \"\ud83d\udd25\"\n)\n\n// count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| eval Esql.script_block_pattern_count = length(Esql.script_block_tmp) - length(replace(Esql.script_block_tmp, \"\ud83d\udd25\", \"\"))\n\n// keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| keep\n Esql.script_block_pattern_count,\n Esql.script_block_tmp,\n powershell.file.script_block_text,\n powershell.file.script_block_id,\n file.path,\n powershell.sequence,\n powershell.total,\n _id,\n _index,\n host.name,\n agent.id,\n user.id\n\n// Filter for scripts that match the pattern at least once\n| where Esql.script_block_pattern_count >= 1\n", - "related_integrations": [ - { - "package": "windows", - "version": "^3.0.0" - } - ], - "required_fields": [ - { - "ecs": false, - "name": "Esql.script_block_pattern_count", - "type": "integer" - }, - { - "ecs": false, - "name": "Esql.script_block_tmp", - "type": "keyword" - }, - { - "ecs": false, - "name": "_id", - "type": "keyword" - }, - { - "ecs": false, - "name": "_index", - "type": "keyword" - }, - { - "ecs": true, - "name": "agent.id", - "type": "keyword" - }, - { - "ecs": true, - "name": "file.path", - "type": "keyword" - }, - { - "ecs": true, - "name": "host.name", - "type": "keyword" - }, - { - "ecs": false, - "name": "powershell.file.script_block_id", - "type": "keyword" - }, - { - "ecs": false, - "name": "powershell.file.script_block_text", - "type": "text" - }, - { - "ecs": false, - "name": "powershell.sequence", - "type": "long" - }, - { - "ecs": false, - "name": "powershell.total", - "type": "long" - }, - { - "ecs": true, - "name": "user.id", - "type": "keyword" - } - ], - "risk_score": 21, - "rule_id": "85e2d45e-a3df-4acf-83d3-21805f564ff4", - "setup": "## Setup\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nAdministrative Templates >\nWindows PowerShell >\nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n", - "severity": "low", - "tags": [ - "Domain: Endpoint", - "OS: Windows", - "Use Case: Threat Detection", - "Tactic: Defense Evasion", - "Data Source: PowerShell Logs", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0005", - "name": "Defense Evasion", - "reference": "https://attack.mitre.org/tactics/TA0005/" - }, - "technique": [ - { - "id": "T1027", - "name": "Obfuscated Files or Information", - "reference": "https://attack.mitre.org/techniques/T1027/" - }, - { - "id": "T1140", - "name": "Deobfuscate/Decode Files or Information", - "reference": "https://attack.mitre.org/techniques/T1140/" - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0002", - "name": "Execution", - "reference": "https://attack.mitre.org/tactics/TA0002/" - }, - "technique": [ - { - "id": "T1059", - "name": "Command and Scripting Interpreter", - "reference": "https://attack.mitre.org/techniques/T1059/", - "subtechnique": [ - { - "id": "T1059.001", - "name": "PowerShell", - "reference": "https://attack.mitre.org/techniques/T1059/001/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 4 - }, - "id": "85e2d45e-a3df-4acf-83d3-21805f564ff4_4", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/85e2d45e-a3df-4acf-83d3-21805f564ff4_8.json b/packages/security_detection_engine/kibana/security_rule/85e2d45e-a3df-4acf-83d3-21805f564ff4_8.json new file mode 100644 index 00000000000..b8519a776c0 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/85e2d45e-a3df-4acf-83d3-21805f564ff4_8.json @@ -0,0 +1,202 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects PowerShell scripts that reconstructs strings from char[] arrays, index lookups, or repeated ([char]NN)+ concatenation/join logic. Attackers use character-array reconstruction to hide commands, URLs, or payloads and evade static analysis and AMSI.", + "from": "now-9m", + "investigation_fields": { + "field_names": [ + "@timestamp", + "user.name", + "user.id", + "user.domain", + "powershell.file.script_block_text", + "powershell.file.script_block_id", + "powershell.sequence", + "powershell.total", + "file.path", + "file.directory", + "file.name", + "process.pid", + "host.name", + "host.id", + "powershell.file.script_block_length" + ] + }, + "language": "esql", + "license": "Elastic License v2", + "name": "Potential PowerShell Obfuscation via Character Array Reconstruction", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This guide was created by humans with the assistance of generative AI. While its contents have been manually curated to include the most valuable information, always validate assumptions and adjust procedures to match your internal runbooks and incident triage and response policies.\n\n### Investigating Potential PowerShell Obfuscation via Character Array Reconstruction\n\nThis rule identifies PowerShell Script Block Logging content that reconstructs strings at runtime from character codes or character arrays. This technique is commonly used to conceal intent (for example, commands, URLs, or file paths) and can indicate attempts to evade static inspection.\n\nFocus triage on what strings are being rebuilt, who ran the script, where it ran, and whether the decoded content leads to follow-on activity.\n\n#### Key alert fields to review\n\n- `user.name`, `user.domain`, `user.id`: Account execution context for correlation, prioritization, and scoping.\n- `host.name`, `host.id`: Host execution context for correlation, prioritization, and scoping.\n- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file.\n- `powershell.file.script_block_text`: Script block content that matched the detection logic.\n- `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`: Script block metadata to pivot to other fragments or reconstruct full script content when split across multiple events.\n- `Esql.script_block_tmp`: Transformed script block where detection patterns replace original content with a marker to support scoring/counting and quickly spot match locations.\n- `Esql.script_block_pattern_count`: Count of matches for the detection pattern(s) observed in the script block content.\n- `powershell.file.script_block_entropy_bits`: Shannon entropy of the script block. Higher values may indicate obfuscation.\n- `powershell.file.script_block_surprisal_stdev`: Standard deviation of surprisal across the script block. Low values indicate uniform randomness. High values indicate mixed patterns and variability.\n- `powershell.file.script_block_unique_symbols`: Count of distinct characters present in the script block.\n- `powershell.file.script_block_length`: Script block length (size) context.\n\n#### Possible investigation steps\n\n- Review `powershell.file.script_block_text` and use `Esql.script_block_tmp` to quickly spot the segments that triggered the match. Identify the reconstruction method (for example, `[char[]](...)`, repeated `([char]NN)+` concatenation, joins, or index-based lookups).\n- If the script block is split, reconstruct the full content using `powershell.file.script_block_id` together with `powershell.sequence` and `powershell.total`. Verify that all expected sequences are present and in order before drawing conclusions.\n- If `powershell.total` indicates multiple fragments but one or more `powershell.sequence` values are missing, treat the script as incomplete context. Attempt to retrieve the missing fragments and consider the possibility of log gaps or ingestion delays.\n- Deobfuscate the reconstructed strings by translating numeric character codes and arrays into their resulting text. Capture any decoded values that look like commands, script content, URLs, file paths, registry paths, or encoded blobs.\n- After decoding, re-review the full script block content for additional obfuscation layers or execution logic that is not covered by the character reconstruction pattern (for example, secondary decoding steps or dynamically-invoked script).\n- Use `Esql.script_block_pattern_count` as a quick measure of how heavily the script relies on this obfuscation pattern. Higher counts typically indicate more deliberate concealment and can help prioritize review.\n- Use the script statistics to support prioritization and comparison against expected baselines: `powershell.file.script_block_entropy_bits`, `powershell.file.script_block_surprisal_stdev`, `powershell.file.script_block_unique_symbols`, and `powershell.file.script_block_length`. Look for unusually long, high-entropy, or highly variable content relative to known-good PowerShell activity in your environment.\n- Review the execution context: `user.name`, `user.domain`, and `user.id` to understand who executed the script and whether the account matches expected administrative or automation usage for the `host.name` and `host.id` involved.\n- Review file origin indicators when present: `file.path`, `file.directory`, and `file.name`. Assess whether the script appears to originate from an expected location for your environment versus a user-writable, temporary, or unusual directory.\n- Pivot to the source event using `_id` and `_index` to review the full event payload and confirm whether additional relevant `powershell.file.*` context is available for analysis.\n- Scope for related activity by searching for additional script blocks that share the same `powershell.file.script_block_id`, similar `powershell.file.script_block_text` content, the same `file.path`, the same `user.id`, or the same `host.id` around the alert time window.\n- Correlate the alert timestamp with adjacent telemetry from the same host and user (process activity, network connections, file writes, registry modifications, and authentication events) to identify how PowerShell was launched (including the initiating/parent process) and what occurred immediately before and after the obfuscated content executed.\n- If decoded content indicates external communication or secondary payload retrieval, identify potential indicators (domains, IPs, URLs, file names) and check for additional occurrences across other hosts and users.\n- If decoded content indicates credential access, lateral movement, or persistence, expand the investigation to related accounts and hosts within the same timeframe and document the full execution chain.\n\n### False positive analysis\n\n- Some benign scripts reconstruct strings from character codes for formatting, localization, or to safely represent special characters. These cases are often limited in scope and decode to human-readable, expected values.\n- Software deployment, management, or monitoring tooling may generate PowerShell dynamically and use string reconstruction as an implementation detail. Validate whether the script source (`file.path`) and execution context (`user.id`, `host.id`) align with known tooling behavior.\n- Internal scripts may use light obfuscation to reduce casual tampering or to embed configuration values. Treat unknown sources, unexpected accounts, or unusually high `Esql.script_block_pattern_count` / `powershell.file.script_block_entropy_bits` as higher risk until validated.\n- If determined benign, document the script source and expected execution context (account and host) and retain the decoded strings for faster triage of future alerts.\n\n### Response and remediation\n\n- If malicious or suspicious activity is confirmed, contain the affected host to prevent additional execution and lateral movement. Consider restricting the involved account based on investigation results.\n- Preserve evidence: retain the full `powershell.file.script_block_text` and any reconstructed/decoded strings, along with related events for the same `powershell.file.script_block_id` (all `powershell.sequence` values).\n- If the script originates from disk (`file.path` present), collect and quarantine the referenced file and review for additional related artifacts created or modified around the alert time window.\n- Identify and remediate follow-on actions indicated by the decoded content (for example, downloaded payloads, persistence mechanisms, or changes to system configuration).\n- Hunt for spread: search for the same decoded indicators, similar reconstruction patterns, and elevated `Esql.script_block_pattern_count` across other hosts and users.\n- If account misuse is suspected, perform appropriate credential hygiene and review recent authentication activity for the affected `user.id` and related accounts.\n- Review and strengthen PowerShell controls and monitoring based on findings (for example, ensure Script Block Logging is consistently enabled and that anti-malware scanning integration is functioning as expected).\n", + "query": "from logs-windows.powershell_operational* metadata _id, _version, _index\n| where event.code == \"4104\"\n\n// Filter for scripts that contain the \"char\" keyword using MATCH, boosts the query performance\n| where powershell.file.script_block_text : \"char\"\n\n// replace the patterns we are looking for with the \ud83d\udd25 emoji to enable counting them\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| eval Esql.script_block_tmp = replace(\n powershell.file.script_block_text,\n \"\"\"(char\\[\\]\\]\\(\\d+,\\d+[^)]+|(\\s?\\(\\[char\\]\\d+\\s?\\)\\+){2,})\"\"\",\n \"\ud83d\udd25\"\n)\n\n// count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| eval Esql.script_block_pattern_count = length(Esql.script_block_tmp) - length(replace(Esql.script_block_tmp, \"\ud83d\udd25\", \"\"))\n\n// keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| keep\n Esql.script_block_pattern_count,\n Esql.script_block_tmp,\n powershell.file.*,\n file.path,\n powershell.sequence,\n powershell.total,\n _id,\n _version,\n _index,\n host.name,\n host.id,\n agent.id,\n user.id\n\n// Filter for scripts that match the pattern at least once\n| where Esql.script_block_pattern_count >= 1\n", + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.script_block_pattern_count", + "type": "integer" + }, + { + "ecs": false, + "name": "Esql.script_block_tmp", + "type": "keyword" + }, + { + "ecs": false, + "name": "_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "_index", + "type": "keyword" + }, + { + "ecs": false, + "name": "_version", + "type": "long" + }, + { + "ecs": true, + "name": "agent.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.path", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.name", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_entropy_bits", + "type": "double" + }, + { + "ecs": false, + "name": "powershell.file.script_block_entropy_normalized", + "type": "double" + }, + { + "ecs": false, + "name": "powershell.file.script_block_hash", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_length", + "type": "long" + }, + { + "ecs": false, + "name": "powershell.file.script_block_surprisal_stdev", + "type": "double" + }, + { + "ecs": false, + "name": "powershell.file.script_block_text", + "type": "text" + }, + { + "ecs": false, + "name": "powershell.file.script_block_unique_symbols", + "type": "long" + }, + { + "ecs": false, + "name": "powershell.sequence", + "type": "long" + }, + { + "ecs": false, + "name": "powershell.total", + "type": "long" + }, + { + "ecs": true, + "name": "user.id", + "type": "keyword" + } + ], + "risk_score": 73, + "rule_id": "85e2d45e-a3df-4acf-83d3-21805f564ff4", + "setup": "## Setup\n\nPowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104).\nSetup instructions: https://ela.st/powershell-logging-setup\n", + "severity": "high", + "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": 8 + }, + "id": "85e2d45e-a3df-4acf-83d3-21805f564ff4_8", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/870aecc0-cea4-4110-af3f-e02e9b373655_110.json b/packages/security_detection_engine/kibana/security_rule/870aecc0-cea4-4110-af3f-e02e9b373655_110.json deleted file mode 100644 index 04bd3a38081..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/870aecc0-cea4-4110-af3f-e02e9b373655_110.json +++ /dev/null @@ -1,111 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies the use of the grep command to discover known third-party macOS and Linux security tools, such as Antivirus or Host Firewall details.", - "false_positives": [ - "Endpoint Security installers, updaters and post installation verification scripts." - ], - "from": "now-9m", - "index": [ - "logs-endpoint.events.*", - "auditbeat-*" - ], - "language": "eql", - "license": "Elastic License v2", - "name": "Security Software Discovery via Grep", - "note": "## Triage and analysis\n\n### Investigating Security Software Discovery via Grep\n\nAfter successfully compromising an environment, attackers may try to gain situational awareness to plan their next steps. This can happen by running commands to enumerate network resources, users, connections, files, and installed security software.\n\nThis rule looks for the execution of the `grep` utility with arguments compatible to the enumeration of the security software installed on the host. Attackers can use this information to decide whether or not to infect a system, disable protections, use bypasses, etc.\n\n#### Possible investigation steps\n\n- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence and whether they are located in expected locations.\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- Inspect the host for suspicious or abnormal behavior in the alert timeframe.\n- Validate the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations.\n\n### False positive analysis\n\n- Discovery activities are not inherently malicious if they occur in isolation. As long as the analyst did not identify suspicious activity related to the user or host, such alerts can be dismissed.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Isolate the involved hosts 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 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": "process where event.type == \"start\" and\nprocess.name : \"grep\" and user.id != \"0\" and\n not process.parent.executable : (\"/Library/Application Support/*\", \"/opt/McAfee/agent/scripts/ma\") and\n process.args :\n (\"Little Snitch*\",\n \"Avast*\",\n \"Avira*\",\n \"ESET*\",\n \"BlockBlock*\",\n \"360Sec*\",\n \"LuLu*\",\n \"KnockKnock*\",\n \"kav\",\n \"KIS\",\n \"RTProtectionDaemon*\",\n \"Malware*\",\n \"VShieldScanner*\",\n \"WebProtection*\",\n \"webinspectord*\",\n \"McAfee*\",\n \"isecespd*\",\n \"macmnsvc*\",\n \"masvc*\",\n \"kesl*\",\n \"avscan*\",\n \"guard*\",\n \"rtvscand*\",\n \"symcfgd*\",\n \"scmdaemon*\",\n \"symantec*\",\n \"sophos*\",\n \"osquery*\",\n \"elastic-endpoint*\"\n ) and\n not (\n (process.args : \"Avast\" and process.args : \"Passwords\") or\n (process.args == \"osquery.conf\") or \n (process.parent.args : \"/opt/McAfee/agent/scripts/ma\" and process.parent.args : \"checkhealth\") or\n (process.command_line : (\n \"grep ESET Command-line scanner, version %s -A2\",\n \"grep -i McAfee Web Gateway Core version:\",\n \"grep --color=auto ESET Command-line scanner, version %s -A2\"\n )\n ) or\n (process.parent.command_line : (\n \"\"\"sh -c printf \"command_start_%s\"*; perl -pe 's/[^ -~]/\\n/g' < /opt/eset/esets/sbin/esets_scan | grep 'ESET Command-line scanner, version %s' -A2 | tail -1; printf \"command_done_%s*\"\"\",\n \"\"\"bash -c perl -pe 's/[^ -~]/\\n/g' < /opt/eset/esets/sbin/esets_scan | grep 'ESET Command-line scanner, version %s' -A2 | tail -1\"\"\"\n )\n )\n )\n", - "related_integrations": [ - { - "package": "endpoint", - "version": "^8.2.0" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "event.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.executable", - "type": "keyword" - }, - { - "ecs": true, - "name": "user.id", - "type": "keyword" - } - ], - "risk_score": 47, - "rule_id": "870aecc0-cea4-4110-af3f-e02e9b373655", - "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: macOS", - "OS: Linux", - "Use Case: Threat Detection", - "Tactic: Discovery", - "Resources: Investigation Guide", - "Data Source: Elastic Defend" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0007", - "name": "Discovery", - "reference": "https://attack.mitre.org/tactics/TA0007/" - }, - "technique": [ - { - "id": "T1518", - "name": "Software Discovery", - "reference": "https://attack.mitre.org/techniques/T1518/", - "subtechnique": [ - { - "id": "T1518.001", - "name": "Security Software Discovery", - "reference": "https://attack.mitre.org/techniques/T1518/001/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "eql", - "version": 110 - }, - "id": "870aecc0-cea4-4110-af3f-e02e9b373655_110", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/89f9a4b0-9f8f-4ee0-8823-c4751a6d6696_213.json b/packages/security_detection_engine/kibana/security_rule/89f9a4b0-9f8f-4ee0-8823-c4751a6d6696_213.json new file mode 100644 index 00000000000..c9bc4e89bf5 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/89f9a4b0-9f8f-4ee0-8823-c4751a6d6696_213.json @@ -0,0 +1,142 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies a network connection by the command prompt (cmd.exe) when it is executed with specific arguments, such as a script or a URL, or when it is spawned by Microsoft Office applications. Adversaries often abuse cmd.exe to download malicious payloads or establish command and control channels from a remote source.", + "from": "now-9m", + "index": [ + "winlogbeat-*", + "logs-endpoint.events.process-*", + "logs-endpoint.events.network-*", + "logs-windows.sysmon_operational-*", + "logs-sentinel_one_cloud_funnel.*" + ], + "investigation_fields": { + "field_names": [ + "@timestamp", + "host.name", + "host.id", + "user.name", + "user.domain", + "user.id", + "process.entity_id", + "process.name", + "process.parent.name" + ] + }, + "language": "eql", + "license": "Elastic License v2", + "name": "Suspicious Command Prompt Network Connection", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Suspicious Command Prompt Network Connection\n\nThis alert identifies a Windows `cmd.exe` process start event that is quickly followed by a network connection from the same `cmd.exe` instance (`process.entity_id`). The command line indicates scripted execution (batch files), references to remote resources (URL-like strings), or execution launched by a Microsoft Office application. This pattern can be used to download payloads, stage execution, or establish command and control.\n\n#### Triage and analysis steps\n\n- Confirm the matched sequence and keep analysis tied to the correct process instance:\n - Use the `Investigate in timeline` button in the Alerts table or pivot on `process.entity_id` to review both the process start event and the associated network event(s).\n - Example KQL pivots:\n - `process.entity_id:\"\" and event.category:process`\n - `process.entity_id:\"\" and event.category:network`\n\n- Determine why `cmd.exe` matched and assess intent:\n - Review `process.args` to confirm the interpreter switch (`/c` to execute and exit, `/k` to remain open).\n - Identify which match condition applies:\n - Batch script: `process.args` includes a `.bat` or `.cmd` reference.\n - Remote resource: `process.command_line` contains `http://`, `https://`, or `ftp://`.\n - Office parent: `process.parent.name` is one of `winword.exe`, `excel.exe`, `powerpnt.exe`, `outlook.exe`, `msaccess.exe`, or `mspub.exe`.\n - Look for staging or obfuscation patterns in `process.command_line` (for example: `&`/`&&`/`||`, pipes `|`, redirection `>`/`>>`, escaping `^`, environment variables, or long encoded strings).\n\n- Validate the execution context and launch vector:\n - Review `user.*` fields to determine who ran the command and whether it is expected for the host role.\n - Review `process.parent.name` (and `process.parent.command_line` if available) to understand the initial trigger:\n - Office parent: prioritize identifying the initiating document or message and any user interaction around `@timestamp`.\n - Management tooling or installer parent: validate change control and whether the command line and destination are consistent with that software.\n - If a batch script is referenced, locate the script on the host (if telemetry allows) and capture path and hash (`file.path`, `file.hash.sha256`) for scoping.\n\n- Analyze the outbound destination:\n - Review `destination.ip` and `destination.port` for expectedness (business relationship, known vendor, or organization-owned public IP space).\n - Note: the rule excludes common private and reserved address ranges, but it can still alert on connections to legitimate public services.\n - Pivot on `destination.ip` to identify other hosts contacting the same destination near `@timestamp`:\n - `destination.ip:\"\" and event.category:network`\n - Check whether the same `process.entity_id` generated repeated connections (potential beaconing) versus a single connection (one-time retrieval).\n\n- Reconstruct follow-on activity and potential impact:\n - Identify child processes spawned by `cmd.exe` and look for common follow-on tooling (for example: `powershell.exe`, `mshta.exe`, `rundll32.exe`, `regsvr32.exe`, `certutil.exe`, `bitsadmin.exe`, `curl.exe`, `wget.exe`).\n - If file telemetry is available, review file creation/modification shortly after `@timestamp` and correlate any new binaries or scripts with hashes and execution events.\n\n- Scope the activity (blast radius):\n - Search for the same `process.command_line` (or distinctive substrings), script name, or extracted URL across endpoints.\n - Search for other `cmd.exe` instances connecting to the same `destination.ip` or the same destination port/protocol.\n - If the parent is Office, scope for the same parent-child relationship (`process.parent.name` -> `cmd.exe`) across users and hosts.\n\n### False positive analysis\n\n- Software deployment, packaging, or endpoint management workflows that use `cmd.exe /c` to run batch scripts and contact vendor services.\n- Signed installer or updater activity where `cmd.exe` is used as a helper process with stable command lines.\n- Documented Office macros/add-ins/templates that legitimately spawn `cmd.exe` with consistent command lines and destinations.\n\nA benign determination is more likely when the combination of `process.parent.name`, stable `process.command_line`, and consistent `destination.ip`/`destination.port` repeats across an expected set of hosts and users and aligns to a documented workflow owner.\n\n### Response and remediation\n\n- If the activity is suspicious or cannot be attributed to an approved workflow:\n - Contain the affected endpoint (`host.id`) using available endpoint or network controls.\n - Preserve evidence (at minimum):\n - `@timestamp`, `host.*`, `user.*`\n - `process.entity_id`, `process.command_line`, `process.args`, `process.parent.*`\n - `destination.ip`, `destination.port`, `network.*`\n - Any related child processes and file artifacts (paths and hashes) identified during triage\n - Scope for related activity by searching for additional occurrences of the same destination and command-line patterns.\n - If Office is the launch vector, identify and quarantine the initiating document or email and assess whether similar content was delivered to other users.\n - If a script is involved, collect and review the script contents and investigate how it was introduced (downloads, email attachments, shared drives, logon scripts, scheduled tasks).\n - If account compromise is suspected, follow established identity response procedures (credential reset, session review, and access auditing).\n\n- If the activity is confirmed benign:\n - Document the expected parent process, command-line pattern, and destinations.\n - Consider adding a narrowly scoped exception using stable identifiers and constrained conditions (for example, specific `process.command_line` patterns and known destinations) to reduce recurring noise.\n", + "query": "sequence by process.entity_id with maxspan=15s\n [process where host.os.type == \"windows\" and event.type == \"start\" and\n process.name : \"cmd.exe\" and process.args : (\"/c\", \"/k\") and\n (\n process.args : (\"*.bat\", \"*.cmd\") or\n process.command_line : (\"*http://*\", \"*https://*\", \"*ftp://*\") or\n process.parent.name : (\"excel.exe\", \"msaccess.exe\", \"mspub.exe\", \"powerpnt.exe\", \"winword.exe\", \"outlook.exe\")\n )\n ]\n [network where host.os.type == \"windows\" and process.name : \"cmd.exe\" and\n not cidrmatch(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\",\n \"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\",\n \"192.0.0.171/32\", \"192.0.2.0/24\", \"192.31.196.0/24\", \"192.52.193.0/24\",\n \"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\",\n \"198.18.0.0/15\", \"198.51.100.0/24\", \"203.0.113.0/24\", \"240.0.0.0/4\", \"::1\",\n \"FE80::/10\", \"FF00::/8\")]\n", + "references": [ + "https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "windows", + "version": "^3.0.0" + }, + { + "package": "sentinel_one_cloud_funnel", + "version": "^1.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "destination.ip", + "type": "ip" + }, + { + "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" + }, + { + "ecs": true, + "name": "process.parent.name", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "89f9a4b0-9f8f-4ee0-8823-c4751a6d6696", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Execution", + "Resources: Investigation Guide", + "Data Source: Elastic Defend", + "Data Source: Sysmon", + "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/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0011", + "name": "Command and Control", + "reference": "https://attack.mitre.org/tactics/TA0011/" + }, + "technique": [ + { + "id": "T1105", + "name": "Ingress Tool Transfer", + "reference": "https://attack.mitre.org/techniques/T1105/" + } + ] + } + ], + "type": "eql", + "version": 213 + }, + "id": "89f9a4b0-9f8f-4ee0-8823-c4751a6d6696_213", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/8a1d4831-3ce6-4859-9891-28931fa6101d_212.json b/packages/security_detection_engine/kibana/security_rule/8a1d4831-3ce6-4859-9891-28931fa6101d_212.json new file mode 100644 index 00000000000..eec4602c355 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/8a1d4831-3ce6-4859-9891-28931fa6101d_212.json @@ -0,0 +1,149 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies when a script interpreter or signed binary is launched via a non-standard working directory. An attacker may use this technique to evade defenses.", + "from": "now-9m", + "index": [ + "winlogbeat-*", + "logs-endpoint.events.process-*", + "logs-windows.sysmon_operational-*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Suspicious Execution from a Mounted Device", + "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 Execution from a Mounted Device\n\nIn Windows environments, script interpreters and signed binaries are essential for executing legitimate tasks. However, adversaries can exploit these by launching them from non-standard directories, such as mounted devices, to bypass security measures. The detection rule identifies such anomalies by monitoring processes initiated from unexpected directories, especially when triggered by common parent processes like explorer.exe, thus flagging potential defense evasion attempts.\n\n### Possible investigation steps\n\n- Review the process details to confirm the executable path and working directory, ensuring they match the criteria of being launched from a non-standard directory (e.g., not from \"C:\\\\\").\n- Investigate the parent process, explorer.exe, to determine if there are any unusual activities or user actions that might have triggered the suspicious execution.\n- Check the user account associated with the process to verify if the activity aligns with their typical behavior or if the account might be compromised.\n- Analyze the command line arguments used by the suspicious process to identify any potentially malicious scripts or commands being executed.\n- Correlate the event with other security alerts or logs from the same host to identify any patterns or additional indicators of compromise.\n- Examine the mounted device from which the process was executed to determine its origin, legitimacy, and any associated files that might be malicious.\n\n### False positive analysis\n\n- Legitimate software installations or updates may trigger the rule if they are executed from a mounted device. Users can create exceptions for known software update processes that are verified as safe.\n- Portable applications running from USB drives or external storage can be flagged. To mitigate this, users should whitelist specific applications that are frequently used and deemed non-threatening.\n- IT administrative scripts executed from network shares or mounted drives for maintenance tasks might be detected. Users can exclude these scripts by specifying trusted network paths or script names.\n- Development environments where scripts are tested from non-standard directories can cause alerts. Developers should ensure their working directories are recognized as safe or use designated development machines with adjusted monitoring rules.\n- Backup or recovery operations that utilize mounted devices for script execution may be misidentified. Users should identify and exclude these operations by defining exceptions for known backup tools and processes.\n\n### Response and remediation\n\n- Isolate the affected system from the network to prevent further malicious activity and lateral movement.\n- Terminate any suspicious processes identified by the detection rule, such as those initiated by script interpreters or signed binaries from non-standard directories.\n- Conduct a forensic analysis of the mounted device and the affected system to identify any malicious payloads or scripts and remove them.\n- Review and restore any altered system configurations or registry settings to their original state to ensure system integrity.\n- Update and patch the system to close any vulnerabilities that may have been exploited by the attacker.\n- Monitor for any recurrence of similar activities by enhancing logging and alerting mechanisms, focusing on process execution from non-standard directories.\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": "process where host.os.type == \"windows\" and event.type == \"start\" and process.executable : \"C:\\\\*\" and\n (\n process.working_directory : (\"D:\\\\*\", \"E:\\\\*\", \"F:\\\\*\") or\n ?process.Ext.device.product_id : (\"Virtual DVD-ROM\", \"Virtual Disk\")\n ) and\n process.parent.name : \"explorer.exe\" and\n process.name : (\n \"rundll32.exe\", \"mshta.exe\", \"powershell.exe\", \"pwsh.exe\", \"cmd.exe\", \"regsvr32.exe\", \"cscript.exe\",\n \"wscript.exe\", \"certutil.exe\", \"bitsadmin.exe\", \"msiexec.exe\", \"wmic.exe\", \"schtasks.exe\", \"msbuild.exe\"\n )\n", + "references": [ + "https://www.microsoft.com/security/blog/2021/05/27/new-sophisticated-email-based-attack-from-nobelium/", + "https://www.volexity.com/blog/2021/05/27/suspected-apt29-operation-launches-election-fraud-themed-phishing-campaigns/" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": false, + "name": "process.Ext.device.product_id", + "type": "unknown" + }, + { + "ecs": true, + "name": "process.executable", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.working_directory", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "8a1d4831-3ce6-4859-9891-28931fa6101d", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Tactic: Execution", + "Data Source: Elastic Defend", + "Data Source: Sysmon", + "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/", + "subtechnique": [ + { + "id": "T1218.005", + "name": "Mshta", + "reference": "https://attack.mitre.org/techniques/T1218/005/" + }, + { + "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/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.001", + "name": "PowerShell", + "reference": "https://attack.mitre.org/techniques/T1059/001/" + }, + { + "id": "T1059.003", + "name": "Windows Command Shell", + "reference": "https://attack.mitre.org/techniques/T1059/003/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 212 + }, + "id": "8a1d4831-3ce6-4859-9891-28931fa6101d_212", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/8d4d0a23-19d3-4186-a6f1-6f0760d2e070_2.json b/packages/security_detection_engine/kibana/security_rule/8d4d0a23-19d3-4186-a6f1-6f0760d2e070_2.json new file mode 100644 index 00000000000..528d9fd55fa --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/8d4d0a23-19d3-4186-a6f1-6f0760d2e070_2.json @@ -0,0 +1,114 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule uses alert data to determine when multiple external EDR alerts 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 External EDR Alerts 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 Multiple External EDR Alerts by Host\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 .alerts-security.*\n| WHERE event.dataset in (\"crowdstrike.alert\", \"crowdstrike.falcon\", \"sentinel_one.alert\", \"sentinel_one.threat\", \"m365_defender.alert\") and\n host.id is not null and kibana.alert.risk_score > 21 and\n not (event.module == \"crowdstrike\" and (kibana.alert.rule.name like \"* at *\" or kibana.alert.rule.name like \"* on *\" or kibana.alert.rule.name == \"EICARTestFileWrittenWin\")) and\n not KQL(\"\"\"kibana.alert.rule.tags : \"Rule Type: Higher-Order Rule\" \"\"\")\n| stats Esql.alerts_count = COUNT(*),\n Esql.rule_risk_score_distinct_count = COUNT_DISTINCT(kibana.alert.risk_score),\n Esql.unique_rules_count = COUNT_DISTINCT(kibana.alert.rule.name),\n Esql.processes_count = COUNT_DISTINCT(process.executable),\n Esql.files_count = COUNT_DISTINCT(file.path),\n Esql.process_cmdline_count = COUNT_DISTINCT(process.command_line),\n Esql.rule_risk_score_values = VALUES(kibana.alert.risk_score),\n Esql.process_path_values = VALUES(process.executable),\n Esql.file_path_values = VALUES(file.path),\n Esql.user_name_values = VALUES(user.name),\n Esql.process_command_line_values = VALUES(process.command_line),\n Esql.process_parent_command_line_values = VALUES(process.parent.command_line),\n Esql.rule_name_values = VALUES(kibana.alert.rule.name) by host.id, host.name, event.module\n| where (\n\t// 3+ unique rules or processes\n (\n Esql.unique_rules_count >= 3 or\n (Esql.processes_count >= 3 and Esql.rule_name_values == \"External Alerts\")\n ) and\n \t// and 2+ rules of different severity, or 1 high/critical severity rule\n (\n Esql.rule_risk_score_distinct_count >= 2 or\n Esql.rule_risk_score_values == 73 or\n Esql.rule_risk_score_values == 99\n )\n) or\n // or 5+ unique rules from the same host for 1+ path/command_line/process\n (Esql.unique_rules_count >= 5 and Esql.alerts_count <= 50 and\n (Esql.files_count >= 1 or Esql.process_cmdline_count >= 1 or Esql.processes_count >= 1)\n)\n| KEEP event.module, host.id, host.name, Esql.*\n", + "references": [ + "https://github.com/elastic/detection-rules/blob/main/rules/promotions/external_alerts.toml" + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.alerts_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.file_path_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.files_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.process_cmdline_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.process_command_line_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.process_parent_command_line_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.process_path_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.processes_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.rule_name_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.rule_risk_score_distinct_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.rule_risk_score_values", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.unique_rules_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.user_name_values", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.module", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.name", + "type": "keyword" + } + ], + "risk_score": 73, + "rule_id": "8d4d0a23-19d3-4186-a6f1-6f0760d2e070", + "severity": "high", + "tags": [ + "Use Case: Threat Detection", + "Rule Type: Higher-Order Rule", + "Resources: Investigation Guide", + "Domain: Endpoint" + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 2 + }, + "id": "8d4d0a23-19d3-4186-a6f1-6f0760d2e070_2", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/8e7a4f2c-9b3d-4e5a-a1b6-c2d8f7e9b3a5_4.json b/packages/security_detection_engine/kibana/security_rule/8e7a4f2c-9b3d-4e5a-a1b6-c2d8f7e9b3a5_4.json new file mode 100644 index 00000000000..800825e5ed3 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/8e7a4f2c-9b3d-4e5a-a1b6-c2d8f7e9b3a5_4.json @@ -0,0 +1,859 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies potential abuse of actor tokens in Microsoft Entra ID audit logs. Actor tokens are undocumented backend mechanisms used by Microsoft for service-to-service (S2S) operations, allowing services to perform actions on behalf of users. These tokens appear in logs with the service's display name but the impersonated user's UPN. While some legitimate Microsoft operations use actor tokens, unexpected usage may indicate exploitation of CVE-2025-55241, which allowed unauthorized access to Azure AD Graph API across tenants before being patched by Microsoft.", + "false_positives": [ + "Creating specific groups via the Exchange Online PowerShell module will make Exchange use an Actor token on your behalf. The rule excludes group operations and directory feature operations to reduce false positives from these legitimate administrative activities." + ], + "from": "now-9m", + "interval": "8m", + "language": "esql", + "license": "Elastic License v2", + "name": "Entra ID Actor Token User Impersonation Abuse", + "note": "## Triage and analysis\n\n### Investigating Entra ID Actor Token User Impersonation Abuse\n\nThis rule detects when Microsoft services use actor tokens to perform operations in audit logs. Actor tokens are undocumented backend mechanisms used by Microsoft for service-to-service (S2S) communication. They appear with a mismatch: the service's display name but the impersonated user's UPN. While some operations legitimately use actor tokens, unexpected usage may indicate exploitation of CVE-2025-55241, which allowed attackers to obtain Global Admin privileges across any Entra ID tenant. Note that this vulnerability has been patched by Microsoft as of September 2025.\n\n### Possible investigation steps\n\n- Review the `azure.auditlogs.properties.initiated_by.user.userPrincipalName` field to identify which service principals are exhibiting this behavior.\n- Check the `azure.auditlogs.properties.initiated_by.user.displayName` to confirm these are legitimate Microsoft services.\n- Analyze the actions performed by these service principals - look for privilege escalations, permission grants, or unusual administrative operations.\n- Review the timing and frequency of these events to identify potential attack patterns or automated exploitation.\n- Cross-reference with recent administrative changes or service configurations that might explain legitimate use cases.\n- Check if any new applications or service principals were registered recently that could be related to this activity.\n- Investigate any correlation with other suspicious authentication events or privilege escalation attempts in your tenant.\n\n### False positive analysis\n\n- Legitimate Microsoft service migrations or updates may temporarily exhibit this behavior.\n- Third-party integrations using Microsoft Graph or other APIs might trigger this pattern during normal operations.\n- Automated administrative tools or scripts using service principal authentication could be misconfigured.\n\n### Response and remediation\n\n- Immediately review and audit all service principal permissions and recent consent grants in your Entra ID tenant.\n- Disable or restrict any suspicious service principals exhibiting this behavior until verified.\n- Review and revoke any unnecessary application permissions, especially those with high privileges.\n- Enable and review Entra ID audit logs for any permission grants or role assignments made by these service principals.\n- Implement Conditional Access policies to restrict service principal authentication from unexpected locations or conditions.\n- Enable Entra ID Identity Protection to detect and respond to risky service principal behaviors.\n- Review and harden application consent policies to prevent unauthorized service principal registrations.\n- Consider implementing privileged identity management (PIM) for service principal role assignments.\n", + "query": "from logs-azure.auditlogs-* metadata _id, _version, _index\n| where azure.auditlogs.properties.initiated_by.user.displayName in (\n \"Office 365 Exchange Online\",\n \"Skype for Business Online\",\n \"Dataverse\",\n \"Office 365 SharePoint Online\",\n \"Microsoft Dynamics ERP\"\n ) and\n not azure.auditlogs.operation_name like \"*group*\" and\n azure.auditlogs.operation_name != \"Set directory feature on tenant\"\n and azure.auditlogs.properties.initiated_by.user.userPrincipalName rlike \".+@[A-Za-z0-9.]+\\\\.[A-Za-z]{2,}\"\n| keep\n @timestamp,\n azure.*,\n client.*,\n event.*,\n source.*,\n _id,\n _version,\n _index\n", + "references": [ + "https://dirkjanm.io/obtaining-global-admin-in-every-entra-id-tenant-with-actor-tokens/", + "https://msrc.microsoft.com/update-guide/en-US/advisory/CVE-2025-55241" + ], + "related_integrations": [ + { + "package": "azure", + "version": "^1.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "@timestamp", + "type": "date" + }, + { + "ecs": false, + "name": "_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "_index", + "type": "keyword" + }, + { + "ecs": false, + "name": "_version", + "type": "long" + }, + { + "ecs": false, + "name": "azure.auditlogs.category", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.identity", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.level", + "type": "double" + }, + { + "ecs": false, + "name": "azure.auditlogs.operation_name", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.operation_version", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.activity_datetime", + "type": "date" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.activity_display_name", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.additional_details.key", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.additional_details.user_agent", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.additional_details.value", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.authentication_protocol", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.category", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.correlation_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.id", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.initiated_by.app.appId", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.initiated_by.app.displayName", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.initiated_by.app.servicePrincipalId", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.initiated_by.app.servicePrincipalName", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.initiated_by.user.displayName", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.initiated_by.user.id", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.initiated_by.user.ipAddress", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.initiated_by.user.roles", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.initiated_by.user.userPrincipalName", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.logged_by_service", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.operation_type", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.result", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.result_reason", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.target_resources.*.display_name", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.target_resources.*.id", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.target_resources.*.ip_address", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.target_resources.*.modified_properties.*.display_name", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.target_resources.*.modified_properties.*.new_value", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.target_resources.*.modified_properties.*.old_value", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.target_resources.*.type", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.target_resources.*.user_principal_name", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.target_resources.0.modified_properties.0.display_name", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.target_resources.0.modified_properties.0.new_value", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.target_resources.0.modified_properties.0.old_value", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.target_resources.0.modified_properties.1.display_name", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.target_resources.0.modified_properties.1.new_value", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.target_resources.0.modified_properties.2.new_value", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.target_resources.0.modified_properties.3.new_value", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.result_description", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.result_signature", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.tenant_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.correlation_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.resource.authorization_rule", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.resource.group", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.resource.id", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.resource.name", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.resource.namespace", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.resource.provider", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.subscription_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.tenant_id", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.address", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.as.number", + "type": "long" + }, + { + "ecs": true, + "name": "client.as.organization.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.bytes", + "type": "long" + }, + { + "ecs": true, + "name": "client.domain", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.geo.city_name", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.geo.continent_code", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.geo.continent_name", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.geo.country_iso_code", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.geo.country_name", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.geo.location", + "type": "geo_point" + }, + { + "ecs": true, + "name": "client.geo.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.geo.postal_code", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.geo.region_iso_code", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.geo.region_name", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.geo.timezone", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.ip", + "type": "ip" + }, + { + "ecs": true, + "name": "client.mac", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.nat.ip", + "type": "ip" + }, + { + "ecs": true, + "name": "client.nat.port", + "type": "long" + }, + { + "ecs": true, + "name": "client.packets", + "type": "long" + }, + { + "ecs": true, + "name": "client.port", + "type": "long" + }, + { + "ecs": true, + "name": "client.registered_domain", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.subdomain", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.top_level_domain", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.user.domain", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.user.email", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.user.full_name", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.user.group.domain", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.user.group.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.user.group.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.user.hash", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.user.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.user.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.user.roles", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.agent_id_status", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.category", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.code", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.created", + "type": "date" + }, + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.duration", + "type": "long" + }, + { + "ecs": true, + "name": "event.end", + "type": "date" + }, + { + "ecs": true, + "name": "event.hash", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.ingested", + "type": "date" + }, + { + "ecs": true, + "name": "event.kind", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.module", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.original", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.outcome", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.provider", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.reason", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.reference", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.risk_score", + "type": "float" + }, + { + "ecs": true, + "name": "event.risk_score_norm", + "type": "float" + }, + { + "ecs": true, + "name": "event.sequence", + "type": "long" + }, + { + "ecs": true, + "name": "event.severity", + "type": "long" + }, + { + "ecs": true, + "name": "event.start", + "type": "date" + }, + { + "ecs": true, + "name": "event.timezone", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.url", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.address", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.as.number", + "type": "long" + }, + { + "ecs": true, + "name": "source.as.organization.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.bytes", + "type": "long" + }, + { + "ecs": true, + "name": "source.domain", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.geo.city_name", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.geo.continent_code", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.geo.continent_name", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.geo.country_iso_code", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.geo.country_name", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.geo.location", + "type": "geo_point" + }, + { + "ecs": true, + "name": "source.geo.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.geo.postal_code", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.geo.region_iso_code", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.geo.region_name", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.geo.timezone", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.ip", + "type": "ip" + }, + { + "ecs": true, + "name": "source.mac", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.nat.ip", + "type": "ip" + }, + { + "ecs": true, + "name": "source.nat.port", + "type": "long" + }, + { + "ecs": true, + "name": "source.packets", + "type": "long" + }, + { + "ecs": true, + "name": "source.port", + "type": "long" + }, + { + "ecs": true, + "name": "source.registered_domain", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.subdomain", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.top_level_domain", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.user.domain", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.user.email", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.user.full_name", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.user.group.domain", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.user.group.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.user.group.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.user.hash", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.user.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.user.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.user.roles", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "8e7a4f2c-9b3d-4e5a-a1b6-c2d8f7e9b3a5", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Domain: Identity", + "Data Source: Azure", + "Data Source: Entra ID", + "Data Source: Entra Audit Logs", + "Use Case: Identity and Access Audit", + "Use Case: Threat Detection", + "Tactic: Initial Access", + "Tactic: Privilege Escalation", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0001", + "name": "Initial Access", + "reference": "https://attack.mitre.org/tactics/TA0001/" + }, + "technique": [ + { + "id": "T1078", + "name": "Valid Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/", + "subtechnique": [ + { + "id": "T1078.004", + "name": "Cloud Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/004/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0004", + "name": "Privilege Escalation", + "reference": "https://attack.mitre.org/tactics/TA0004/" + }, + "technique": [ + { + "id": "T1548", + "name": "Abuse Elevation Control Mechanism", + "reference": "https://attack.mitre.org/techniques/T1548/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 4 + }, + "id": "8e7a4f2c-9b3d-4e5a-a1b6-c2d8f7e9b3a5_4", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/90efea04-5675-11f0-8f80-f661ea17fbcd_3.json b/packages/security_detection_engine/kibana/security_rule/90efea04-5675-11f0-8f80-f661ea17fbcd_3.json new file mode 100644 index 00000000000..83fb319d940 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/90efea04-5675-11f0-8f80-f661ea17fbcd_3.json @@ -0,0 +1,114 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects a sequence of events in Microsoft Entra ID indicative of suspicious cloud-based device registration via automated tooling like ROADtools or similar frameworks. This behavior involves adding a device via the Device Registration Service, followed by the assignment of registered users and owners \u2014 a pattern consistent with techniques used to establish persistence or acquire a Primary Refresh Token (PRT). ROADtools and similar tooling leave distinct telemetry signatures such as the `Microsoft.OData.Client` user agent. These sequences are uncommon in typical user behavior and may reflect abuse of device trust for session hijacking or silent token replay.", + "from": "now-30m", + "index": [ + "filebeat-*", + "logs-azure.auditlogs-*" + ], + "interval": "15m", + "language": "eql", + "license": "Elastic License v2", + "name": "Entra ID Unusual Cloud Device Registration", + "note": "## Triage and analysis\n\n### Investigating Entra ID Unusual Cloud Device Registration\n\nThis rule detects a sequence of Microsoft Entra ID audit events consistent with cloud device registration abuse via ROADtools or similar automation frameworks. The activity includes three correlated events:\n\n1. Add device operation from the Device Registration Service using suspicious user-agents (`Dsreg/*`, `DeviceRegistrationClient`, or `Microsoft.OData.Client/*`).\n2. Addition of a registered user with an `enterprise registration` URN.\n3. Assignment of a registered owner to the device.\n\nThis pattern has been observed in OAuth phishing and PRT abuse campaigns where adversaries silently register a cloud device to obtain persistent, trusted access.\n\n### Possible investigation steps\n\n- Identify the user principal associated with the device registration.\n- Review the `azure.auditlogs.identity` field to confirm the Device Registration Service initiated the request.\n- Check the user-agent in `azure.auditlogs.properties.additional_details.value`. Known attack tooling signatures include:\n - `Dsreg/10.0 (Windows X.X.X)` - ROADtools Windows device registration\n - `DeviceRegistrationClient` - ROADtools MacOS/Android device registration\n - `Microsoft.OData.Client/*` - .NET-based tools or Graph SDK\n- Examine the OS version in the modified properties to identify potentially suspicious or outdated versions.\n- Verify the URN in the new value field (`urn:ms-drs:enterpriseregistration.windows.net`) is not being misused.\n- Use `azure.correlation_id` to pivot across all three steps of the registration flow.\n- Pivot to `azure.signinlogs` to detect follow-on activity using the new device, such as sign-ins involving refresh or primary refresh tokens.\n- Look for signs of persistence or lateral movement enabled by the newly registered device.\n- Identify the registered device name by reviewing `azure.auditlogs.properties.target_resources.0.display_name` and confirm it's expected for the user or organization.\n- Use the correlation ID `azure.correlation_id` to pivot into registered user events from Entra ID audit logs and check `azure.auditlogs.properties.target_resources.0.user_principal_name` to identify the user associated with the device registration.\n- Review any activity for this user from Entra ID sign-in logs, where the incoming token type is a `primaryRefreshToken`.\n\n### False positive analysis\n\n- Some MDM, autopilot provisioning flows, or third-party device management tools may generate similar sequences. Validate against known provisioning tools, expected rollout windows, and device inventory.\n- Investigate whether the device name, OS version, and registration details align with normal IT workflows.\n- Check if the user-agent corresponds to legitimate automation or tooling used by your organization.\n\n### Response and remediation\n\n- If confirmed malicious, remove the registered device from Entra ID.\n- Revoke refresh tokens and primary refresh tokens associated with the user and device.\n- Disable the user account and initiate password reset and identity verification procedures.\n- Review audit logs and sign-in activity for additional indicators of persistence or access from the rogue device.\n- Tighten conditional access policies to restrict device registration and enforce compliance or hybrid join requirements.\n", + "query": "sequence by azure.correlation_id with maxspan=5m\n[any where event.dataset == \"azure.auditlogs\" and\n azure.auditlogs.identity == \"Device Registration Service\" and\n azure.auditlogs.operation_name == \"Add device\" and\n (\n azure.auditlogs.properties.additional_details.value like \"Microsoft.OData.Client/*\" or\n azure.auditlogs.properties.additional_details.value like \"Dsreg/*\" or\n azure.auditlogs.properties.additional_details.value == \"DeviceRegistrationClient\"\n ) and\n `azure.auditlogs.properties.target_resources.0.modified_properties.1.display_name` == \"CloudAccountEnabled\" and\n `azure.auditlogs.properties.target_resources.0.modified_properties.1.new_value` == \"[true]\"]\n[any where event.dataset == \"azure.auditlogs\" and\n azure.auditlogs.operation_name == \"Add registered users to device\" and\n `azure.auditlogs.properties.target_resources.0.modified_properties.2.new_value` like \"*urn:ms-drs:enterpriseregistration.windows.net*\"]\n[any where event.dataset == \"azure.auditlogs\" and\n azure.auditlogs.operation_name == \"Add registered owner to device\"]\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/introducing-roadtools-token-exchange-roadtx/" + ], + "related_integrations": [ + { + "package": "azure", + "version": "^1.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "`azure.auditlogs.properties.target_resources.0.modified_properties.1.display_name`", + "type": "unknown" + }, + { + "ecs": false, + "name": "`azure.auditlogs.properties.target_resources.0.modified_properties.1.new_value`", + "type": "unknown" + }, + { + "ecs": false, + "name": "`azure.auditlogs.properties.target_resources.0.modified_properties.2.new_value`", + "type": "unknown" + }, + { + "ecs": false, + "name": "azure.auditlogs.identity", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.operation_name", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.additional_details.value", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.correlation_id", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "90efea04-5675-11f0-8f80-f661ea17fbcd", + "severity": "medium", + "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": "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/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 3 + }, + "id": "90efea04-5675-11f0-8f80-f661ea17fbcd_3", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/93c1ce76-494c-4f01-8167-35edfb52f7b1_416.json b/packages/security_detection_engine/kibana/security_rule/93c1ce76-494c-4f01-8167-35edfb52f7b1_416.json new file mode 100644 index 00000000000..a46edeaf80b --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/93c1ce76-494c-4f01-8167-35edfb52f7b1_416.json @@ -0,0 +1,100 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies registry write modifications to hide an encoded portable executable. This could be indicative of adversary defense evasion by avoiding the storing of malicious content directly on disk.", + "from": "now-9m", + "index": [ + "logs-endpoint.events.registry-*", + "endgame-*", + "logs-windows.sysmon_operational-*", + "logs-sentinel_one_cloud_funnel.*", + "winlogbeat-*", + "logs-m365_defender.event-*", + "logs-crowdstrike.fdr*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Deprecated - Encoded Executable Stored in the Registry", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Deprecated - Encoded Executable Stored in the Registry\n\nWindows Registry is a hierarchical database storing low-level settings for the OS and applications. Adversaries exploit it to hide encoded executables, evading detection by avoiding direct disk storage. The detection rule identifies suspicious registry modifications, specifically targeting encoded patterns indicative of hidden executables, thus flagging potential defense evasion tactics.\n\n### Possible investigation steps\n\n- Review the registry path and key where the modification was detected to understand the context and potential impact on the system.\n- Analyze the encoded data string \"TVqQAAMAAAAEAAAA*\" to determine if it corresponds to a known malicious executable or pattern.\n- Check the modification timestamp to correlate with any other suspicious activities or events on the system around the same time.\n- Investigate the process or user account responsible for the registry modification to assess if it is associated with legitimate activity or known threats.\n- Cross-reference the alert with other data sources such as Sysmon, Microsoft Defender for Endpoint, or SentinelOne for additional context or corroborating evidence of malicious behavior.\n- Evaluate the system's network activity and connections during the time of the registry modification to identify any potential command and control communications or data exfiltration attempts.\n\n### False positive analysis\n\n- Legitimate software installations or updates may write encoded executables to the registry as part of their normal operation. Users can create exceptions for known software by identifying their specific registry paths and excluding them from the detection rule.\n- Security tools and system management software might store encoded data in the registry for legitimate purposes. Review the registry paths and data associated with these tools and exclude them if they are verified as non-threatening.\n- Custom scripts or enterprise applications developed in-house may use encoded executables in the registry for deployment or configuration purposes. Work with development teams to identify these scripts and add exceptions for their registry modifications.\n- Regularly review and update the list of exceptions to ensure that only verified and necessary exclusions are maintained, minimizing the risk of overlooking potential threats.\n\n### Response and remediation\n\n- Isolate the affected system from the network to prevent further spread of the potential threat.\n- Use endpoint detection and response (EDR) tools to terminate any suspicious processes associated with the encoded executable.\n- Remove the malicious registry entry by using a trusted registry editor or automated script to ensure the encoded executable is no longer stored in the registry.\n- Conduct a full system scan using updated antivirus and anti-malware tools to identify and remove any additional threats or remnants of the attack.\n- Restore the system from a known good backup if the integrity of the system is compromised and cannot be assured through cleaning.\n- Monitor the system and network for any signs of re-infection or similar registry modifications, adjusting detection rules if necessary to enhance future threat identification.\n- Escalate the incident to the security operations center (SOC) or relevant cybersecurity team for further analysis and to determine if additional systems are affected.", + "query": "registry where host.os.type == \"windows\" and\n/* update here with encoding combinations */\n registry.data.strings : \"TVqQAAMAAAAEAAAA*\"\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "windows", + "version": "^3.0.0" + }, + { + "package": "sentinel_one_cloud_funnel", + "version": "^1.0.0" + }, + { + "package": "m365_defender", + "version": "^3.0.0" + }, + { + "package": "crowdstrike", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "registry.data.strings", + "type": "wildcard" + } + ], + "risk_score": 47, + "rule_id": "93c1ce76-494c-4f01-8167-35edfb52f7b1", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: Elastic Endgame", + "Data Source: Elastic Defend", + "Data Source: Sysmon", + "Data Source: SentinelOne", + "Data Source: Microsoft Defender for Endpoint", + "Data Source: Crowdstrike", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1112", + "name": "Modify Registry", + "reference": "https://attack.mitre.org/techniques/T1112/" + }, + { + "id": "T1140", + "name": "Deobfuscate/Decode Files or Information", + "reference": "https://attack.mitre.org/techniques/T1140/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 416 + }, + "id": "93c1ce76-494c-4f01-8167-35edfb52f7b1_416", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/94e734c0-2cda-11ef-84e1-f661ea17fbce_209.json b/packages/security_detection_engine/kibana/security_rule/94e734c0-2cda-11ef-84e1-f661ea17fbce_209.json new file mode 100644 index 00000000000..7df23c15a0a --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/94e734c0-2cda-11ef-84e1-f661ea17fbce_209.json @@ -0,0 +1,198 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects potential credential stuffing attacks where a single source IP attempts authentication against many Okta user accounts with minimal attempts per user, indicating the use of breached credential lists.", + "false_positives": [ + "Corporate proxy or VPN exit nodes may aggregate traffic from multiple legitimate users.", + "Shared systems such as kiosks or conference room computers may have multiple users authenticating." + ], + "from": "now-15m", + "language": "esql", + "license": "Elastic License v2", + "name": "Potential Okta Credential Stuffing (Single Source)", + "note": "## Triage and analysis\n\n### Investigating Potential Okta Credential Stuffing (Single Source)\n\nThis rule identifies a single source IP attempting authentication against many user accounts with minimal attempts per user. This pattern indicates credential stuffing where attackers rapidly test breached username and password pairs.\n\n#### Possible investigation steps\n- Identify the source IP and determine if it belongs to known proxy, VPN, or cloud infrastructure.\n- Review the list of targeted user accounts and check if any authentications succeeded.\n- Examine the user agent strings for signs of automation or scripting tools.\n- Check if Okta flagged the source as a known threat or proxy.\n- Determine if any targeted accounts have elevated privileges or access to sensitive systems.\n- Review the geographic location and ASN of the source IP for anomalies.\n\n### False positive analysis\n- Corporate proxies or VPN exit nodes may aggregate traffic from multiple legitimate users.\n- Shared systems such as kiosks or conference room computers may have multiple users authenticating.\n- Legitimate SSO integrations may generate multiple authentication attempts from a single source.\n\n### Response and remediation\n- If attack is confirmed, block the source IP at the network perimeter.\n- Reset passwords for any accounts that may have been compromised.\n- Enable or strengthen MFA for targeted accounts.\n- Review Okta sign-on policies to add additional friction for suspicious authentication patterns.\n- If this is a known legitimate source, consider adding an exception for the IP or ASN.\n", + "query": "FROM logs-okta.system-* METADATA _id, _version, _index\n| WHERE\n event.dataset == \"okta.system\"\n AND (event.action LIKE \"user.authentication.*\" OR event.action == \"user.session.start\")\n AND okta.outcome.reason IN (\"INVALID_CREDENTIALS\", \"LOCKED_OUT\")\n AND okta.actor.alternate_id IS NOT NULL\n// Build user-source context as JSON for enrichment\n| EVAL Esql.user_source_info = CONCAT(\n \"{\\\"user\\\":\\\"\", okta.actor.alternate_id,\n \"\\\",\\\"ip\\\":\\\"\", COALESCE(okta.client.ip::STRING, \"unknown\"),\n \"\\\",\\\"user_agent\\\":\\\"\", COALESCE(okta.client.user_agent.raw_user_agent, \"unknown\"), \"\\\"}\"\n )\n// FIRST STATS: Aggregate by (IP, user) to get per-user attempt counts\n// This prevents skew from outlier users with many attempts\n| STATS\n Esql.user_attempts = COUNT(*),\n Esql.user_dt_hashes = COUNT_DISTINCT(okta.debug_context.debug_data.dt_hash),\n Esql.user_source_info = VALUES(Esql.user_source_info),\n Esql.user_agents_per_user = VALUES(okta.client.user_agent.raw_user_agent),\n Esql.devices_per_user = VALUES(okta.client.device),\n Esql.is_proxy = VALUES(okta.security_context.is_proxy),\n Esql.geo_country = VALUES(client.geo.country_name),\n Esql.geo_city = VALUES(client.geo.city_name),\n Esql.asn_number = VALUES(source.as.number),\n Esql.asn_org = VALUES(source.as.organization.name),\n Esql.threat_suspected = VALUES(okta.debug_context.debug_data.threat_suspected),\n Esql.risk_level = VALUES(okta.debug_context.debug_data.risk_level),\n Esql.risk_reasons = VALUES(okta.debug_context.debug_data.risk_reasons),\n Esql.event_actions = VALUES(event.action),\n Esql.first_seen_user = MIN(@timestamp),\n Esql.last_seen_user = MAX(@timestamp)\n BY okta.client.ip, okta.actor.alternate_id\n// SECOND STATS: Aggregate by IP to detect credential stuffing pattern\n// Now we can accurately measure the distribution of attempts across users\n| STATS\n Esql.unique_users = COUNT(*),\n Esql.total_attempts = SUM(Esql.user_attempts),\n Esql.max_attempts_per_user = MAX(Esql.user_attempts),\n Esql.min_attempts_per_user = MIN(Esql.user_attempts),\n Esql.avg_attempts_per_user = AVG(Esql.user_attempts),\n Esql.users_with_single_attempt = SUM(CASE(Esql.user_attempts == 1, 1, 0)),\n Esql.users_with_few_attempts = SUM(CASE(Esql.user_attempts <= 2, 1, 0)),\n Esql.first_seen = MIN(Esql.first_seen_user),\n Esql.last_seen = MAX(Esql.last_seen_user),\n Esql.target_users = VALUES(okta.actor.alternate_id),\n Esql.user_source_mapping = VALUES(Esql.user_source_info),\n Esql.event_action_values = VALUES(Esql.event_actions),\n Esql.user_agent_values = VALUES(Esql.user_agents_per_user),\n Esql.device_values = VALUES(Esql.devices_per_user),\n Esql.is_proxy_values = VALUES(Esql.is_proxy),\n Esql.geo_country_values = VALUES(Esql.geo_country),\n Esql.geo_city_values = VALUES(Esql.geo_city),\n Esql.source_asn_values = VALUES(Esql.asn_number),\n Esql.source_asn_org_values = VALUES(Esql.asn_org),\n Esql.threat_suspected_values = VALUES(Esql.threat_suspected),\n Esql.risk_level_values = VALUES(Esql.risk_level),\n Esql.risk_reasons_values = VALUES(Esql.risk_reasons)\n BY okta.client.ip\n// Calculate stuffing signature: most users should have very few attempts\n| EVAL Esql.pct_users_few_attempts = Esql.users_with_few_attempts * 100.0 / Esql.unique_users\n// Credential stuffing: many users, most with 1-2 attempts each, low max per user\n// Stacked stats gives us accurate per-user distribution instead of skewed averages\n| WHERE\n Esql.total_attempts >= 25\n AND Esql.unique_users >= 15\n AND Esql.max_attempts_per_user <= 2\n AND Esql.pct_users_few_attempts >= 80.0\n| SORT Esql.unique_users DESC\n| KEEP Esql.*, okta.client.ip\n", + "references": [ + "https://support.okta.com/help/s/article/Troubleshooting-Distributed-Brute-Force-andor-Password-Spray-attacks-in-Okta", + "https://www.okta.com/identity-101/brute-force/", + "https://support.okta.com/help/s/article/How-does-the-Device-Token-work?language=en_US", + "https://developer.okta.com/docs/reference/api/event-types/", + "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy", + "https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection", + "https://www.okta.com/resources/whitepaper-how-adaptive-mfa-can-help-in-mitigating-brute-force-attacks/", + "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security", + "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta" + ], + "related_integrations": [ + { + "package": "okta", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.avg_attempts_per_user", + "type": "double" + }, + { + "ecs": false, + "name": "Esql.device_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.event_action_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.first_seen", + "type": "date" + }, + { + "ecs": false, + "name": "Esql.geo_city_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.geo_country_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.is_proxy_values", + "type": "boolean" + }, + { + "ecs": false, + "name": "Esql.last_seen", + "type": "date" + }, + { + "ecs": false, + "name": "Esql.max_attempts_per_user", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.min_attempts_per_user", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.pct_users_few_attempts", + "type": "double" + }, + { + "ecs": false, + "name": "Esql.risk_level_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.risk_reasons_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.source_asn_org_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.source_asn_values", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.target_users", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.threat_suspected_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.total_attempts", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.unique_users", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.user_agent_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.user_source_mapping", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.users_with_few_attempts", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.users_with_single_attempt", + "type": "long" + }, + { + "ecs": false, + "name": "okta.client.ip", + "type": "ip" + } + ], + "risk_score": 47, + "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": "medium", + "tags": [ + "Domain: Identity", + "Use Case: Identity and Access Audit", + "Data Source: Okta", + "Data Source: Okta System Logs", + "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.004", + "name": "Credential Stuffing", + "reference": "https://attack.mitre.org/techniques/T1110/004/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 209 + }, + "id": "94e734c0-2cda-11ef-84e1-f661ea17fbce_209", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/994e40aa-8c85-43de-825e-15f665375ee8_113.json b/packages/security_detection_engine/kibana/security_rule/994e40aa-8c85-43de-825e-15f665375ee8_113.json deleted file mode 100644 index 2beaaea382e..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/994e40aa-8c85-43de-825e-15f665375ee8_113.json +++ /dev/null @@ -1,103 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "A supervised machine learning model (ProblemChild) has identified a suspicious Windows process event with high probability of it being malicious activity. Alternatively, the model's blocklist identified the event as being malicious.", - "from": "now-10m", - "index": [ - "endgame-*", - "logs-endpoint.events.process-*", - "winlogbeat-*" - ], - "language": "eql", - "license": "Elastic License v2", - "name": "Machine Learning Detected a Suspicious Windows Event with a High Malicious Probability Score", - "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 Machine Learning Detected a Suspicious Windows Event with a High Malicious Probability Score\n\nThe detection leverages a machine learning model, ProblemChild, to identify potentially malicious Windows processes by analyzing patterns and assigning a high probability score to suspicious activities. Adversaries may exploit legitimate processes to evade detection, often using techniques like masquerading. This rule flags high-risk events by focusing on processes with a high malicious probability score or those identified by a blocklist, excluding known benign activities.\n\n### Possible investigation steps\n\n- Review the process details flagged by the ProblemChild model, focusing on those with a prediction probability greater than 0.98 or identified by the blocklist.\n- Examine the command-line arguments of the suspicious process to identify any unusual or unexpected patterns, excluding those matching known benign patterns like \"*C:\\\\WINDOWS\\\\temp\\\\nessus_*.txt*\" or \"*C:\\\\WINDOWS\\\\temp\\\\nessus_*.tmp*\".\n- Check the parent process of the flagged event to determine if it is a legitimate process or if it has been potentially compromised.\n- Investigate the user account associated with the process to assess if it has been involved in any other suspicious activities or if it has elevated privileges that could be exploited.\n- Correlate the event with other security alerts or logs to identify any related activities or patterns that could indicate a broader attack campaign.\n- Consult threat intelligence sources to determine if the process or its associated indicators are linked to known malicious activities or threat actors.\n\n### False positive analysis\n\n- Nessus scan files in the Windows temp directory may trigger false positives due to their temporary nature and frequent legitimate use. Users can mitigate this by adding exceptions for file paths like C:\\WINDOWS\\temp\\nessus_*.txt and C:\\WINDOWS\\temp\\nessus_*.tmp.\n- Legitimate software updates or installations might be flagged if they mimic known malicious patterns. Users should review the process details and whitelist trusted software update processes.\n- System administration tools that perform actions similar to those used in attacks could be misidentified. Users should verify the legitimacy of these tools and exclude them from the rule if they are part of regular administrative tasks.\n- Custom scripts or automation tools that are not widely recognized might be flagged. Users should ensure these scripts are secure and add them to an allowlist if they are part of routine operations.\n- Frequent false positives from specific processes can be managed by adjusting the threshold of the machine learning model or refining the blocklist to better distinguish between benign and malicious activities.\n\n### Response and remediation\n\n- Isolate the affected system from the network to prevent further spread of potential malicious activity.\n- Terminate the suspicious process identified by the ProblemChild model to halt any ongoing malicious actions.\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 analyze the process execution history and associated files to understand the scope of the compromise and identify any persistence mechanisms.\n- Restore any altered or deleted files from backups, ensuring that the backup is clean and free from malware.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.\n- Implement enhanced monitoring and logging for similar processes and activities to detect and respond to future attempts at masquerading or defense evasion.", - "query": "process where ((problemchild.prediction == 1 and problemchild.prediction_probability > 0.98) or\nblocklist_label == 1) and not process.args : (\"*C:\\\\WINDOWS\\\\temp\\\\nessus_*.txt*\", \"*C:\\\\WINDOWS\\\\temp\\\\nessus_*.tmp*\")\n", - "references": [ - "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html", - "https://docs.elastic.co/en/integrations/problemchild", - "https://www.elastic.co/security-labs/detecting-living-off-the-land-attacks-with-new-elastic-integration" - ], - "related_integrations": [ - { - "package": "problemchild", - "version": "^2.0.0" - }, - { - "package": "endpoint", - "version": "^8.2.0" - }, - { - "package": "windows", - "version": "^3.0.0" - } - ], - "required_fields": [ - { - "ecs": false, - "name": "blocklist_label", - "type": "unknown" - }, - { - "ecs": false, - "name": "problemchild.prediction", - "type": "unknown" - }, - { - "ecs": false, - "name": "problemchild.prediction_probability", - "type": "unknown" - }, - { - "ecs": true, - "name": "process.args", - "type": "keyword" - } - ], - "risk_score": 73, - "rule_id": "994e40aa-8c85-43de-825e-15f665375ee8", - "setup": "## Setup\n\nThe rule requires the Living off the Land (LotL) Attack Detection integration assets to be installed, as well as Windows process events collected by integrations such as Elastic Defend or Winlogbeat.\n\n### LotL Attack Detection Setup\nThe LotL Attack Detection integration detects living-off-the-land activity in Windows process events.\n\n#### Prerequisite Requirements:\n- Fleet is required for LotL Attack Detection.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n- Windows process events collected by the [Elastic Defend](https://docs.elastic.co/en/integrations/endpoint) integration or Winlogbeat(https://www.elastic.co/guide/en/beats/winlogbeat/current/_winlogbeat_overview.html).\n- To install Elastic Defend, refer to the [documentation](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n- To set up and run Winlogbeat, follow [this](https://www.elastic.co/guide/en/beats/winlogbeat/current/winlogbeat-installation-configuration.html) guide.\n\n#### The following steps should be executed to install assets associated with the LotL Attack Detection integration:\n- Go to the Kibana homepage. Under Management, click Integrations.\n- In the query bar, search for Living off the Land Attack Detection and select the integration to see more details about it.\n- Follow the instructions under the **Installation** section.\n- For this rule to work, complete the instructions through **Configure the ingest pipeline**.\n", - "severity": "high", - "tags": [ - "OS: Windows", - "Data Source: Elastic Endgame", - "Use Case: Living off the Land Attack Detection", - "Rule Type: ML", - "Rule Type: Machine Learning", - "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": "T1036", - "name": "Masquerading", - "reference": "https://attack.mitre.org/techniques/T1036/", - "subtechnique": [ - { - "id": "T1036.004", - "name": "Masquerade Task or Service", - "reference": "https://attack.mitre.org/techniques/T1036/004/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "eql", - "version": 113 - }, - "id": "994e40aa-8c85-43de-825e-15f665375ee8_113", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/9c260313-c811-4ec8-ab89-8f6530e0246c_211.json b/packages/security_detection_engine/kibana/security_rule/9c260313-c811-4ec8-ab89-8f6530e0246c_211.json deleted file mode 100644 index 28f5d5c83dc..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/9c260313-c811-4ec8-ab89-8f6530e0246c_211.json +++ /dev/null @@ -1,110 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "The hosts file on endpoints is used to control manual IP address to hostname resolutions. The hosts file is the first point of lookup for DNS hostname resolution so if adversaries can modify the endpoint hosts file, they can route traffic to malicious infrastructure. This rule detects modifications to the hosts file on Microsoft Windows, Linux (Ubuntu or RHEL) and macOS systems.", - "from": "now-9m", - "index": [ - "auditbeat-*", - "winlogbeat-*", - "logs-endpoint.events.*", - "logs-windows.*" - ], - "language": "eql", - "license": "Elastic License v2", - "name": "Hosts File Modified", - "note": "## Triage and analysis\n\n### Investigating Hosts File Modified\n\nOperating systems use the hosts file to map a connection between an IP address and domain names before going to domain name servers. Attackers can abuse this mechanism to route traffic to malicious infrastructure or disrupt security that depends on server communications. For example, Russian threat actors modified this file on a domain controller to redirect Duo MFA calls to localhost instead of the Duo server, which prevented the MFA service from contacting its server to validate MFA login. This effectively disabled MFA for active domain accounts because the default policy of Duo for Windows is to \"Fail open\" if the MFA server is unreachable. This can happen in any MFA implementation and is not exclusive to Duo. Find more details in this [CISA Alert](https://www.cisa.gov/uscert/ncas/alerts/aa22-074a).\n\nThis rule identifies modifications in the hosts file across multiple operating systems using process creation events for Linux and file events in Windows and macOS.\n\n#### Possible investigation steps\n\n- Identify the specifics of the involved assets, such as role, criticality, and associated users.\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 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- Examine the changes to the hosts file by comparing it against file backups, volume shadow copies, and other restoration mechanisms.\n\n### False positive analysis\n\n- This mechanism can be used legitimately. Analysts can dismiss the alert if the administrator is aware of the activity and the configuration was justified.\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 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- Review the privileges of the administrator account that performed the action.\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\n\n /* file events for creation; file change events are not captured by some of the included sources for linux and so may\n miss this, which is the purpose of the process + command line args logic below */\n (\n event.category == \"file\" and event.type in (\"change\", \"creation\") and\n file.path : (\"/private/etc/hosts\", \"/etc/hosts\", \"?:\\\\Windows\\\\System32\\\\drivers\\\\etc\\\\hosts\") and \n not process.name in (\"dockerd\", \"rootlesskit\", \"podman\", \"crio\")\n )\n or\n\n /* process events for change targeting linux only */\n (\n event.category == \"process\" and event.type in (\"start\") and\n process.name in (\"nano\", \"vim\", \"vi\", \"emacs\", \"echo\", \"sed\") and\n process.args : (\"/etc/hosts\") and \n not process.parent.name in (\"dhclient-script\", \"google_set_hostname\")\n )\n", - "references": [ - "https://www.elastic.co/guide/en/beats/auditbeat/current/auditbeat-reference-yml.html" - ], - "related_integrations": [ - { - "package": "endpoint", - "version": "^9.0.0" - }, - { - "package": "windows", - "version": "^2.5.0" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "event.category", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.type", - "type": "keyword" - }, - { - "ecs": true, - "name": "file.path", - "type": "keyword" - }, - { - "ecs": true, - "name": "process.args", - "type": "keyword" - }, - { - "ecs": true, - "name": "process.name", - "type": "keyword" - }, - { - "ecs": true, - "name": "process.parent.name", - "type": "keyword" - } - ], - "risk_score": 47, - "rule_id": "9c260313-c811-4ec8-ab89-8f6530e0246c", - "setup": "## Setup\n\nFor Windows systems using Auditbeat, this rule requires adding `C:/Windows/System32/drivers/etc` as an additional path in the 'file_integrity' module of auditbeat.yml.\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: Impact", - "Resources: Investigation Guide", - "Data Source: Elastic Defend" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0040", - "name": "Impact", - "reference": "https://attack.mitre.org/tactics/TA0040/" - }, - "technique": [ - { - "id": "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/" - } - ] - } - ] - } - ], - "timeline_id": "4d4c0b59-ea83-483f-b8c1-8c360ee53c5c", - "timeline_title": "Comprehensive File Timeline", - "timestamp_override": "event.ingested", - "type": "eql", - "version": 211 - }, - "id": "9c260313-c811-4ec8-ab89-8f6530e0246c_211", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/9edd1804-83c7-4e48-b97d-c776b4c97564_4.json b/packages/security_detection_engine/kibana/security_rule/9edd1804-83c7-4e48-b97d-c776b4c97564_4.json deleted file mode 100644 index 2962cf063e5..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/9edd1804-83c7-4e48-b97d-c776b4c97564_4.json +++ /dev/null @@ -1,148 +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", - "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating PowerShell Obfuscation via Negative Index String Reversal\n\nPowerShell, a powerful scripting language, can be exploited by adversaries using obfuscation techniques like negative index string reversal to evade detection. This method manipulates strings or arrays by iterating in reverse, bypassing static analysis tools. The detection rule identifies scripts with obfuscation patterns by analyzing script length and specific indexing patterns, flagging potential threats for further investigation.\n\n### Possible investigation steps\n\n- Review the `powershell.file.script_block_text` to understand the script's intent and identify any suspicious or malicious behavior.\n- Check the `host.name` and `user.id` fields to determine the affected system and user, assessing if they are high-value targets or have a history of similar alerts.\n- Analyze the `file.path` to identify the location of the script and assess if it is in a common or suspicious directory.\n- Investigate the `powershell.file.script_block_id` and `powershell.sequence` to trace the execution flow and determine if this script is part of a larger, potentially malicious sequence.\n- Correlate the `agent.id` with other logs to see if there are additional related activities or alerts from the same endpoint.\n- Examine the `count` of detected patterns to assess the level of obfuscation and potential threat severity.\n\n### False positive analysis\n\n- Scripts containing the keyword \"GENESIS-5654\" are known false positives and are automatically excluded from triggering alerts. Ensure that any legitimate scripts using this keyword are documented to prevent unnecessary investigations.\n- Legitimate administrative scripts that use negative indexing for valid purposes may trigger false positives. Review these scripts and consider adding them to an exception list if they are frequently flagged but verified as non-malicious.\n- Automated scripts generated by trusted software that use similar obfuscation patterns for performance or compatibility reasons can be excluded by identifying unique identifiers or patterns within these scripts and updating the exclusion criteria accordingly.\n- Regularly update the exclusion list to include new patterns or identifiers from trusted sources as they are identified, ensuring that legitimate activities are not hindered by the detection rule.\n- Collaborate with IT and security teams to maintain a list of known safe scripts and their characteristics, which can be referenced when analyzing potential false positives.\n\n### Response and remediation\n\n- Isolate the affected host immediately to prevent further spread of potentially malicious scripts or unauthorized access.\n- Terminate any suspicious PowerShell processes identified by the alert to halt ongoing obfuscation activities.\n- Conduct a thorough review of the PowerShell script block text and related logs to identify any malicious payloads or commands executed.\n- Remove any identified malicious scripts or files from the affected system to prevent re-execution.\n- Reset credentials for any user accounts involved in the alert to mitigate potential unauthorized access.\n- Escalate the incident to the security operations team for further analysis and to determine if additional systems are compromised.\n- Update endpoint protection and monitoring tools to enhance detection capabilities for similar obfuscation techniques in the future.\n", - "query": "from logs-windows.powershell_operational* metadata _id, _version, _index\n| where event.code == \"4104\"\n\n// Filter out smaller scripts that are unlikely to implement obfuscation using the patterns we are looking for\n| eval Esql.script_block_length = length(powershell.file.script_block_text)\n| where Esql.script_block_length > 500\n\n// replace the patterns we are looking for with the \ud83d\udd25 emoji to enable counting them\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| eval Esql.script_block_tmp = replace(\n powershell.file.script_block_text,\n \"\"\"\\$\\w+\\[\\-\\s?1\\.\\.\"\"\",\n \"\ud83d\udd25\"\n)\n\n// count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| eval Esql.script_block_pattern_count = length(Esql.script_block_tmp) - length(replace(Esql.script_block_tmp, \"\ud83d\udd25\", \"\"))\n\n// keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| keep\n Esql.script_block_pattern_count,\n Esql.script_block_length,\n Esql.script_block_tmp,\n powershell.file.script_block_text,\n powershell.file.script_block_id,\n file.path,\n powershell.sequence,\n powershell.total,\n _id,\n _index,\n host.name,\n agent.id,\n user.id\n\n// Filter for scripts that match the pattern at least once\n| where Esql.script_block_pattern_count >= 1\n\n// FP Patterns\n| where not powershell.file.script_block_text like \"*GENESIS-5654*\"\n", - "related_integrations": [ - { - "package": "windows", - "version": "^3.0.0" - } - ], - "required_fields": [ - { - "ecs": false, - "name": "Esql.script_block_length", - "type": "integer" - }, - { - "ecs": false, - "name": "Esql.script_block_pattern_count", - "type": "integer" - }, - { - "ecs": false, - "name": "Esql.script_block_tmp", - "type": "keyword" - }, - { - "ecs": false, - "name": "_id", - "type": "keyword" - }, - { - "ecs": false, - "name": "_index", - "type": "keyword" - }, - { - "ecs": true, - "name": "agent.id", - "type": "keyword" - }, - { - "ecs": true, - "name": "file.path", - "type": "keyword" - }, - { - "ecs": true, - "name": "host.name", - "type": "keyword" - }, - { - "ecs": false, - "name": "powershell.file.script_block_id", - "type": "keyword" - }, - { - "ecs": false, - "name": "powershell.file.script_block_text", - "type": "text" - }, - { - "ecs": false, - "name": "powershell.sequence", - "type": "long" - }, - { - "ecs": false, - "name": "powershell.total", - "type": "long" - }, - { - "ecs": true, - "name": "user.id", - "type": "keyword" - } - ], - "risk_score": 21, - "rule_id": "9edd1804-83c7-4e48-b97d-c776b4c97564", - "setup": "## Setup\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nAdministrative Templates >\nWindows PowerShell >\nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n", - "severity": "low", - "tags": [ - "Domain: Endpoint", - "OS: Windows", - "Use Case: Threat Detection", - "Tactic: Defense Evasion", - "Data Source: PowerShell Logs", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0005", - "name": "Defense Evasion", - "reference": "https://attack.mitre.org/tactics/TA0005/" - }, - "technique": [ - { - "id": "T1027", - "name": "Obfuscated Files or Information", - "reference": "https://attack.mitre.org/techniques/T1027/" - }, - { - "id": "T1140", - "name": "Deobfuscate/Decode Files or Information", - "reference": "https://attack.mitre.org/techniques/T1140/" - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0002", - "name": "Execution", - "reference": "https://attack.mitre.org/tactics/TA0002/" - }, - "technique": [ - { - "id": "T1059", - "name": "Command and Scripting Interpreter", - "reference": "https://attack.mitre.org/techniques/T1059/", - "subtechnique": [ - { - "id": "T1059.001", - "name": "PowerShell", - "reference": "https://attack.mitre.org/techniques/T1059/001/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 4 - }, - "id": "9edd1804-83c7-4e48-b97d-c776b4c97564_4", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/9edd1804-83c7-4e48-b97d-c776b4c97564_8.json b/packages/security_detection_engine/kibana/security_rule/9edd1804-83c7-4e48-b97d-c776b4c97564_8.json new file mode 100644 index 00000000000..1f7548c4123 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/9edd1804-83c7-4e48-b97d-c776b4c97564_8.json @@ -0,0 +1,212 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects PowerShell scripts that uses negative index ranges (for example, $var[-1..0]) to reverse strings or arrays and rebuild content at runtime. Attackers use index reversal to reconstruct hidden commands or payloads and evade static analysis and AMSI.", + "from": "now-9m", + "investigation_fields": { + "field_names": [ + "@timestamp", + "user.name", + "user.id", + "user.domain", + "powershell.file.script_block_text", + "powershell.file.script_block_id", + "powershell.sequence", + "powershell.total", + "file.path", + "file.directory", + "file.name", + "process.pid", + "host.name", + "host.id", + "powershell.file.script_block_length" + ] + }, + "language": "esql", + "license": "Elastic License v2", + "name": "PowerShell Obfuscation via Negative Index String Reversal", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This guide was created by humans with the assistance of generative AI. While its contents have been manually curated to include the most valuable information, always validate assumptions and adjust procedures to match your internal runbooks and incident triage and response policies.\n\n### Investigating PowerShell Obfuscation via Negative Index String Reversal\n\nThis alert flags PowerShell script block content that uses negative index ranges to reverse strings or arrays and rebuild content at runtime. This pattern can be used to hide command text and reduce readability during review, so the primary goal is to recover the reconstructed content and determine what it does in the observed execution context.\n\n#### Key alert fields to review\n\n- `user.name`, `user.domain`, `user.id`: Account execution context for correlation, prioritization, and scoping.\n- `host.name`, `host.id`: Host execution context for correlation, prioritization, and scoping.\n- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file.\n- `powershell.file.script_block_text`: Script block content that matched the detection logic.\n- `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`: Script block metadata to pivot to other fragments or reconstruct full script content when split across multiple events.\n- `Esql.script_block_tmp`: Transformed script block where detection patterns replace original content with a marker to support scoring/counting and quickly spot match locations.\n- `Esql.script_block_pattern_count`: Count of matches for the detection pattern(s) observed in the script block content.\n- `powershell.file.script_block_entropy_bits`: Shannon entropy of the script block. Higher values may indicate obfuscation.\n- `powershell.file.script_block_surprisal_stdev`: Standard deviation of surprisal across the script block. Low values indicate uniform randomness. High values indicate mixed patterns and variability.\n- `powershell.file.script_block_unique_symbols`: Count of distinct characters present in the script block.\n- `powershell.file.script_block_length`: Script block length (size) context.\n\n#### Possible investigation steps\n\n- Review `powershell.file.script_block_text` and locate the reversal logic. Use `Esql.script_block_tmp` to quickly find match positions, then identify:\n - The variable or array being reversed\n - The reconstructed output (string, byte array, or command fragment)\n - The sink where the output is used (for example, passed into a dynamic execution routine, used as a URL, or written to disk)\n- Reconstruct the final value produced by the reversal. Focus on what the script is trying to rebuild (commands, URLs, file paths, registry paths, encoded blobs, or arguments) and record the recovered strings for scoping.\n- If the script block is fragmented, pivot on `powershell.file.script_block_id` and use `powershell.sequence` and `powershell.total` to rebuild the full script in order. Reassess intent based on the complete content rather than a single fragment.\n- Use `Esql.script_block_pattern_count` to prioritize reviews:\n - Single-use reversal may be utility logic and requires context to judge\n - Repeated reversal across a long script is more consistent with obfuscation wrappers\n- Use script complexity signals to guide triage:\n - High `powershell.file.script_block_entropy_bits` and high `powershell.file.script_block_unique_symbols` can indicate encoded or staged content\n - Compare `powershell.file.script_block_surprisal_stdev` with the script content to determine whether the script mixes readable logic with high-randomness segments\n- Validate execution context with `user.name`, `user.domain`, `user.id`, `host.name`, and `host.id`. Prioritize investigation when the user is unexpected for the host, the host is sensitive, or similar activity is new for that account.\n- Review `file.path`, `file.directory`, and `file.name` (if present) to understand script origin. Treat unknown locations, new or renamed scripts, and ambiguous naming as higher risk, and check for additional script blocks tied to the same path.\n- Scope related activity by searching for additional PowerShell script block events on the same `host.id` and `user.id` around `@timestamp`, and by pivoting on the same `powershell.file.script_block_id`. Look for:\n - Follow-on script blocks with clearer (deobfuscated) commands\n - Repeated use of similar reversal segments or reconstructed indicators\n- If other endpoint telemetry is available, correlate activity on the same host and time window to identify what happened next (process launches, network connections, file writes, or other changes) and validate whether outcomes align with the reconstructed content.\n\n### False positive analysis\n\n- Legitimate scripts may reverse arrays or strings for formatting, parsing, or testing. These cases typically remain readable end-to-end and do not rely on multiple layers of reconstruction to produce executable behavior.\n- Developer utilities and automation tooling can include dense string manipulation. Validate whether the observed `file.path` and execution context (`user.name`, `host.name`) align with approved workflows and whether the same script content recurs consistently across expected hosts.\n- If activity is confirmed benign, prefer context-based tuning using stable attributes visible in the alert (for example, consistent `file.path` and recognizable script content patterns) rather than suppressing the technique broadly.\n\n### Response and remediation\n\n- If the reconstructed content indicates malicious behavior, isolate the affected host to limit further execution and reduce the risk of lateral movement.\n- Preserve evidence by retaining the full `powershell.file.script_block_text` and all related fragments grouped by `powershell.file.script_block_id`. Capture the reconstructed strings and relevant metadata (`powershell.sequence`, `powershell.total`, `Esql.script_block_pattern_count`) in case notes.\n- Identify and contain the execution source. If an unauthorized on-disk script is referenced by `file.path`, remove or quarantine it and investigate how it was introduced using your standard incident response workflow.\n- Investigate the associated account (`user.id`) for signs of compromise. Apply account controls (credential reset, session invalidation, privilege review) based on your procedures and observed scope.\n- Hunt for additional exposure by pivoting on recovered indicators and on recurrence of the reversal technique across hosts and users. Remediate any additional impacted endpoints identified during scoping.\n- After containment, improve preventative controls appropriate for your environment, such as restricting PowerShell usage to approved users/hosts and enhancing monitoring for obfuscation and dynamic execution patterns.\n", + "query": "from logs-windows.powershell_operational* metadata _id, _version, _index\n| where event.code == \"4104\"\n\n// Filter out smaller scripts that are unlikely to implement obfuscation using the patterns we are looking for\n| eval Esql.script_block_length = length(powershell.file.script_block_text)\n| where Esql.script_block_length > 500\n\n// replace the patterns we are looking for with the \ud83d\udd25 emoji to enable counting them\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| eval Esql.script_block_tmp = replace(\n powershell.file.script_block_text,\n \"\"\"\\$\\w+\\[\\-\\s?1\\.\\.\"\"\",\n \"\ud83d\udd25\"\n)\n\n// count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| eval Esql.script_block_pattern_count = length(Esql.script_block_tmp) - length(replace(Esql.script_block_tmp, \"\ud83d\udd25\", \"\"))\n\n// keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| keep\n Esql.script_block_pattern_count,\n Esql.script_block_length,\n Esql.script_block_tmp,\n powershell.file.*,\n file.name,\n file.path,\n powershell.sequence,\n powershell.total,\n _id,\n _version,\n _index,\n host.name,\n host.id,\n agent.id,\n user.id\n\n// Filter for scripts that match the pattern at least once\n| where Esql.script_block_pattern_count >= 1\n\n// FP Patterns\n| where not powershell.file.script_block_text like \"*GENESIS-5654*\"\n\n| where file.name not like (\"PSFzf.psm1\", \"Tenable_API_AssetLists_IPv6Seeder.ps1\", \"Utility.ps1\")\n // ESQL requires this condition, otherwise it only returns matches where file.name exists.\n or file.name is null\n", + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.script_block_length", + "type": "integer" + }, + { + "ecs": false, + "name": "Esql.script_block_pattern_count", + "type": "integer" + }, + { + "ecs": false, + "name": "Esql.script_block_tmp", + "type": "keyword" + }, + { + "ecs": false, + "name": "_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "_index", + "type": "keyword" + }, + { + "ecs": false, + "name": "_version", + "type": "long" + }, + { + "ecs": true, + "name": "agent.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.path", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.name", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_entropy_bits", + "type": "double" + }, + { + "ecs": false, + "name": "powershell.file.script_block_entropy_normalized", + "type": "double" + }, + { + "ecs": false, + "name": "powershell.file.script_block_hash", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_length", + "type": "long" + }, + { + "ecs": false, + "name": "powershell.file.script_block_surprisal_stdev", + "type": "double" + }, + { + "ecs": false, + "name": "powershell.file.script_block_text", + "type": "text" + }, + { + "ecs": false, + "name": "powershell.file.script_block_unique_symbols", + "type": "long" + }, + { + "ecs": false, + "name": "powershell.sequence", + "type": "long" + }, + { + "ecs": false, + "name": "powershell.total", + "type": "long" + }, + { + "ecs": true, + "name": "user.id", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "9edd1804-83c7-4e48-b97d-c776b4c97564", + "setup": "## Setup\n\nPowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104).\nSetup instructions: https://ela.st/powershell-logging-setup\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": 8 + }, + "id": "9edd1804-83c7-4e48-b97d-c776b4c97564_8", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/9f432a8b-9588-4550-838e-1f77285580d3_10.json b/packages/security_detection_engine/kibana/security_rule/9f432a8b-9588-4550-838e-1f77285580d3_10.json new file mode 100644 index 00000000000..5379f7cbf0e --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/9f432a8b-9588-4550-838e-1f77285580d3_10.json @@ -0,0 +1,212 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects PowerShell scripts that rebuilds IEX by converting method references to strings (for example, ''.IndexOf.ToString()) and extracting multiple indexed characters (for example, [n,n,n]). Attackers use method-string reconstruction to conceal dynamic execution and bypass static detections and AMSI.", + "from": "now-9m", + "investigation_fields": { + "field_names": [ + "@timestamp", + "user.name", + "user.id", + "user.domain", + "powershell.file.script_block_text", + "powershell.file.script_block_id", + "powershell.sequence", + "powershell.total", + "file.path", + "file.directory", + "file.name", + "process.pid", + "host.name", + "host.id", + "powershell.file.script_block_length" + ] + }, + "language": "esql", + "license": "Elastic License v2", + "name": "Dynamic IEX Reconstruction via Method String Access", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This guide was created by humans with the assistance of generative AI. While its contents have been manually curated to include the most valuable information, always validate assumptions and adjust procedures to match your internal runbooks and incident triage and response policies.\n\n### Investigating Dynamic IEX Reconstruction via Method String Access\n\nThis alert indicates PowerShell script block content that uses method-to-string conversion and indexed character extraction to assemble an execution primitive at runtime, commonly \"IEX\" (Invoke-Expression). This obfuscation technique can conceal dynamic execution intent and is often used to reduce obvious keywords in the script body.\n\n#### Key alert fields to review\n\n- `user.name`, `user.domain`, `user.id`: Account execution context for correlation, prioritization, and scoping.\n- `host.name`, `host.id`: Host execution context for correlation, prioritization, and scoping.\n- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file.\n- `powershell.file.script_block_text`: Script block content that matched the detection logic.\n- `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`: Script block metadata to pivot to other fragments or reconstruct full script content when split across multiple events.\n- `Esql.script_block_tmp`: Transformed script block where detection patterns replace original content with a marker to support scoring/counting and quickly spot match locations.\n- `Esql.script_block_pattern_count`: Count of matches for the detection pattern(s) observed in the script block content.\n- `powershell.file.script_block_entropy_bits`: Shannon entropy of the script block. Higher values may indicate obfuscation.\n- `powershell.file.script_block_surprisal_stdev`: Standard deviation of surprisal across the script block. Low values indicate uniform randomness. High values indicate mixed patterns and variability.\n- `powershell.file.script_block_unique_symbols`: Count of distinct characters present in the script block.\n- `powershell.file.script_block_length`: Script block length (size) context.\n\n#### Possible investigation steps\n\n- Establish execution context and scope:\n - Review `host.name` and `host.id` to identify the affected endpoint and its role/criticality.\n - Review `user.name`, `user.domain`, and `user.id` to determine whether the activity aligns with expected administrative or automation usage.\n - Review `file.path`, `file.directory`, and `file.name` (when present) to understand whether the script originated from an on-disk file.\n - Review `agent.id` to pivot to other telemetry from the same endpoint and timeframe.\n\n- Validate what matched and how extensively it appears:\n - Review `Esql.script_block_pattern_count` to gauge how often the technique appears within the script block (higher counts can indicate heavier obfuscation).\n - Use `Esql.script_block_tmp` to quickly locate the matched regions, then review the corresponding locations in `powershell.file.script_block_text` for the exact construct and nearby context.\n - Review `powershell.file.script_block_length` alongside `powershell.file.script_block_entropy_bits`, `powershell.file.script_block_surprisal_stdev`, and `powershell.file.script_block_unique_symbols` to help distinguish isolated string tricks from broader obfuscation.\n\n- Reconstruct the full script block when content is split:\n - Pivot on `powershell.file.script_block_id` and order results by `powershell.sequence`.\n - Use `powershell.total` to confirm you have all fragments before making a final assessment.\n - Preserve the reassembled content from `powershell.file.script_block_text` for follow-on analysis and scoping.\n\n- Determine the reconstructed token and follow-on behavior:\n - In `powershell.file.script_block_text`, identify the method string being indexed and the associated index list (for example, [n,n,n]) to determine what characters are being assembled.\n - Identify how the reconstructed string is used (for example, invoked directly, assigned to a variable, or passed as an argument) and what content it ultimately executes.\n - Capture any secondary artifacts referenced in the script content (for example, embedded payload strings, additional script blocks, or external resource locations) and use them to drive further correlation.\n\n- Validate likely origin and initiating source:\n - If `file.path` is present, validate whether the script location is expected for the user and host, and whether it appears in a user-writable location or a standard administrative tooling path.\n - If file origin fields are not present, the script may have been executed interactively or generated at runtime; rely on surrounding endpoint telemetry to identify the initiating process and any related activity.\n\n- Correlate with adjacent activity to understand impact:\n - Review other PowerShell script blocks on the same `host.id` and `user.id` around the alert time to identify staging steps and any follow-on execution.\n - If process telemetry is available, identify the PowerShell process and its parent process that initiated execution, and check for suspicious child processes near the alert time.\n - If network or file telemetry is available, look for downloads, outbound connections, and file writes temporally aligned with the script block execution and the content referenced within `powershell.file.script_block_text`.\n\n- Assess prevalence across the environment:\n - Search for similar patterns (including stable substrings from `powershell.file.script_block_text`) across other hosts and users.\n - Prioritize results with higher `Esql.script_block_pattern_count` and higher obfuscation metrics to identify likely common tooling or shared payloads.\n\n### False positive analysis\n\n- PowerShell developers or automation teams may experiment with unconventional string manipulation, but method-string indexing to assemble execution primitives is uncommon in routine administration.\n- Authorized security testing, malware analysis, or threat emulation activities can intentionally use this technique; validate against approved testing windows and operator accounts.\n- Some script packaging or code protection approaches can introduce non-standard string operations; treat as benign only when the script origin (`file.path` / `file.name`), execution context (`user.id`), and surrounding host activity support a known, approved workflow.\n\n### Response and remediation\n\n- If malicious or suspicious activity is confirmed:\n - Contain the affected host identified by `host.id` to prevent additional execution and lateral movement.\n - Preserve evidence from the alert, including `powershell.file.script_block_text`, `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`, `file.path`, and `Esql.script_block_pattern_count`.\n - Scope for related activity by searching for similar content patterns across the environment and identifying additional impacted hosts and accounts.\n - If an on-disk script is involved (`file.path` present), collect the file for analysis and remove or quarantine it according to your incident handling process.\n - Review the associated account (`user.id`) for additional suspicious activity and remediate credential exposure as appropriate (for example, reset credentials and review recent authentication activity).\n\n- If the activity is determined to be benign:\n - Document the legitimate script source, expected hosts, and operator accounts for future triage.\n - Reduce noise with narrowly scoped suppression using stable characteristics available in the alert (for example, consistent `file.path` and repeatable non-sensitive substrings in `powershell.file.script_block_text`), while continuing to monitor for deviations.\n", + "query": "from logs-windows.powershell_operational* metadata _id, _version, _index\n| where event.code == \"4104\"\n\n// Filter out smaller scripts that are unlikely to implement obfuscation using the patterns we are looking for\n| eval Esql.script_block_length = length(powershell.file.script_block_text)\n| where Esql.script_block_length > 500\n\n// replace the patterns we are looking for with the \ud83d\udd25 emoji to enable counting them\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| eval Esql.script_block_tmp = replace(\n powershell.file.script_block_text,\n \"\"\"(?i)['\"]['\"].(Insert|Normalize|Chars|substring|Remove|LastIndexOfAny|LastIndexOf|IsNormalized|IndexOfAny|IndexOf)[^\\[]+\\[\\d+,\\d+,\\d+\\]\"\"\",\n \"\ud83d\udd25\"\n)\n\n// count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| eval Esql.script_block_pattern_count = length(Esql.script_block_tmp) - length(replace(Esql.script_block_tmp, \"\ud83d\udd25\", \"\"))\n\n// keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| keep\n Esql.script_block_pattern_count,\n Esql.script_block_length,\n Esql.script_block_tmp,\n powershell.file.*,\n file.path,\n file.directory,\n powershell.sequence,\n powershell.total,\n _id,\n _version,\n _index,\n host.name,\n host.id,\n agent.id,\n user.id\n\n// Filter for scripts that match the pattern at least once\n| where Esql.script_block_pattern_count >= 1\n\n| where not (\n file.directory like \"C:\\\\\\\\Program Files\\\\\\\\WindowsPowerShell\\\\\\\\Modules\\\\\\\\Maester\\\\\\\\1.1.0*\" or\n file.directory like \"C:\\\\\\\\Users\\\\\\\\*\\\\\\\\Documents\\\\\\\\WindowsPowerShell\\\\\\\\Modules\\\\\\\\Maester\\\\\\\\1.1.0*\"\n )\n // ESQL requires this condition, otherwise it only returns matches where file.directory exists.\n or file.directory is null\n", + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.script_block_length", + "type": "integer" + }, + { + "ecs": false, + "name": "Esql.script_block_pattern_count", + "type": "integer" + }, + { + "ecs": false, + "name": "Esql.script_block_tmp", + "type": "keyword" + }, + { + "ecs": false, + "name": "_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "_index", + "type": "keyword" + }, + { + "ecs": false, + "name": "_version", + "type": "long" + }, + { + "ecs": true, + "name": "agent.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.directory", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.path", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.name", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_entropy_bits", + "type": "double" + }, + { + "ecs": false, + "name": "powershell.file.script_block_entropy_normalized", + "type": "double" + }, + { + "ecs": false, + "name": "powershell.file.script_block_hash", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_length", + "type": "long" + }, + { + "ecs": false, + "name": "powershell.file.script_block_surprisal_stdev", + "type": "double" + }, + { + "ecs": false, + "name": "powershell.file.script_block_text", + "type": "text" + }, + { + "ecs": false, + "name": "powershell.file.script_block_unique_symbols", + "type": "long" + }, + { + "ecs": false, + "name": "powershell.sequence", + "type": "long" + }, + { + "ecs": false, + "name": "powershell.total", + "type": "long" + }, + { + "ecs": true, + "name": "user.id", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "9f432a8b-9588-4550-838e-1f77285580d3", + "setup": "## Setup\n\nPowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104).\nSetup instructions: https://ela.st/powershell-logging-setup\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": 10 + }, + "id": "9f432a8b-9588-4550-838e-1f77285580d3_10", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/9f432a8b-9588-4550-838e-1f77285580d3_6.json b/packages/security_detection_engine/kibana/security_rule/9f432a8b-9588-4550-838e-1f77285580d3_6.json deleted file mode 100644 index b44ddbab67e..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/9f432a8b-9588-4550-838e-1f77285580d3_6.json +++ /dev/null @@ -1,153 +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// Filter out smaller scripts that are unlikely to implement obfuscation using the patterns we are looking for\n| eval Esql.script_block_length = length(powershell.file.script_block_text)\n| where Esql.script_block_length > 500\n\n// replace the patterns we are looking for with the \ud83d\udd25 emoji to enable counting them\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| eval Esql.script_block_tmp = replace(\n powershell.file.script_block_text,\n \"\"\"(?i)['\"]['\"].(Insert|Normalize|Chars|substring|Remove|LastIndexOfAny|LastIndexOf|IsNormalized|IndexOfAny|IndexOf)[^\\[]+\\[\\d+,\\d+,\\d+\\]\"\"\",\n \"\ud83d\udd25\"\n)\n\n// count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| eval Esql.script_block_pattern_count = length(Esql.script_block_tmp) - length(replace(Esql.script_block_tmp, \"\ud83d\udd25\", \"\"))\n\n// keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| keep\n Esql.script_block_pattern_count,\n Esql.script_block_length,\n Esql.script_block_tmp,\n powershell.file.script_block_text,\n powershell.file.script_block_id,\n file.path,\n file.directory,\n powershell.sequence,\n powershell.total,\n _id,\n _index,\n host.name,\n agent.id,\n user.id\n\n// Filter for scripts that match the pattern at least once\n| where Esql.script_block_pattern_count >= 1\n\n| where not (\n file.directory like \"C:\\\\\\\\Program Files\\\\\\\\WindowsPowerShell\\\\\\\\Modules\\\\\\\\Maester\\\\\\\\1.1.0*\" or\n file.directory like \"C:\\\\\\\\Users\\\\\\\\*\\\\\\\\Documents\\\\\\\\WindowsPowerShell\\\\\\\\Modules\\\\\\\\Maester\\\\\\\\1.1.0*\"\n )\n // ESQL requires this condition, otherwise it only returns matches where file.directory exists.\n or file.directory is null\n", - "related_integrations": [ - { - "package": "windows", - "version": "^3.0.0" - } - ], - "required_fields": [ - { - "ecs": false, - "name": "Esql.script_block_length", - "type": "integer" - }, - { - "ecs": false, - "name": "Esql.script_block_pattern_count", - "type": "integer" - }, - { - "ecs": false, - "name": "Esql.script_block_tmp", - "type": "keyword" - }, - { - "ecs": false, - "name": "_id", - "type": "keyword" - }, - { - "ecs": false, - "name": "_index", - "type": "keyword" - }, - { - "ecs": true, - "name": "agent.id", - "type": "keyword" - }, - { - "ecs": true, - "name": "file.directory", - "type": "keyword" - }, - { - "ecs": true, - "name": "file.path", - "type": "keyword" - }, - { - "ecs": true, - "name": "host.name", - "type": "keyword" - }, - { - "ecs": false, - "name": "powershell.file.script_block_id", - "type": "keyword" - }, - { - "ecs": false, - "name": "powershell.file.script_block_text", - "type": "text" - }, - { - "ecs": false, - "name": "powershell.sequence", - "type": "long" - }, - { - "ecs": false, - "name": "powershell.total", - "type": "long" - }, - { - "ecs": true, - "name": "user.id", - "type": "keyword" - } - ], - "risk_score": 21, - "rule_id": "9f432a8b-9588-4550-838e-1f77285580d3", - "setup": "## Setup\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nAdministrative Templates >\nWindows PowerShell >\nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n", - "severity": "low", - "tags": [ - "Domain: Endpoint", - "OS: Windows", - "Use Case: Threat Detection", - "Tactic: Defense Evasion", - "Data Source: PowerShell Logs", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0005", - "name": "Defense Evasion", - "reference": "https://attack.mitre.org/tactics/TA0005/" - }, - "technique": [ - { - "id": "T1027", - "name": "Obfuscated Files or Information", - "reference": "https://attack.mitre.org/techniques/T1027/" - }, - { - "id": "T1140", - "name": "Deobfuscate/Decode Files or Information", - "reference": "https://attack.mitre.org/techniques/T1140/" - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0002", - "name": "Execution", - "reference": "https://attack.mitre.org/tactics/TA0002/" - }, - "technique": [ - { - "id": "T1059", - "name": "Command and Scripting Interpreter", - "reference": "https://attack.mitre.org/techniques/T1059/", - "subtechnique": [ - { - "id": "T1059.001", - "name": "PowerShell", - "reference": "https://attack.mitre.org/techniques/T1059/001/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 6 - }, - "id": "9f432a8b-9588-4550-838e-1f77285580d3_6", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/a3cc60d8-2701-11f0-accf-f661ea17fbcd_4.json b/packages/security_detection_engine/kibana/security_rule/a3cc60d8-2701-11f0-accf-f661ea17fbcd_4.json new file mode 100644 index 00000000000..c2aeb798f13 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/a3cc60d8-2701-11f0-accf-f661ea17fbcd_4.json @@ -0,0 +1,126 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies when an application accesses SharePoint Online or OneDrive for Business for the first time in the tenant within a specified timeframe. This detects successful OAuth phishing campaigns, illicit consent grants, or compromised third-party applications gaining initial access to file storage. Adversaries often use malicious OAuth applications or phishing techniques to gain consent from users, allowing persistent access to organizational data repositories without traditional credential theft.", + "false_positives": [ + "New legitimate applications or integrations recently deployed in the environment may trigger this detection during initial setup or rollout phases.", + "Third-party SaaS applications with SharePoint integration may appear as new app IDs when users first authorize access.", + "Developers testing new applications or OAuth flows in non-production tenants may generate alerts during development cycles." + ], + "from": "now-9m", + "history_window_start": "now-7d", + "index": [ + "logs-azure.signinlogs-*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "Entra ID Sharepoint or OneDrive Accessed by Unusual Client", + "new_terms_fields": [ + "azure.signinlogs.properties.app_id", + "azure.signinlogs.properties.tenant_id" + ], + "note": "## Triage and analysis\n\n### Investigating Entra ID Sharepoint or OneDrive Accessed by Unusual Client\n\nThis rule identifies when an application accesses SharePoint Online or OneDrive for Business for the first time in the tenant. This is a critical signal for detecting successful OAuth phishing campaigns, where adversaries trick users into granting consent to malicious applications. Once consent is granted, the malicious app can persistently access file storage without further user interaction. This detection also catches illicit consent grants, compromised third-party applications, or custom malicious apps registered by adversaries.\n\n### Possible Investigation Steps:\n\n- Identify the Application: Review `azure.signinlogs.properties.app_id` and `azure.signinlogs.properties.app_display_name` to determine which application accessed SharePoint. Cross-reference with known legitimate applications in your environment.\n- Check Application Registration: Search Entra ID app registrations for the app ID. Determine if it's a first-party Microsoft app, known third-party integration, or suspicious/unknown application.\n- Review Consent History: Investigate when and how consent was granted. Check `azure.auditlogs` for recent `Consent to application` events matching this app ID. Identify which user granted consent and whether it was admin or user consent.\n- Analyze Permissions Granted: Review the OAuth scopes and permissions granted to the application. Look for overly broad permissions (e.g., `Files.ReadWrite.All`, `Sites.ReadWrite.All`) that exceed business requirements.\n- Correlate with User Activity: Check if the user who granted consent recently received phishing emails, clicked suspicious links, or reported potential phishing attempts.\n- Inspect Source IP and Location: Review `source.ip` and `source.geo.*` fields. Determine if the sign-in originated from expected locations or suspicious infrastructure (VPNs, data centers, anonymizers).\n- Review Application Publisher: Check if the application is verified by Microsoft or has a suspicious/generic publisher name. Unverified applications with generic names (e.g., \"File Viewer\", \"Document Manager\") are common in phishing.\n- Check for Data Access: Review subsequent SharePoint audit logs to see what files/sites the application accessed after gaining consent.\n- Conditional Access Evaluation: Review `azure.signinlogs.properties.applied_conditional_access_policies` to determine if any security controls were bypassed or if the application should have been blocked.\n\n### False Positive Analysis\n\n- New Legitimate Integrations: Newly deployed third-party SaaS applications (e.g., document management, collaboration tools) that integrate with SharePoint will trigger this detection during initial setup. Validate with IT/procurement teams.\n- Microsoft First-Party Applications: This rule excludes common Microsoft first-party apps (Office 365 SharePoint Online, OneDrive SyncEngine, OneDrive iOS App, Microsoft Office, SharePoint Web Client Extensibility, Microsoft Teams, Office 365 Exchange Online, and other Microsoft-owned app IDs). However, new Microsoft applications or features may still appear. Cross-reference unfamiliar app IDs against Microsoft's first-party app list.\n- Development/Testing: Developers testing OAuth flows or building internal applications may generate alerts in development or staging environments.\n- Organizational Changes: Mergers, acquisitions, or tenant migrations may introduce legitimate applications from partner organizations accessing SharePoint for the first time.\n\n### Response and Remediation\n\n- Immediate Actions if Malicious:\n - Revoke consent for the malicious application immediately via Entra ID > Enterprise Applications\n - Revoke all active sessions and refresh tokens for affected users\n - Disable the application's service principal to prevent further access\n - Review and remediate any data accessed by the application using SharePoint audit logs\n- User Notification: Contact users who granted consent to inform them of the phishing attempt and provide security awareness training on identifying malicious OAuth consent requests\n- Conditional Access Hardening: Implement or strengthen Conditional Access policies to:\n - Require admin consent for high-risk permissions (Files.ReadWrite.All, Sites.ReadWrite.All)\n - Block unverified publishers from accessing sensitive resources\n - Enforce device compliance and MFA for application access\n- Tenant-Wide Review: Audit all application consents across the tenant to identify other potentially malicious applications that may have gained access through similar campaigns\n- Monitor for Campaign Patterns: Check if the same malicious application targeted multiple users, indicating an organized phishing campaign. Coordinate with email security teams to identify and block phishing emails used in the campaign.\n\n", + "query": "event.dataset:azure.signinlogs\n and azure.signinlogs.properties.resource_id: (\n 00000003-0000-0ff1-ce00-000000000000 or\n 6a9b9266-8161-4a7b-913a-a9eda19da220\n ) and azure.signinlogs.properties.app_id: ( *\n and not (\n 00000003-0000-0ff1-ce00-000000000000 or\n 08e18876-6177-487e-b8b5-cf950c1e598c or\n ab9b8c07-8f02-4f72-87fa-80105867a763 or\n af124e86-4e96-495a-b70a-90f90ab96707\n )\n )\n and azure.signinlogs.properties.tenant_id:*\n and event.outcome:success\n", + "references": [ + "https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/", + "https://www.microsoft.com/en-us/security/blog/2022/09/22/malicious-oauth-applications-used-to-compromise-email-servers-and-spread-spam/", + "https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/manage-consent-requests", + "https://github.com/merill/microsoft-info/blob/main/_info/MicrosoftApps.json" + ], + "related_integrations": [ + { + "package": "azure", + "version": "^1.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "azure.signinlogs.properties.app_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.signinlogs.properties.resource_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.signinlogs.properties.tenant_id", + "type": "unknown" + }, + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.outcome", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "a3cc60d8-2701-11f0-accf-f661ea17fbcd", + "setup": "#### Required Microsoft Entra ID Sign-In Logs\nTo use this rule, ensure that Microsoft Entra ID Sign-In Logs are being collected and streamed into the Elastic Stack via the Azure integration.\n", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Domain: Identity", + "Domain: Storage", + "Use Case: Identity and Access Audit", + "Tactic: Collection", + "Tactic: Initial Access", + "Data Source: Azure", + "Data Source: Microsoft Entra ID", + "Data Source: Microsoft Entra ID Sign-in Logs", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0009", + "name": "Collection", + "reference": "https://attack.mitre.org/tactics/TA0009/" + }, + "technique": [ + { + "id": "T1213", + "name": "Data from Information Repositories", + "reference": "https://attack.mitre.org/techniques/T1213/", + "subtechnique": [ + { + "id": "T1213.002", + "name": "Sharepoint", + "reference": "https://attack.mitre.org/techniques/T1213/002/" + } + ] + } + ] + }, + { + "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/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "new_terms", + "version": 4 + }, + "id": "a3cc60d8-2701-11f0-accf-f661ea17fbcd_4", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/a74c60cb-70ee-4629-a127-608ead14ebf1_8.json b/packages/security_detection_engine/kibana/security_rule/a74c60cb-70ee-4629-a127-608ead14ebf1_8.json new file mode 100644 index 00000000000..3ebc5c5e897 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/a74c60cb-70ee-4629-a127-608ead14ebf1_8.json @@ -0,0 +1,63 @@ +{ + "attributes": { + "anomaly_threshold": 70, + "author": [ + "Elastic" + ], + "description": "A machine learning job has detected unusually high mean of RDP session duration. Long RDP sessions can be used to evade detection mechanisms via session persistence, and might be used to perform tasks such as lateral movement, that might require uninterrupted access to a compromised machine.", + "from": "now-12h", + "interval": "15m", + "license": "Elastic License v2", + "machine_learning_job_id": "lmd_high_mean_rdp_session_duration", + "name": "High Mean of RDP Session Duration", + "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 Mean of RDP Session Duration\n\nRemote Desktop Protocol (RDP) enables remote access to systems, facilitating administrative tasks. However, adversaries exploit prolonged RDP sessions to maintain persistent access, potentially conducting lateral movements undetected. The 'High Mean of RDP Session Duration' detection rule leverages machine learning to identify anomalies in session lengths, flagging potential misuse indicative of malicious activity.\n\n### Possible investigation steps\n\n- Review the specific RDP session details, including the start and end times, to understand the duration and identify any patterns or anomalies in session lengths.\n- Correlate the flagged RDP session with user activity logs to determine if the session aligns with expected user behavior or if it deviates from normal patterns.\n- Check for any concurrent or subsequent suspicious activities, such as file transfers or command executions, that might indicate lateral movement or data exfiltration.\n- Investigate the source and destination IP addresses involved in the RDP session to identify if they are known, trusted, or associated with any previous security incidents.\n- Analyze the user account involved in the RDP session for any signs of compromise, such as recent password changes, failed login attempts, or unusual access patterns.\n- Review any recent changes in the network or system configurations that might have affected RDP session durations or security settings.\n\n### False positive analysis\n\n- Extended RDP sessions for legitimate administrative tasks can trigger false positives. To manage this, identify and whitelist IP addresses or user accounts associated with routine administrative activities.\n- Scheduled maintenance or software updates often require prolonged RDP sessions. Exclude these activities by setting time-based exceptions during known maintenance windows.\n- Remote support sessions from trusted third-party vendors may appear as anomalies. Create exceptions for these vendors by verifying their IP addresses and adding them to an allowlist.\n- Training sessions or demonstrations using RDP can result in longer session durations. Document and exclude these events by correlating them with scheduled training times and user accounts involved.\n- Automated scripts or processes that maintain RDP sessions for monitoring purposes can be mistaken for threats. Identify these scripts and exclude their associated user accounts or machine names 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 lateral movement.\n- Terminate any suspicious or unauthorized RDP sessions to cut off potential adversary access.\n- Conduct a thorough review of user accounts and permissions on the affected system to identify and disable any compromised accounts.\n- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited.\n- Restore the system from a known good backup if any unauthorized changes or malware are detected.\n- Monitor network traffic and logs for any signs of further exploitation attempts or related suspicious activity.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation.", + "references": [ + "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html", + "https://docs.elastic.co/en/integrations/lmd", + "https://www.elastic.co/blog/detecting-lateral-movement-activity-a-new-kibana-integration", + "https://www.elastic.co/blog/remote-desktop-protocol-connections-elastic-security" + ], + "related_integrations": [ + { + "package": "lmd", + "version": "^2.0.0" + }, + { + "package": "endpoint", + "version": "^8.2.0" + } + ], + "risk_score": 21, + "rule_id": "a74c60cb-70ee-4629-a127-608ead14ebf1", + "setup": "## Setup\n\nThis rule requires the `host.ip` field to be populated.\nFor **Elastic Defend** events on versions **8.18 and above**, this field is **disabled by default**.\n\nIf you are using **Elastic Defend**, ensure host IP collection is enabled by following the configuration steps in the\n[helper guide](https://www.elastic.co/docs/solutions/security/configure-elastic-defend/configure-data-volume-for-elastic-endpoint#host-fields).\n\nThe rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration.\n\n### Lateral Movement Detection Setup\nThe Lateral Movement Detection integration detects lateral movement activity by identifying abnormalities in file and Windows RDP events. Anomalies are detected using Elastic's Anomaly Detection feature.\n\n#### Prerequisite Requirements:\n- Fleet is required for Lateral Movement Detection.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n- Windows RDP process events collected by the [Elastic Defend](https://docs.elastic.co/en/integrations/endpoint) integration.\n- To install Elastic Defend, refer to the [documentation](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n\n#### The following steps should be executed to install assets associated with the Lateral Movement Detection integration:\n- Go to the Kibana homepage. Under Management, click Integrations.\n- In the query bar, search for Lateral Movement Detection and select the integration to see more details about it.\n- Follow the instructions under the **Installation** section.\n- For this rule to work, complete the instructions through **Add preconfigured anomaly detection jobs**.\n", + "severity": "low", + "tags": [ + "Use Case: Lateral Movement Detection", + "Rule Type: ML", + "Rule Type: Machine Learning", + "Tactic: Lateral Movement", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0008", + "name": "Lateral Movement", + "reference": "https://attack.mitre.org/tactics/TA0008/" + }, + "technique": [ + { + "id": "T1210", + "name": "Exploitation of Remote Services", + "reference": "https://attack.mitre.org/techniques/T1210/" + } + ] + } + ], + "type": "machine_learning", + "version": 8 + }, + "id": "a74c60cb-70ee-4629-a127-608ead14ebf1_8", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/a7f2c1b4-5d8e-4f3a-9b0c-2e1d4a6b8f3e_1.json b/packages/security_detection_engine/kibana/security_rule/a7f2c1b4-5d8e-4f3a-9b0c-2e1d4a6b8f3e_1.json new file mode 100644 index 00000000000..e3225541103 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/a7f2c1b4-5d8e-4f3a-9b0c-2e1d4a6b8f3e_1.json @@ -0,0 +1,102 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects when a FortiGate SSL VPN login event is followed by any SIEM detection alert for the same user name within a short time window. This correlation can indicate abuse of VPN access for malicious activity, credential compromise used from a VPN session, or initial access via VPN followed by post-compromise behavior.", + "from": "now-9m", + "index": [ + "logs-fortinet_fortigate.log-*", + ".alerts-security.*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "FortiGate SSL VPN Login Followed by SIEM Alert by User", + "note": "## Triage and analysis\n\n### Investigating FortiGate SSL VPN Login Followed by SIEM Alert by User\n\nThis rule correlates a FortiGate SSL VPN login with a subsequent security alert for the same user name, highlighting possible abuse of VPN access or activity shortly after remote access.\n\n### Possible investigation steps\n\n- Review the FortiGate login event (source IP, user, time) and the SIEM alert(s) that followed for the same user.\n- Determine whether the user is expected to use VPN and whether the subsequent alert is related to legitimate work (e.g. admin tools, updates).\n- Check for other alerts or logins for the same user in the same time window to assess scope.\n- Correlate with authentication logs to identify impossible travel or credential reuse from the VPN session.\n\n### False positive analysis\n\n- Legitimate VPN users triggering detections (e.g. scripted tasks, admin tooling) after login.\n- Security scans or automated jobs that run in the context of a VPN-authenticated user.\n\n### Response and remediation\n\n- If abuse or compromise is suspected, disable or reset the user\u2019s VPN access and credentials.\n- Investigate the host and process associated with the SIEM alert.\n- Escalate to the security or incident response team if the alert indicates malicious activity.\n", + "query": "sequence by user.name with maxspan=10m\n [authentication where event.dataset == \"fortinet_fortigate.log\" and event.action == \"login\" and event.code in (\"0101039426\", \"0101039427\")]\n [any where event.kind == \"signal\" and kibana.alert.rule.name != null and event.dataset != \"fortinet_fortigate.log\" and\n kibana.alert.risk_score > 21 and kibana.alert.rule.rule_id != \"a7f2c1b4-5d8e-4f3a-9b0c-2e1d4a6b8f3e\" and user.name != null]\n", + "references": [ + "https://attack.mitre.org/tactics/TA0001/", + "https://www.elastic.co/docs/reference/integrations/fortinet_fortigate" + ], + "related_integrations": [ + { + "package": "fortinet_fortigate", + "version": "^1.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.kind", + "type": "keyword" + }, + { + "ecs": false, + "name": "kibana.alert.risk_score", + "type": "unknown" + }, + { + "ecs": false, + "name": "kibana.alert.rule.name", + "type": "unknown" + }, + { + "ecs": false, + "name": "kibana.alert.rule.rule_id", + "type": "unknown" + }, + { + "ecs": true, + "name": "user.name", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "a7f2c1b4-5d8e-4f3a-9b0c-2e1d4a6b8f3e", + "severity": "medium", + "tags": [ + "Use Case: Threat Detection", + "Rule Type: Higher-Order Rule", + "Tactic: Initial Access", + "Data Source: Fortinet", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0001", + "name": "Initial Access", + "reference": "https://attack.mitre.org/tactics/TA0001/" + }, + "technique": [ + { + "id": "T1078", + "name": "Valid Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 1 + }, + "id": "a7f2c1b4-5d8e-4f3a-9b0c-2e1d4a6b8f3e_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/a80ffc40-a256-475a-a86a-74361930cdb1_1.json b/packages/security_detection_engine/kibana/security_rule/a80ffc40-a256-475a-a86a-74361930cdb1_1.json new file mode 100644 index 00000000000..a7fb92ca248 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/a80ffc40-a256-475a-a86a-74361930cdb1_1.json @@ -0,0 +1,135 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects the creation of a new SAML Identity Provider (IdP) in AWS IAM. SAML providers enable federated authentication between AWS and external identity providers, allowing users to access AWS resources using credentials from the external IdP. Adversaries who have gained administrative access may create rogue SAML providers to establish persistent, federated access to AWS accounts that survives credential rotation. This technique allows attackers to assume roles and access resources by forging SAML assertions from an IdP they control. Creating a SAML provider is a rare administrative action that should be closely monitored and validated against authorized infrastructure changes.", + "false_positives": [ + "SAML providers may be created during legitimate identity federation setup, SSO integration projects, or infrastructure-as-code deployments. Verify whether the user identity and timing align with approved change management processes. If this is expected administrative activity, 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 Created", + "note": "## Triage and analysis\n\n### Investigating AWS IAM SAML Provider Created\n\nSAML (Security Assertion Markup Language) providers in AWS IAM enable federated authentication, allowing users from external identity providers to access AWS resources without separate AWS credentials. Creating a SAML provider establishes a trust relationship between AWS and the external IdP.\n\nThis rule detects successful `CreateSAMLProvider` API calls. In most environments, SAML provider creation is extremely rare\u2014typically only occurring during initial SSO setup or major infrastructure changes. An unauthorized SAML provider creation could enable an attacker to maintain persistent access by forging SAML assertions from an IdP they control.\n\n### Possible investigation steps\n\n- **Identify the actor**\n - Review `aws.cloudtrail.user_identity.arn` to determine who created the SAML provider.\n - Verify whether this principal is authorized to manage identity federation.\n\n- **Review the SAML provider details**\n - Examine `aws.cloudtrail.request_parameters` for the SAML provider name and metadata document.\n - Identify the external IdP URL and signing certificate in the metadata.\n\n- **Validate business justification**\n - Confirm with identity management or platform teams whether this aligns with planned SSO integration.\n - Check for related change tickets or infrastructure-as-code deployments.\n\n- **Check for follow-on activity**\n - Search for `CreateRole` or `UpdateAssumeRolePolicy` calls that reference the new SAML provider.\n - Look for `AssumeRoleWithSAML` calls using the newly created provider.\n\n- **Correlate with other suspicious activity**\n - Check for preceding privilege escalation or credential access events.\n - Look for other persistence mechanisms being established concurrently.\n\n### False positive analysis\n\n- **Planned SSO integration**\n - SAML providers are created during initial setup of identity federation with Okta, Azure AD, or other IdPs.\n - Validate against documented SSO integration projects.\n\n- **Infrastructure-as-code deployments**\n - Terraform, CloudFormation, or other IaC tools may create SAML providers as part of automated deployments.\n - Confirm via CI/CD logs.\n\n### Response and remediation\n\n- **Immediate containment**\n - If unauthorized, delete the SAML provider using `DeleteSAMLProvider`.\n - Review and remove any IAM roles that trust the rogue provider.\n\n- **Investigation**\n - Audit CloudTrail for any `AssumeRoleWithSAML` calls using this provider.\n - Review all IAM roles with SAML trust relationships.\n\n- **Hardening**\n - Restrict `iam:CreateSAMLProvider` permissions to a limited set of administrative roles.\n - Implement SCPs to control SAML provider creation in member accounts.\n - Enable AWS Config rules to monitor identity provider configurations.\n\n### Additional information\n- **[AWS IAM SAML Providers Documentation](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_saml.html)**\n- **[AWS IR Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/)**\n- **[AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs)**\n", + "query": "event.dataset: \"aws.cloudtrail\"\n and event.provider: \"iam.amazonaws.com\"\n and event.action: \"CreateSAMLProvider\"\n and event.outcome: \"success\"\n", + "references": [ + "https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateSAMLProvider.html", + "https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_saml.html", + "https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-320a" + ], + "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": "a80ffc40-a256-475a-a86a-74361930cdb1", + "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": "T1078", + "name": "Valid Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/", + "subtechnique": [ + { + "id": "T1078.004", + "name": "Cloud Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/004/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0004", + "name": "Privilege Escalation", + "reference": "https://attack.mitre.org/tactics/TA0004/" + }, + "technique": [ + { + "id": "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": 1 + }, + "id": "a80ffc40-a256-475a-a86a-74361930cdb1_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/a8d35ca0-ad8d-48a9-9f6c-553622dca61a_8.json b/packages/security_detection_engine/kibana/security_rule/a8d35ca0-ad8d-48a9-9f6c-553622dca61a_8.json new file mode 100644 index 00000000000..003069e2fcc --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/a8d35ca0-ad8d-48a9-9f6c-553622dca61a_8.json @@ -0,0 +1,63 @@ +{ + "attributes": { + "anomaly_threshold": 70, + "author": [ + "Elastic" + ], + "description": "A machine learning job has detected unusually high variance of RDP session duration. Long RDP sessions can be used to evade detection mechanisms via session persistence, and might be used to perform tasks such as lateral movement, that might require uninterrupted access to a compromised machine.", + "from": "now-12h", + "interval": "15m", + "license": "Elastic License v2", + "machine_learning_job_id": "lmd_high_var_rdp_session_duration", + "name": "High Variance in RDP Session Duration", + "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 Variance in RDP Session Duration\n\nRemote Desktop Protocol (RDP) enables remote access to systems, facilitating legitimate administrative tasks. However, adversaries exploit prolonged RDP sessions to maintain persistent access, often for lateral movement within networks. The detection rule leverages machine learning to identify anomalies in session duration, flagging potential misuse by highlighting sessions with unusually high variance, which may indicate malicious activity.\n\n### Possible investigation steps\n\n- Review the specific RDP session details, including the start and end times, to understand the duration and identify any patterns or anomalies in session length.\n- Correlate the flagged RDP session with user activity logs to determine if the session aligns with known user behavior or scheduled administrative tasks.\n- Investigate the source and destination IP addresses involved in the RDP session to identify any unusual or unauthorized access points.\n- Check for any concurrent alerts or logs indicating lateral movement or other suspicious activities originating from the same source or targeting the same destination.\n- Analyze the user account associated with the RDP session for any signs of compromise, such as recent password changes, failed login attempts, or unusual access times.\n- Review the network traffic during the RDP session for any signs of data exfiltration or communication with known malicious IP addresses.\n\n### False positive analysis\n\n- Long RDP sessions for legitimate administrative tasks can trigger false positives. To manage this, identify and whitelist IP addresses or user accounts associated with routine administrative activities.\n- Scheduled maintenance or updates often require extended RDP sessions. Exclude these sessions by setting time-based exceptions during known maintenance windows.\n- Automated scripts or tools that require prolonged RDP access for monitoring or data collection can be mistaken for anomalies. Document and exclude these processes by recognizing their unique session patterns.\n- Remote support sessions from trusted third-party vendors may appear as high variance. Establish a list of trusted vendor IPs or accounts to prevent these from being flagged.\n- Training or demonstration sessions that involve extended RDP use should be accounted for by creating exceptions for specific user groups or departments involved in such activities.\n\n### Response and remediation\n\n- Immediately isolate the affected system from the network to prevent further lateral movement and potential data exfiltration.\n- Terminate the suspicious RDP session to disrupt any ongoing unauthorized activities.\n- Conduct a thorough review of the affected system for signs of compromise, including checking for unauthorized user accounts, installed software, and changes to system configurations.\n- Reset credentials for any accounts that were accessed during the suspicious RDP session to prevent further unauthorized access.\n- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited.\n- Monitor network traffic and system logs for any signs of continued or related suspicious activity, focusing on RDP connections and lateral movement patterns.\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.", + "references": [ + "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html", + "https://docs.elastic.co/en/integrations/lmd", + "https://www.elastic.co/blog/detecting-lateral-movement-activity-a-new-kibana-integration", + "https://www.elastic.co/blog/remote-desktop-protocol-connections-elastic-security" + ], + "related_integrations": [ + { + "package": "lmd", + "version": "^2.0.0" + }, + { + "package": "endpoint", + "version": "^8.2.0" + } + ], + "risk_score": 21, + "rule_id": "a8d35ca0-ad8d-48a9-9f6c-553622dca61a", + "setup": "## Setup\n\nThis rule requires the `host.ip` field to be populated.\nFor **Elastic Defend** events on versions **8.18 and above**, this field is **disabled by default**.\n\nIf you are using **Elastic Defend**, ensure host IP collection is enabled by following the configuration steps in the\n[helper guide](https://www.elastic.co/docs/solutions/security/configure-elastic-defend/configure-data-volume-for-elastic-endpoint#host-fields).\n\nThe rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration.\n\n### Lateral Movement Detection Setup\nThe Lateral Movement Detection integration detects lateral movement activity by identifying abnormalities in file and Windows RDP events. Anomalies are detected using Elastic's Anomaly Detection feature.\n\n#### Prerequisite Requirements:\n- Fleet is required for Lateral Movement Detection.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n- Windows RDP process events collected by the [Elastic Defend](https://docs.elastic.co/en/integrations/endpoint) integration.\n- To install Elastic Defend, refer to the [documentation](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n\n#### The following steps should be executed to install assets associated with the Lateral Movement Detection integration:\n- Go to the Kibana homepage. Under Management, click Integrations.\n- In the query bar, search for Lateral Movement Detection and select the integration to see more details about it.\n- Follow the instructions under the **Installation** section.\n- For this rule to work, complete the instructions through **Add preconfigured anomaly detection jobs**.\n", + "severity": "low", + "tags": [ + "Use Case: Lateral Movement Detection", + "Rule Type: ML", + "Rule Type: Machine Learning", + "Tactic: Lateral Movement", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0008", + "name": "Lateral Movement", + "reference": "https://attack.mitre.org/tactics/TA0008/" + }, + "technique": [ + { + "id": "T1210", + "name": "Exploitation of Remote Services", + "reference": "https://attack.mitre.org/techniques/T1210/" + } + ] + } + ], + "type": "machine_learning", + "version": 8 + }, + "id": "a8d35ca0-ad8d-48a9-9f6c-553622dca61a_8", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/ad84d445-b1ce-4377-82d9-7c633f28bf9a_216.json b/packages/security_detection_engine/kibana/security_rule/ad84d445-b1ce-4377-82d9-7c633f28bf9a_216.json new file mode 100644 index 00000000000..790b8100fe6 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/ad84d445-b1ce-4377-82d9-7c633f28bf9a_216.json @@ -0,0 +1,125 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects PowerShell scripts that includes a base64-encoded portable executable (PE) header, indicating an embedded binary payload. Attackers embed PEs in scripts to load payloads in memory and avoid writing executables to disk.", + "from": "now-9m", + "index": [ + "winlogbeat-*", + "logs-windows.powershell*" + ], + "investigation_fields": { + "field_names": [ + "@timestamp", + "user.name", + "user.id", + "user.domain", + "powershell.file.script_block_text", + "powershell.file.script_block_id", + "powershell.sequence", + "powershell.total", + "file.path", + "file.directory", + "file.name", + "process.pid", + "host.name", + "host.id", + "powershell.file.script_block_length" + ] + }, + "language": "kuery", + "license": "Elastic License v2", + "name": "Suspicious Portable Executable Encoded in Powershell Script", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This guide was created by humans with the assistance of generative AI. While its contents have been manually curated to include the most valuable information, always validate assumptions and adjust procedures to match your internal runbooks and incident triage and response policies.\n\n### Investigating Suspicious Portable Executable Encoded in Powershell Script\n\nThis alert indicates PowerShell Script Block Logging captured script content that contains a base64-encoded Portable Executable (PE) header pattern, suggesting an embedded Windows binary payload. This technique is commonly used to stage executables for in-memory loading or later execution while minimizing on-disk artifacts.\n\n#### Key alert fields to review\n\n- `user.name`, `user.domain`, `user.id`: Account execution context for correlation, prioritization, and scoping.\n- `host.name`, `host.id`: Host execution context for correlation, prioritization, and scoping.\n- `powershell.file.script_block_text`: Script block content that matched the detection logic.\n- `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`: Script block metadata to pivot to other fragments or reconstruct full script content when split across multiple events.\n- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file.\n- `powershell.file.script_block_length`: Script block length (size) context.\n\n#### Possible investigation steps\n\n- Capture and reconstruct the full script content:\n - Review `powershell.file.script_block_text` in full to identify the encoded blob boundaries and any surrounding helper logic (string concatenation, chunking, decryption, decompression, or obfuscation).\n - If `powershell.file.script_block_id` is present, collect all related events for that ID and use `powershell.sequence` and `powershell.total` to reconstruct the complete script when content is split across multiple records.\n - Confirm reconstruction completeness by ensuring the sequence range is consistent with `powershell.total` and that the combined content is coherent.\n - Use `powershell.file.script_block_length` to help prioritize unusually large script blocks that are more likely to contain full payloads or staged components.\n- Determine the script origin and execution context:\n - Use `user.name`, `user.domain`, and `user.id` to identify the initiating account and whether this activity is expected for that user (approved automation vs. unusual interactive activity).\n - Use `host.name` and `host.id` to identify the affected asset, its owner/role, and whether PowerShell automation is typical for this host.\n - If `file.path`, `file.directory`, or `file.name` are present, treat the alert as file-sourced script execution:\n - Validate whether the path and name align with approved administrative tooling and distribution locations.\n - Prioritize investigation when scripts are sourced from user-writable locations, temporary directories, or uncommon paths for your environment.\n- Identify likely payload handling behavior within the script:\n - Look for logic that transforms the encoded content into executable bytes and how it is consumed (written to disk, loaded as an assembly, reflectively invoked, or mapped into memory).\n - Note any secondary behaviors in the same script block that increase risk, such as staged downloads, persistence-related actions, or attempts to reduce visibility.\n - Identify whether the script constructs multiple encoded blobs, and document which blob is ultimately used for execution.\n- Scope the activity using alert pivots:\n - Search for additional script block events for the same `host.id` and `user.id` around `@timestamp` to identify lead-up actions and follow-on behavior.\n - Search across hosts for the same `powershell.file.script_block_text` patterns (the encoded header and any unique strings nearby) to identify other potentially affected systems.\n - If a script file is indicated by `file.path`/`file.name`, search for the same path/name across your environment to determine distribution and reuse.\n- Correlate with adjacent telemetry (if available):\n - Pivot on `host.id`/`host.name` and `@timestamp` into process telemetry to identify the PowerShell session and any processes that appear shortly after the script ran, which may indicate payload execution outcomes.\n - Pivot on `host.id`/`host.name` and `@timestamp` into network telemetry to identify outbound connections that could indicate payload retrieval or command-and-control activity shortly before or after script execution.\n - Review authentication activity for the same `user.id` around the alert time to identify unusual logons (unexpected host, timing, or access pattern) that could explain how the execution context was obtained.\n- Analyze the embedded payload in an isolated workflow (when permitted):\n - Decode the base64 content and validate whether it forms a legitimate PE.\n - Derive stable indicators (hashes, unique strings, and high-level metadata) and use them to widen the scope across endpoints and historical telemetry.\n - Preserve decoded artifacts and analysis notes according to your incident handling and evidence retention procedures.\n\n### False positive analysis\n\n- Approved administrative or deployment automation that embeds executables in PowerShell scripts for distribution in tightly controlled environments.\n- Vendor-provided installers, updaters, or management tooling that stages binaries through PowerShell as part of legitimate maintenance activity.\n- Authorized security testing or adversary emulation that intentionally uses embedded payloads or in-memory loading techniques.\n- False positives are more likely when `file.path` points to known software distribution locations and the executing `user.id` is an approved automation account; validate against change records and expected tooling.\n\n### Response and remediation\n\n- If the activity is unexpected or malicious:\n - Contain the affected host(s) based on criticality to prevent further execution or lateral movement.\n - Preserve evidence by saving the full reconstructed script content (using `powershell.file.script_block_id` plus all fragments, if split) and recording the associated `@timestamp`, `host.id`, `host.name`, and `user.id` for timeline reconstruction.\n- Assess scope and impact:\n - Hunt for the same script patterns across other hosts and users, and expand scoping using any indicators derived from payload analysis.\n - Review the initiating account for signs of compromise; apply credential hygiene actions per policy (reset credentials, revoke sessions, and review access).\n- Eradicate and recover:\n - Remove or remediate the script source indicated by `file.path` (if present) and any persistence mechanisms identified during triage (for example, suspicious or newly introduced services).\n - If a PE payload is confirmed, follow malware incident procedures to determine whether host reimaging or deeper forensic review is required.\n- Post-incident improvements:\n - Review PowerShell governance for the affected population (script approval processes, least privilege, and monitoring of script block content) to reduce recurrence.\n - Document validated benign patterns and trusted automation paths to streamline future triage and reduce alert fatigue.\n", + "query": "event.category:process and host.os.type:windows and\n powershell.file.script_block_text : (\n TVqQAAMAAAAEAAAA\n ) and not user.id : \"S-1-5-18\"\n", + "references": [ + "https://github.com/atc-project/atc-data/blob/master/docs/Logging_Policies/LP_0109_windows_powershell_script_block_log.md" + ], + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.category", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_text", + "type": "unknown" + }, + { + "ecs": true, + "name": "user.id", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "ad84d445-b1ce-4377-82d9-7c633f28bf9a", + "setup": "## Setup\n\nPowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104).\nSetup instructions: https://ela.st/powershell-logging-setup\n", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Execution", + "Tactic: Defense Evasion", + "Resources: Investigation Guide", + "Data Source: PowerShell Logs" + ], + "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/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1055", + "name": "Process Injection", + "reference": "https://attack.mitre.org/techniques/T1055/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 216 + }, + "id": "ad84d445-b1ce-4377-82d9-7c633f28bf9a_216", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/b07f0fba-0a78-11f0-8311-b66272739ecb_2.json b/packages/security_detection_engine/kibana/security_rule/b07f0fba-0a78-11f0-8311-b66272739ecb_2.json deleted file mode 100644 index 962bf041e4e..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/b07f0fba-0a78-11f0-8311-b66272739ecb_2.json +++ /dev/null @@ -1,91 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "This rule monitors for the unusual occurrence of outbound network connections to suspicious webservice domains.", - "from": "now-9m", - "history_window_start": "now-7d", - "index": [ - "logs-endpoint.events.network-*" - ], - "language": "kuery", - "license": "Elastic License v2", - "name": "Unusual Network Connection to Suspicious Web Service", - "new_terms_fields": [ - "host.id", - "process.executable", - "destination.domain" - ], - "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 Network Connection to Suspicious Web Service\n\nIn macOS environments, network connections to web services are routine for data sharing and collaboration. However, adversaries exploit these services for command and control by disguising malicious traffic as legitimate. The detection rule identifies unusual outbound connections to known suspicious domains, flagging potential misuse by monitoring specific domain patterns and connection events, thus aiding in early threat detection.\n\n### Possible investigation steps\n\n- Review the destination domain and process executable from the alert to determine if it matches any expected web service communication.\n- Check the event.category and event.type fields to confirm the nature of the network connection and ensure it aligns with the expected behavior of a macOS system.\n- Investigate the source host identified by host.os.type to gather information about its recent activities, installed applications, and any potential indicators of compromise.\n- Analyze network traffic logs for the source host to identify any other unusual or suspicious outbound connections that may indicate a broader compromise.\n- Correlate the alert with other security events or alerts from the same host or network segment to identify patterns or related incidents.\n- Consult threat intelligence sources to gather additional context on the flagged domain and assess its reputation and history of malicious activity.\n\n### False positive analysis\n\n- Frequent access to legitimate cloud storage services like Google Drive or Dropbox for routine file sharing can trigger false positives. Users can create exceptions for specific domains or IP addresses known to be safe and frequently accessed by their organization.\n- Automated backup services that use domains such as OneDrive or SharePoint may be flagged. To mitigate this, identify and whitelist the specific services or applications that are part of regular backup operations.\n- Collaboration tools like Slack or Discord, used for legitimate communication, might be mistakenly flagged. Users should review and whitelist these domains if they are part of standard business operations.\n- URL shorteners like bit.ly or tinyurl.com used in marketing or communication campaigns can cause false alerts. Establish a list of trusted shortener services and exclude them from monitoring if they are regularly used by the organization.\n- Development and testing environments using services like ngrok or localtunnel for temporary public URLs can be misidentified. Ensure these environments are documented and excluded from the rule if they are part of normal development workflows.\n\n### Response and remediation\n\n- Immediately isolate the affected macOS device from the network to prevent further communication with the suspicious domains.\n- Conduct a thorough review of the network logs to identify any data exfiltration attempts or additional suspicious connections originating from the isolated device.\n- Remove any unauthorized or suspicious applications or scripts found on the device that may be facilitating the outbound connections.\n- Update the device's security software and perform a full system scan to detect and remove any malware or unauthorized software.\n- Reset credentials and review access permissions for the affected user accounts to prevent unauthorized access.\n- Monitor the network for any further attempts to connect to the flagged domains and ensure that alerts are configured to notify security teams of any recurrence.\n- Escalate the incident to the security operations center (SOC) or relevant cybersecurity team for further investigation and to determine if the threat is part of a larger attack campaign.\n", - "query": "event.category : \"network\" and host.os.type : \"macos\" and event.type : \"start\" and\ndestination.domain : (\n pastebin.* or\n paste.ee or\n ghostbin.com or\n drive.google.com or\n ?.docs.live.net or\n api.dropboxapi.* or\n content.dropboxapi.* or\n *dl.dropboxusercontent.* or\n api.onedrive.com or\n *.onedrive.org or\n onedrive.live.com or\n filebin.net or\n *.ngrok.io or\n ngrok.com or\n *.portmap.* or\n *serveo.net or\n *localtunnel.me or\n *pagekite.me or\n *localxpose.io or\n *notabug.org or\n rawcdn.githack.* or\n paste.nrecom.net or\n zerobin.net or\n controlc.com or\n requestbin.net or\n api.slack.com or\n slack-redir.net or\n slack-files.com or\n cdn.discordapp.com or\n discordapp.com or\n discord.com or\n apis.azureedge.net or\n cdn.sql.gg or\n ?.top4top.io or\n top4top.io or\n uplooder.net or\n *.cdnmegafiles.com or\n transfer.sh or\n updates.peer2profit.com or\n api.telegram.org or\n t.me or\n meacz.gq or\n rwrd.org or\n *.publicvm.com or\n *.blogspot.com or\n api.mylnikov.org or\n script.google.com or\n script.googleusercontent.com or\n paste4btc.com or\n workupload.com or\n temp.sh or\n filetransfer.io or\n gofile.io or\n store?.gofile.io or\n tiny.one or\n api.notion.com or\n *.sharepoint.com or\n *upload.ee or\n bit.ly or\n t.ly or\n cutt.ly or\n mbasic.facebook.com or\n api.gofile.io or\n file.io or\n api.anonfiles.com or\n api.trello.com or\n gist.githubusercontent.com or\n dpaste.com or\n *azurewebsites.net or\n *.zulipchat.com or\n *.4shared.com or\n filecloud.me or\n i.ibb.co or\n files.catbox.moe or\n *.getmyip.com or\n mockbin.org or\n webhook.site or\n run.mocky.io or\n *infinityfreeapp.com or\n free.keep.sh or\n tinyurl.com or\n ftpupload.net or\n lobfile.com or\n *.ngrok-free.app or\n myexternalip.com or\n yandex.ru or\n *.yandex.ru or\n *.aternos.me or\n cdn??.space or\n *.pcloud.com or\n mediafire.zip or\n urlz.fr or\n rentry.co or\n *.b-cdn.net or\n pastecode.dev or\n i.imgur.com or\n the.earth.li or\n *.trycloudflare.com\n)\n", - "related_integrations": [ - { - "package": "endpoint", - "version": "^9.0.0" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "destination.domain", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.category", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.type", - "type": "keyword" - }, - { - "ecs": true, - "name": "host.os.type", - "type": "keyword" - } - ], - "risk_score": 47, - "rule_id": "b07f0fba-0a78-11f0-8311-b66272739ecb", - "severity": "medium", - "tags": [ - "Domain: Endpoint", - "OS: macOS", - "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/", - "subtechnique": [ - { - "id": "T1071.001", - "name": "Web Protocols", - "reference": "https://attack.mitre.org/techniques/T1071/001/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "new_terms", - "version": 2 - }, - "id": "b07f0fba-0a78-11f0-8311-b66272739ecb_2", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/b0c98cfb-0745-4513-b6f9-08dddb033490_5.json b/packages/security_detection_engine/kibana/security_rule/b0c98cfb-0745-4513-b6f9-08dddb033490_5.json deleted file mode 100644 index 1cd13461b98..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/b0c98cfb-0745-4513-b6f9-08dddb033490_5.json +++ /dev/null @@ -1,148 +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// Filter out smaller scripts that are unlikely to implement obfuscation using the patterns we are looking for\n| eval Esql.script_block_length = length(powershell.file.script_block_text)\n| where Esql.script_block_length > 500\n\n// replace the patterns we are looking for with the \ud83d\udd25 emoji to enable counting them\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| eval Esql.script_block_tmp = replace(\n powershell.file.script_block_text,\n \"\"\"(?i)(\\$(?:\\w+|\\w+\\:\\w+)\\[\\d++\\]\\+\\$(?:\\w+|\\w+\\:\\w+)\\[\\d++\\]\\+['\"]x['\"]|\\$(?:\\w+\\:\\w+)\\[\\d++,\\d++,\\d++\\]|\\.name\\[\\d++,\\d++,\\d++\\])\"\"\",\n \"\ud83d\udd25\"\n)\n\n// count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| eval Esql.script_block_pattern_count = length(Esql.script_block_tmp) - length(replace(Esql.script_block_tmp, \"\ud83d\udd25\", \"\"))\n\n// keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| keep\n Esql.script_block_pattern_count,\n Esql.script_block_length,\n Esql.script_block_tmp,\n powershell.file.script_block_text,\n powershell.file.script_block_id,\n file.path,\n powershell.sequence,\n powershell.total,\n _id,\n _index,\n host.name,\n agent.id,\n user.id\n\n// Filter for scripts that match the pattern at least once\n| where Esql.script_block_pattern_count >= 1\n", - "related_integrations": [ - { - "package": "windows", - "version": "^3.0.0" - } - ], - "required_fields": [ - { - "ecs": false, - "name": "Esql.script_block_length", - "type": "integer" - }, - { - "ecs": false, - "name": "Esql.script_block_pattern_count", - "type": "integer" - }, - { - "ecs": false, - "name": "Esql.script_block_tmp", - "type": "keyword" - }, - { - "ecs": false, - "name": "_id", - "type": "keyword" - }, - { - "ecs": false, - "name": "_index", - "type": "keyword" - }, - { - "ecs": true, - "name": "agent.id", - "type": "keyword" - }, - { - "ecs": true, - "name": "file.path", - "type": "keyword" - }, - { - "ecs": true, - "name": "host.name", - "type": "keyword" - }, - { - "ecs": false, - "name": "powershell.file.script_block_id", - "type": "keyword" - }, - { - "ecs": false, - "name": "powershell.file.script_block_text", - "type": "text" - }, - { - "ecs": false, - "name": "powershell.sequence", - "type": "long" - }, - { - "ecs": false, - "name": "powershell.total", - "type": "long" - }, - { - "ecs": true, - "name": "user.id", - "type": "keyword" - } - ], - "risk_score": 47, - "rule_id": "b0c98cfb-0745-4513-b6f9-08dddb033490", - "setup": "## Setup\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nAdministrative Templates >\nWindows PowerShell >\nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n", - "severity": "medium", - "tags": [ - "Domain: Endpoint", - "OS: Windows", - "Use Case: Threat Detection", - "Tactic: Defense Evasion", - "Data Source: PowerShell Logs", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0005", - "name": "Defense Evasion", - "reference": "https://attack.mitre.org/tactics/TA0005/" - }, - "technique": [ - { - "id": "T1027", - "name": "Obfuscated Files or Information", - "reference": "https://attack.mitre.org/techniques/T1027/" - }, - { - "id": "T1140", - "name": "Deobfuscate/Decode Files or Information", - "reference": "https://attack.mitre.org/techniques/T1140/" - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0002", - "name": "Execution", - "reference": "https://attack.mitre.org/tactics/TA0002/" - }, - "technique": [ - { - "id": "T1059", - "name": "Command and Scripting Interpreter", - "reference": "https://attack.mitre.org/techniques/T1059/", - "subtechnique": [ - { - "id": "T1059.001", - "name": "PowerShell", - "reference": "https://attack.mitre.org/techniques/T1059/001/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 5 - }, - "id": "b0c98cfb-0745-4513-b6f9-08dddb033490_5", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/b0c98cfb-0745-4513-b6f9-08dddb033490_9.json b/packages/security_detection_engine/kibana/security_rule/b0c98cfb-0745-4513-b6f9-08dddb033490_9.json new file mode 100644 index 00000000000..280823f31bd --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/b0c98cfb-0745-4513-b6f9-08dddb033490_9.json @@ -0,0 +1,207 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects PowerShell scripts that reconstructs IEX (Invoke-Expression) by indexing environment variable strings (for example, $env:VAR[1,2,3]) or related `.name[...]` slices and joining characters at runtime. Attackers use environment-variable slicing to hide dynamic execution and evade keyword-based detections and AMSI.", + "from": "now-9m", + "investigation_fields": { + "field_names": [ + "@timestamp", + "user.name", + "user.id", + "user.domain", + "powershell.file.script_block_text", + "powershell.file.script_block_id", + "powershell.sequence", + "powershell.total", + "file.path", + "file.directory", + "file.name", + "process.pid", + "host.name", + "host.id", + "powershell.file.script_block_length" + ] + }, + "language": "esql", + "license": "Elastic License v2", + "name": "Potential Dynamic IEX Reconstruction via Environment Variables", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This guide was created by humans with the assistance of generative AI. While its contents have been manually curated to include the most valuable information, always validate assumptions and adjust procedures to match your internal runbooks and incident triage and response policies.\n\n### Investigating Potential Dynamic IEX Reconstruction via Environment Variables\n\nThis alert indicates PowerShell Script Block Logging captured a script that builds \"IEX\" (Invoke-Expression) at runtime by indexing characters from environment variable strings or related name properties and combining them. This technique is commonly used to obscure dynamic execution and can indicate an attempt to execute attacker-controlled content.\n\n#### Key alert fields to review\n\n- `user.name`, `user.domain`, `user.id`: Account execution context for correlation, prioritization, and scoping.\n- `host.name`, `host.id`: Host execution context for correlation, prioritization, and scoping.\n- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file.\n- `powershell.file.script_block_text`: Script block content that matched the detection logic.\n- `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`: Script block metadata to pivot to other fragments or reconstruct full script content when split across multiple events.\n- `Esql.script_block_tmp`: Transformed script block where detection patterns replace original content with a marker to support scoring/counting and quickly spot match locations.\n- `Esql.script_block_pattern_count`: Count of matches for the detection pattern(s) observed in the script block content.\n- `powershell.file.script_block_entropy_bits`: Shannon entropy of the script block. Higher values may indicate obfuscation.\n- `powershell.file.script_block_surprisal_stdev`: Standard deviation of surprisal across the script block. Low values indicate uniform randomness. High values indicate mixed patterns and variability.\n- `powershell.file.script_block_unique_symbols`: Count of distinct characters present in the script block.\n- `powershell.file.script_block_length`: Script block length (size) context.\n\n#### Possible investigation steps\n\n- Confirm scope and execution context:\n - Review `host.name` and `host.id` to identify the impacted endpoint and determine whether it is a typical user workstation, server, or a special-purpose system in your environment.\n - Review `user.name`, `user.domain`, and `user.id` to understand who executed the script and whether the account is expected to run PowerShell on this host (interactive user, service account, or administrative context).\n - Use `agent.id` (if available) to identify the reporting agent and to support correlation with other telemetry collected from the same endpoint.\n - Use the alert timestamp as the anchor to correlate activity immediately before and after the script block ran.\n\n- Analyze the obfuscation and intended execution:\n - Examine `powershell.file.script_block_text` to locate environment-variable slicing patterns (for example, `$env:[]`, `$env:[,,]`, or `.name[,,]`) and identify the variable names and indices being used.\n - Use `Esql.script_block_tmp` to quickly find the match locations, then review the surrounding context in `powershell.file.script_block_text` to determine how the reconstructed string is used (assignment, concatenation/join, or immediate invocation).\n - Determine whether the reconstructed output is used as a dynamic execution primitive (for example, passed to `Invoke-Expression` / `IEX`, used with the call operator, or invoked via a method). Focus on what content is ultimately evaluated or executed.\n\n- Reconstruct full script content:\n - If the script appears incomplete or staged across multiple events, use `powershell.file.script_block_id` with `powershell.sequence` and `powershell.total` to collect all fragments and rebuild the full script in order.\n - After reconstruction, identify where string construction occurs versus where execution occurs to understand the end-to-end flow.\n\n- Assess obfuscation level and intent using available enrichments:\n - Review `Esql.script_block_pattern_count` to understand how frequently the reconstruction pattern appears within the script block; repeated occurrences can indicate systematic obfuscation rather than an isolated string operation.\n - Review `powershell.file.script_block_length` for size context and compare it with typical script sizes seen for the same host or user.\n - Review `powershell.file.script_block_entropy_bits`, `powershell.file.script_block_surprisal_stdev`, and `powershell.file.script_block_unique_symbols` to gauge whether the script contains encoded or highly obfuscated content (for example, large high-entropy blocks that may indicate packed or encoded data).\n\n- Identify script origin and potential spread:\n - If `file.path` is populated, review `file.name` and `file.directory` to determine where the script was sourced from and whether the location aligns with approved administrative tooling or software distribution paths.\n - If `file.path` is not populated, treat the activity as potentially inline or dynamically generated and prioritize identifying the initiating process or source using adjacent telemetry.\n - Scope for other alerts or script blocks on the same `host.id` or associated with the same `user.id` that show similar reconstruction patterns, especially within the same time window.\n\n- Correlate with adjacent telemetry (as available in your environment):\n - Using `host.id` / `host.name`, `user.id`, and the alert time, correlate with process execution data to identify the PowerShell host process and the initiating parent process or source (for example, interactive session, script runner, scheduled task, service, or another application).\n - Correlate with network, file, registry, and authentication telemetry on the same host around the alert time to identify follow-on activity that supports malicious intent (download or retrieval of content, creation or modification of files, persistence-related changes, or suspicious logons).\n\n### False positive analysis\n\n- Legitimate automation or administration scripts may construct command strings dynamically, including deriving short tokens from environment variables for compatibility or to reduce hard-coded strings.\n- Security testing and purple-team or red-team activity may intentionally use environment-variable slicing to emulate evasive tradecraft.\n- Developer tooling, obfuscation research, or PowerShell training content may include this technique. Benign usage is typically tied to known owners, consistent hosts, predictable execution windows, and the absence of suspicious downstream activity.\n\n### Response and remediation\n\n- If the activity is suspected or confirmed malicious:\n - Contain the affected host to prevent additional execution and reduce lateral movement risk.\n - Preserve evidence by collecting the complete script content using `powershell.file.script_block_id`, `powershell.sequence`, and `powershell.total`, and retain the original `powershell.file.script_block_text` for analysis.\n - Extract and track indicators from the script content (for example, URLs, domains, IP addresses, file names, or unique strings) and scope for additional occurrences across the environment using `host.id`, `host.name`, `user.id`, and `file.path` when present.\n - Identify and remediate the initial execution source (parent process or launching mechanism) and remove or quarantine any associated script files referenced by `file.path`.\n - If account compromise is suspected, reset affected credentials and review for additional suspicious PowerShell activity associated with the same `user.id`.\n\n- If the activity is determined to be benign:\n - Document the business justification, owning team, expected hosts, and expected script location (`file.path` when present).\n - Monitor for deviations in execution context (new hosts, new users, or materially different script content) and consider targeted tuning based on stable attributes such as `file.path` and known `user.id` values.\n", + "query": "from logs-windows.powershell_operational* metadata _id, _version, _index\n| where event.code == \"4104\"\n\n// Filter out smaller scripts that are unlikely to implement obfuscation using the patterns we are looking for\n| eval Esql.script_block_length = length(powershell.file.script_block_text)\n| where Esql.script_block_length > 500\n\n// replace the patterns we are looking for with the \ud83d\udd25 emoji to enable counting them\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| eval Esql.script_block_tmp = replace(\n powershell.file.script_block_text,\n \"\"\"(?i)(\\$(?:\\w+|\\w+\\:\\w+)\\[\\d++\\]\\+\\$(?:\\w+|\\w+\\:\\w+)\\[\\d++\\]\\+['\"]x['\"]|\\$(?:\\w+\\:\\w+)\\[\\d++,\\d++,\\d++\\]|\\.name\\[\\d++,\\d++,\\d++\\])\"\"\",\n \"\ud83d\udd25\"\n)\n\n// count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| eval Esql.script_block_pattern_count = length(Esql.script_block_tmp) - length(replace(Esql.script_block_tmp, \"\ud83d\udd25\", \"\"))\n\n// keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| keep\n Esql.script_block_pattern_count,\n Esql.script_block_length,\n Esql.script_block_tmp,\n powershell.file.*,\n file.path,\n powershell.sequence,\n powershell.total,\n _id,\n _version,\n _index,\n host.name,\n host.id,\n agent.id,\n user.id\n\n// Filter for scripts that match the pattern at least once\n| where Esql.script_block_pattern_count >= 1\n", + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.script_block_length", + "type": "integer" + }, + { + "ecs": false, + "name": "Esql.script_block_pattern_count", + "type": "integer" + }, + { + "ecs": false, + "name": "Esql.script_block_tmp", + "type": "keyword" + }, + { + "ecs": false, + "name": "_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "_index", + "type": "keyword" + }, + { + "ecs": false, + "name": "_version", + "type": "long" + }, + { + "ecs": true, + "name": "agent.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.path", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.name", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_entropy_bits", + "type": "double" + }, + { + "ecs": false, + "name": "powershell.file.script_block_entropy_normalized", + "type": "double" + }, + { + "ecs": false, + "name": "powershell.file.script_block_hash", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_length", + "type": "long" + }, + { + "ecs": false, + "name": "powershell.file.script_block_surprisal_stdev", + "type": "double" + }, + { + "ecs": false, + "name": "powershell.file.script_block_text", + "type": "text" + }, + { + "ecs": false, + "name": "powershell.file.script_block_unique_symbols", + "type": "long" + }, + { + "ecs": false, + "name": "powershell.sequence", + "type": "long" + }, + { + "ecs": false, + "name": "powershell.total", + "type": "long" + }, + { + "ecs": true, + "name": "user.id", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "b0c98cfb-0745-4513-b6f9-08dddb033490", + "setup": "## Setup\n\nPowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104).\nSetup instructions: https://ela.st/powershell-logging-setup\n", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: PowerShell Logs", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1027", + "name": "Obfuscated Files or Information", + "reference": "https://attack.mitre.org/techniques/T1027/" + }, + { + "id": "T1140", + "name": "Deobfuscate/Decode Files or Information", + "reference": "https://attack.mitre.org/techniques/T1140/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.001", + "name": "PowerShell", + "reference": "https://attack.mitre.org/techniques/T1059/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 9 + }, + "id": "b0c98cfb-0745-4513-b6f9-08dddb033490_9", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/b2951150-658f-4a60-832f-a00d1e6c6745_212.json b/packages/security_detection_engine/kibana/security_rule/b2951150-658f-4a60-832f-a00d1e6c6745_212.json new file mode 100644 index 00000000000..a026bf2e20e --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/b2951150-658f-4a60-832f-a00d1e6c6745_212.json @@ -0,0 +1,91 @@ +{ + "attributes": { + "author": [ + "Austin Songer" + ], + "description": "Identifies that a user has deleted an unusually large volume of files as reported by Microsoft Cloud App Security.", + "false_positives": [ + "Users or System Administrator cleaning out folders." + ], + "from": "now-9m", + "index": [ + "logs-o365.audit-*", + "filebeat-*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "Deprecated - M365 Security Compliance Unusual Volume of File 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 - M365 Security Compliance Unusual Volume of File Deletion\n\nMicrosoft 365's cloud environment facilitates file storage and collaboration, but its vast data handling capabilities can be exploited by adversaries for data destruction. Attackers may delete large volumes of files to disrupt operations or cover their tracks. The detection rule leverages audit logs to identify anomalies in file deletion activities, flagging successful, unusual deletion volumes as potential security incidents, thus enabling timely investigation and response.\n\n### Possible investigation steps\n\n- Review the audit logs for the specific user associated with the alert to confirm the volume and context of the file deletions, focusing on entries with event.action:\"Unusual volume of file deletion\" and event.outcome:success.\n- Correlate the timestamps of the deletion events with other activities in the user's account to identify any suspicious patterns or anomalies, such as unusual login locations or times.\n- Check for any recent changes in user permissions or roles that might explain the ability to delete a large volume of files, ensuring these align with the user's typical responsibilities.\n- Investigate any recent security alerts or incidents involving the same user or related accounts to determine if this activity is part of a broader attack or compromise.\n- Contact the user or their manager to verify if the deletions were intentional and authorized, and gather any additional context that might explain the activity.\n- Assess the impact of the deletions on business operations and data integrity, and determine if any recovery actions are necessary to restore critical files.\n\n### False positive analysis\n\n- High-volume legitimate deletions during data migration or cleanup projects can trigger false positives. To manage this, create exceptions for users or groups involved in these activities during the specified time frame.\n- Automated processes or scripts that perform bulk deletions as part of routine maintenance may be flagged. Identify these processes and whitelist them to prevent unnecessary alerts.\n- Users with roles in data management or IT support may regularly delete large volumes of files as part of their job responsibilities. Establish a baseline for these users and adjust the detection thresholds accordingly.\n- Temporary spikes in file deletions due to organizational changes, such as department restructuring, can be mistaken for malicious activity. Monitor these events and temporarily adjust the rule parameters to accommodate expected changes.\n- Regularly review and update the list of exceptions to ensure that only legitimate activities are excluded from alerts, maintaining the effectiveness of the detection rule.\n\n### Response and remediation\n\n- Immediately isolate the affected user account to prevent further unauthorized file deletions. This can be done by disabling the account or changing the password.\n- Review the audit logs to identify the scope of the deletion and determine if any critical or sensitive files were affected. Restore these files from backups if available.\n- Conduct a thorough review of the affected user's recent activities to identify any other suspicious actions or potential indicators of compromise.\n- Escalate the incident to the security operations team for further investigation and to determine if the deletion is part of a larger attack or breach.\n- Implement additional monitoring on the affected account and similar high-risk accounts to detect any further unusual activities.\n- Review and update access controls and permissions to ensure that users have the minimum necessary access to perform their job functions, reducing the risk of large-scale deletions.\n- Coordinate with the IT and security teams to conduct a post-incident review, identifying any gaps in the response process and implementing improvements to prevent recurrence.", + "query": "event.dataset:o365.audit and event.provider:SecurityComplianceCenter and event.category:web and event.action:\"Unusual volume of file deletion\" and event.outcome:success\n", + "references": [ + "https://docs.microsoft.com/en-us/cloud-app-security/anomaly-detection-policy", + "https://docs.microsoft.com/en-us/cloud-app-security/policy-template-reference" + ], + "related_integrations": [ + { + "package": "o365", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.category", + "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": "b2951150-658f-4a60-832f-a00d1e6c6745", + "setup": "The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Data Source: Microsoft 365", + "Use Case: Configuration Audit", + "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/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 212 + }, + "id": "b2951150-658f-4a60-832f-a00d1e6c6745_212", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/b5877334-677f-4fb9-86d5-a9721274223b_318.json b/packages/security_detection_engine/kibana/security_rule/b5877334-677f-4fb9-86d5-a9721274223b_318.json new file mode 100644 index 00000000000..74d932563c0 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/b5877334-677f-4fb9-86d5-a9721274223b_318.json @@ -0,0 +1,152 @@ +{ + "attributes": { + "author": [ + "Austin Songer" + ], + "description": "Identifies when a user attempts to clear console history. An adversary may clear the command history of a compromised account to conceal the actions undertaken during an intrusion.", + "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": "Clearing Windows Console History", + "note": "## Triage and analysis\n\n### Investigating Clearing Windows Console History\n\nPowerShell is one of the main tools system administrators use for automation, report routines, and other tasks. This makes it available for use in various environments, and creates an attractive way for attackers to execute code.\n\nAttackers can try to cover their tracks by clearing PowerShell console history. PowerShell has two different ways of logging commands: the built-in history and the command history managed by the PSReadLine module. This rule looks for the execution of commands that can clear the built-in PowerShell logs or delete the `ConsoleHost_history.txt` file.\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- 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 - Verify if any other anti-forensics behaviors were observed.\n- Investigate the PowerShell logs on the SIEM to determine if there was suspicious behavior that an attacker may be trying to cover up.\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 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 - Ensure that PowerShell auditing policies and log collection are in place to grant future visibility.\n", + "query": "process where host.os.type == \"windows\" and event.type == \"start\" and\n (\n process.name : (\"powershell.exe\", \"pwsh.exe\", \"powershell_ise.exe\") or\n ?process.pe.original_file_name in (\"PowerShell.EXE\", \"pwsh.dll\", \"powershell_ise.EXE\")\n ) and\n (\n process.command_line : \"*Clear-History*\" or\n (\n process.command_line : (\"*Remove-Item*\", \"* rm *\") and\n process.command_line : (\"*ConsoleHost_history.txt*\", \"*(Get-PSReadlineOption).HistorySavePath*\")\n ) or\n (process.command_line : \"*Set-PSReadlineOption*\" and process.command_line : \"*SaveNothing*\")\n )\n", + "references": [ + "https://stefanos.cloud/kb/how-to-clear-the-powershell-command-history/", + "https://www.shellhacks.com/clear-history-powershell/", + "https://community.sophos.com/sophos-labs/b/blog/posts/powershell-command-history-forensics" + ], + "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": "^3.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": 47, + "rule_id": "b5877334-677f-4fb9-86d5-a9721274223b", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Tactic: Execution", + "Resources: Investigation Guide", + "Data Source: Elastic Endgame", + "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": "T1070", + "name": "Indicator Removal", + "reference": "https://attack.mitre.org/techniques/T1070/", + "subtechnique": [ + { + "id": "T1070.003", + "name": "Clear Command History", + "reference": "https://attack.mitre.org/techniques/T1070/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.001", + "name": "PowerShell", + "reference": "https://attack.mitre.org/techniques/T1059/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 318 + }, + "id": "b5877334-677f-4fb9-86d5-a9721274223b_318", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/b627cd12-dac4-11ec-9582-f661ea17fbcd_112.json b/packages/security_detection_engine/kibana/security_rule/b627cd12-dac4-11ec-9582-f661ea17fbcd_112.json new file mode 100644 index 00000000000..9f84f203c3a --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/b627cd12-dac4-11ec-9582-f661ea17fbcd_112.json @@ -0,0 +1,83 @@ +{ + "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 == \"start\" and\n (process.name in (\"systemctl\", \"service\", \"chkconfig\", \"update-rc.d\") and\n process.args : (\"elastic-agent\", \"elastic-agent.service\", \"ElasticEndpoint\") and\n process.args : (\"stop\", \"disable\", \"remove\", \"off\", \"kill\", \"mask\"))\n or\n /* pkill , killall used to stop Elastic Agent or Endpoint on Linux */\n(event.type == \"start\" and process.name in (\"pkill\", \"killall\", \"kill\") and process.args : (\"elastic-agent\", \"elastic-endpoint\"))\n or\n /* Unload Elastic Defend extension on MacOS */\n(event.type == \"start\" and process.name : \"kextunload\" and process.args : \"com.apple.iokit.EndpointSecurity\"))\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + } + ], + "required_fields": [ + { + "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": 112 + }, + "id": "b627cd12-dac4-11ec-9582-f661ea17fbcd_112", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/b7f77c3c-1bcb-4afc-9ace-49357007947b_2.json b/packages/security_detection_engine/kibana/security_rule/b7f77c3c-1bcb-4afc-9ace-49357007947b_2.json new file mode 100644 index 00000000000..1e28a83030a --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/b7f77c3c-1bcb-4afc-9ace-49357007947b_2.json @@ -0,0 +1,99 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule correlates multiple security alerts from a host exhibiting unusually high CPU utilization within a short time window. This behavior may indicate malicious activity such as malware execution, cryptomining, exploit payload execution, or abuse of system resources following initial compromise.", + "from": "now-9m", + "interval": "5m", + "language": "esql", + "license": "Elastic License v2", + "name": "Multiple Alerts on a Host Exhibiting CPU Spike", + "note": "## Triage and analysis\n\n### Investigating Multiple Alerts on a Host Exhibiting CPU Spike\n\nThis rule identifies hosts that both triggered multiple security alerts and exhibited unusually high CPU utilization on the\nwithin a short time window. This combination may indicate malicious execution, resource abuse, or post-compromise activity.\n\n### Possible investigation steps\n- Review the correlated alert(s) to understand why the host was flagged by the detection alerts.\n- Examine the involved process name, command line, and SHA-256 hash to determine whether those processes are expected or known to be malicious.\n- Validate the observed CPU usage and duration to determine whether the spike is abnormal for this process and host.\n- Check for related process activity such as parent/child processes, suspicious process spawning, or privilege escalation attempts.\n- Review additional host telemetry including:\n - Network connections initiated by the process\n - File creation or modification events\n - Persistence mechanisms (services, scheduled tasks, registry keys)\n- Determine whether similar activity is observed on other hosts, which may indicate a broader compromise.\n\n### False positive analysis\n- Legitimate high-CPU processes such as software updates, backup agents, security scans, or system maintenance tasks.\n- Resource-intensive but benign applications (e.g., compilers, video encoding, data processing jobs).\n- Security tools or monitoring agents temporarily consuming high CPU.\n\n### Response and remediation\n- If malicious activity is confirmed, isolate the affected host to prevent further impact.\n- Terminate the offending process if safe to do so.\n- Remove any identified malicious binaries or artifacts and eliminate persistence mechanisms.\n- Apply relevant patches or configuration changes to remediate the root cause.\n- Monitor the environment for recurrence of similar high-CPU processes combined with security alerts.\n- Escalate the incident if multiple hosts or indicators suggest coordinated or widespread activity.", + "query": "FROM metrics-*, .alerts-security.* METADATA _index\n| where not KQL(\"\"\"kibana.alert.rule.tags : \"Rule Type: Higher-Order Rule\" \"\"\")\n| eval\n // hosts with more than 90% total CPU use\n cpu_metrics_host_ids = CASE(_index like \".ds-metrics-system.cpu-*\" and system.cpu.total.norm.pct >= 0.9, host.id, null),\n // hosts with high severity security alerts\n alerts_host_ids = CASE(_index like \".internal.alerts-security.*\" and kibana.alert.rule.name is not null and host.id is not null and kibana.alert.risk_score >= 73, host.id, null)\n| stats host_with_cpu_spike = COUNT_DISTINCT(cpu_metrics_host_ids),\n host_with_alerts = COUNT_DISTINCT(alerts_host_ids),\n Esql.max_cpu_pct = MAX(system.cpu.total.norm.pct),\n Esql.unique_alerts_count = COUNT_DISTINCT(kibana.alert.rule.name),\n Esql.unique_process_count = COUNT_DISTINCT(process.entity_id),\n Esql.alerts = VALUES(kibana.alert.rule.name),\n Esql.process_hash_sha256 = VALUES(process.hash.sha256),\n process_path = VALUES(process.executable),\n parent_process_path = VALUES(process.parent.executable),\n user_name = VALUES(user.name),\n cmdline = VALUES(process.command_line) by host.id\n// at least 3 unique high severity alerts and from a host with 90% CPU use\n| where host_with_cpu_spike > 0 and host_with_alerts > 0 and Esql.unique_alerts_count >= 3\n| eval process.hash.sha256 = MV_FIRST(Esql.process_hash_sha256),\n process.executable = MV_FIRST(process_path),\n process.parent.executable = MV_FIRST(parent_process_path),\n process.command_line = MV_FIRST(cmdline),\n user.name = MV_FIRST(user_name)\n| KEEP user.name, host.id, process.*, Esql.*\n", + "required_fields": [ + { + "ecs": false, + "name": "Esql.alerts", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.max_cpu_pct", + "type": "double" + }, + { + "ecs": false, + "name": "Esql.process_hash_sha256", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.unique_alerts_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.unique_process_count", + "type": "long" + }, + { + "ecs": true, + "name": "host.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.command_line", + "type": "wildcard" + }, + { + "ecs": true, + "name": "process.executable", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.hash.sha256", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.executable", + "type": "keyword" + }, + { + "ecs": true, + "name": "user.name", + "type": "keyword" + } + ], + "risk_score": 99, + "rule_id": "b7f77c3c-1bcb-4afc-9ace-49357007947b", + "setup": "## Setup\n\nThis rule requires host CPU metrics collected via the Elastic Agent **System** integration.\n\n### System Metrics Integration Setup\nThe System integration collects host-level metrics such as CPU usage, load, memory, and process statistics and sends them to Elasticsearch using Elastic Agent.\n\n#### Prerequisite Requirements:\n- Elastic Agent managed by Fleet\n- A Fleet Server configured and reachable\n Refer to the Fleet Server setup guide:\n https://www.elastic.co/guide/en/fleet/current/fleet-server.html\n\n#### The following steps should be executed in order to enable CPU metrics collection:\n- Go to the Kibana home page and click **Add integrations**.\n- In the search bar, enter **System** and select the **System** integration.\n- Click **Add System**.\n- Configure an integration name and optionally add a description.\n- Under **Metrics**, ensure the following datasets are enabled:\n - `system.cpu`\n - `system.load` (optional but recommended)\n - `system.process` (optional, if process-level CPU is required)\n- Review optional and advanced settings as needed.\n- Add the integration to an existing agent policy or create a new agent policy.\n- Deploy the Elastic Agent to the hosts from which CPU metrics should be collected.\n- Click **Save and Continue** to finalize the setup.\n\n#### Validation\nAfter deployment, verify CPU metrics ingestion by confirming the presence of documents in:\n- `metrics-system.cpu-*`\n- `metrics-system.load-*` (if enabled)\n\nFor more details on the System integration and available metrics, refer to the documentation:\nhttps://docs.elastic.co/integrations/system\n", + "severity": "critical", + "tags": [ + "Use Case: Threat Detection", + "Rule Type: Higher-Order Rule", + "Resources: Investigation Guide", + "Domain: Endpoint", + "Tactic: Impact" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0040", + "name": "Impact", + "reference": "https://attack.mitre.org/tactics/TA0040/" + }, + "technique": [] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 2 + }, + "id": "b7f77c3c-1bcb-4afc-9ace-49357007947b_2", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/be4c5aed-90f5-4221-8bd5-7ab3a4334751_8.json b/packages/security_detection_engine/kibana/security_rule/be4c5aed-90f5-4221-8bd5-7ab3a4334751_8.json new file mode 100644 index 00000000000..7f762ae0385 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/be4c5aed-90f5-4221-8bd5-7ab3a4334751_8.json @@ -0,0 +1,63 @@ +{ + "attributes": { + "anomaly_threshold": 70, + "author": [ + "Elastic" + ], + "description": "An anomaly detection job has detected a remote file transfer on an unusual directory indicating a potential lateral movement activity on the host. Many Security solutions monitor well-known directories for suspicious activities, so attackers might use less common directories to bypass monitoring.", + "from": "now-90m", + "interval": "15m", + "license": "Elastic License v2", + "machine_learning_job_id": "lmd_rare_file_path_remote_transfer", + "name": "Unusual Remote File Directory", + "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 Remote File Directory\n\nThe 'Unusual Remote File Directory' detection leverages machine learning to identify atypical file transfers in directories not commonly monitored, which may indicate lateral movement by adversaries. Attackers exploit these less scrutinized paths to evade detection, often using remote services to transfer malicious payloads. This rule flags such anomalies, aiding in early detection of potential breaches.\n\n### Possible investigation steps\n\n- Review the alert details to identify the specific unusual directory involved in the file transfer and note any associated file names or types.\n- Check the source and destination IP addresses involved in the transfer to determine if they are known or trusted entities within the network.\n- Investigate the user account associated with the file transfer to verify if the activity aligns with their typical behavior or role within the organization.\n- Examine recent logs or events from the host to identify any other suspicious activities or anomalies that may correlate with the file transfer.\n- Cross-reference the detected activity with known threat intelligence sources to determine if the file transfer or directory is associated with any known malicious campaigns or tactics.\n- Assess the potential impact of the file transfer by evaluating the sensitivity of the data involved and the criticality of the systems affected.\n\n### False positive analysis\n\n- Routine administrative tasks may trigger alerts if they involve file transfers to directories not typically monitored. Users can create exceptions for known administrative activities to prevent unnecessary alerts.\n- Automated backup processes might be flagged if they store files in uncommon directories. Identifying and excluding these backup operations can reduce false positives.\n- Software updates or patches that deploy files to less common directories could be mistaken for suspicious activity. Users should whitelist these update processes to avoid false alerts.\n- Development or testing environments often involve file transfers to non-standard directories. Users can configure exceptions for these environments to minimize false positives.\n- Legitimate remote services used for file transfers, such as cloud storage synchronization, may be flagged. Users should identify and exclude these trusted services from monitoring.\n\n### Response and remediation\n\n- Isolate the affected host immediately to prevent further lateral movement and contain the potential threat. Disconnect it from the network to stop any ongoing malicious activity.\n- Conduct a thorough analysis of the unusual directory and any files transferred to identify malicious payloads. Use endpoint detection and response (EDR) tools to scan for known malware signatures and behaviors.\n- Remove any identified malicious files and artifacts from the affected directory and host. Ensure that all traces of the threat are eradicated to prevent re-infection.\n- Reset credentials and review access permissions for the affected host and any associated accounts to mitigate the risk of unauthorized access. Ensure that least privilege principles are enforced.\n- Monitor network traffic and logs for any signs of further lateral movement or exploitation attempts. Pay special attention to remote service connections and unusual directory access.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional hosts or systems are compromised.\n- Update detection mechanisms and rules to enhance monitoring of less common directories and improve the detection of similar threats in the future.", + "references": [ + "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html", + "https://docs.elastic.co/en/integrations/lmd", + "https://www.elastic.co/blog/detecting-lateral-movement-activity-a-new-kibana-integration", + "https://www.elastic.co/blog/remote-desktop-protocol-connections-elastic-security" + ], + "related_integrations": [ + { + "package": "lmd", + "version": "^2.0.0" + }, + { + "package": "endpoint", + "version": "^8.2.0" + } + ], + "risk_score": 21, + "rule_id": "be4c5aed-90f5-4221-8bd5-7ab3a4334751", + "setup": "## Setup\n\nThis rule requires the `host.ip` field to be populated.\nFor **Elastic Defend** events on versions **8.18 and above**, this field is **disabled by default**.\n\nIf you are using **Elastic Defend**, ensure host IP collection is enabled by following the configuration steps in the\n[helper guide](https://www.elastic.co/docs/solutions/security/configure-elastic-defend/configure-data-volume-for-elastic-endpoint#host-fields).\n\nThe rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration.\n\n### Lateral Movement Detection Setup\nThe Lateral Movement Detection integration detects lateral movement activity by identifying abnormalities in file and Windows RDP events. Anomalies are detected using Elastic's Anomaly Detection feature.\n\n#### Prerequisite Requirements:\n- Fleet is required for Lateral Movement Detection.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n- File events collected by the [Elastic Defend](https://docs.elastic.co/en/integrations/endpoint) integration.\n- To install Elastic Defend, refer to the [documentation](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n\n#### The following steps should be executed to install assets associated with the Lateral Movement Detection integration:\n- Go to the Kibana homepage. Under Management, click Integrations.\n- In the query bar, search for Lateral Movement Detection and select the integration to see more details about it.\n- Follow the instructions under the **Installation** section.\n- For this rule to work, complete the instructions through **Add preconfigured anomaly detection jobs**.\n", + "severity": "low", + "tags": [ + "Use Case: Lateral Movement Detection", + "Rule Type: ML", + "Rule Type: Machine Learning", + "Tactic: Lateral Movement", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0008", + "name": "Lateral Movement", + "reference": "https://attack.mitre.org/tactics/TA0008/" + }, + "technique": [ + { + "id": "T1210", + "name": "Exploitation of Remote Services", + "reference": "https://attack.mitre.org/techniques/T1210/" + } + ] + } + ], + "type": "machine_learning", + "version": 8 + }, + "id": "be4c5aed-90f5-4221-8bd5-7ab3a4334751_8", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/c02c8b9f-5e1d-463c-a1b0-04edcdfe1a3d_109.json b/packages/security_detection_engine/kibana/security_rule/c02c8b9f-5e1d-463c-a1b0-04edcdfe1a3d_109.json deleted file mode 100644 index f2d870f2506..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/c02c8b9f-5e1d-463c-a1b0-04edcdfe1a3d_109.json +++ /dev/null @@ -1,103 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies use of the Secure Copy Protocol (SCP) to copy files locally by abusing the auto addition of the Secure Shell Daemon (sshd) to the authorized application list for Full Disk Access. This may indicate attempts to bypass macOS privacy controls to access sensitive files.", - "from": "now-9m", - "index": [ - "logs-endpoint.events.process*" - ], - "language": "eql", - "license": "Elastic License v2", - "name": "Potential Privacy Control Bypass via Localhost Secure Copy", - "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 Privacy Control Bypass via Localhost Secure Copy\n\nSecure Copy Protocol (SCP) is used for secure file transfers over SSH. On macOS, SSH daemon inclusion in the Full Disk Access list can be exploited to bypass privacy controls. Adversaries may misuse SCP to locally copy files, evading security measures. The detection rule identifies such activity by monitoring SCP commands targeting localhost, excluding benign uses like Vagrant, to flag potential privacy control bypass attempts.\n\n### Possible investigation steps\n\n- Review the process details to confirm the presence of SCP commands targeting localhost or 127.0.0.1, as indicated by the process.command_line field.\n- Check the process.args field for the presence of \"StrictHostKeyChecking=no\" to verify if the SCP command was executed with potentially insecure settings.\n- Investigate the user account associated with the SCP command to determine if it is a legitimate user or potentially compromised.\n- Examine the timing and frequency of the SCP command execution to identify any unusual patterns or repeated attempts that may indicate malicious activity.\n- Cross-reference the alert with other security logs or alerts to identify any related suspicious activities or anomalies around the same timeframe.\n- Assess the system for any unauthorized changes or access to sensitive files that may have occurred as a result of the SCP command execution.\n\n### False positive analysis\n\n- Vagrant usage can trigger false positives due to its legitimate use of SCP for local file transfers. To mitigate this, ensure that Vagrant-related SCP commands are excluded by refining the detection rule to ignore processes with arguments containing \"vagrant@*127.0.0.1*\".\n- Development and testing environments may frequently use SCP to localhost for legitimate purposes. Consider creating exceptions for known development tools or scripts that regularly perform these actions to reduce noise.\n- Automated backup solutions might use SCP to copy files locally as part of their routine operations. Identify and whitelist these processes to prevent them from being flagged as potential threats.\n- System administrators may use SCP for local file management tasks. Establish a list of trusted administrator accounts or specific command patterns that can be safely excluded from triggering alerts.\n- Continuous integration and deployment pipelines might involve SCP commands to localhost. Review and exclude these processes if they are part of a controlled and secure workflow.\n\n### Response and remediation\n\n- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or data exfiltration.\n- Terminate any suspicious SCP processes identified in the alert to halt ongoing unauthorized file transfers.\n- Conduct a thorough review of the system's Full Disk Access list to identify and remove any unauthorized applications, including the SSH daemon if it was added without proper authorization.\n- Analyze the system's SSH configuration and logs to identify any unauthorized changes or access patterns, and revert any suspicious modifications.\n- Reset credentials for any accounts that may have been compromised, focusing on those with SSH access, and enforce the use of strong, unique passwords.\n- Implement network monitoring to detect and alert on any future SCP commands targeting localhost, especially those bypassing host key checks.\n- Escalate the incident to the security operations team for further investigation and to assess the potential impact on sensitive data, ensuring compliance with organizational incident response protocols.", - "query": "process where host.os.type == \"macos\" and event.type in (\"start\", \"process_started\") and\n process.name:\"scp\" and\n process.args:\"StrictHostKeyChecking=no\" and\n process.command_line:(\"scp *localhost:/*\", \"scp *127.0.0.1:/*\") and\n not process.args:\"vagrant@*127.0.0.1*\"\n", - "references": [ - "https://www.trendmicro.com/en_us/research/20/h/xcsset-mac-malware--infects-xcode-projects--uses-0-days.html" - ], - "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.args", - "type": "keyword" - }, - { - "ecs": true, - "name": "process.command_line", - "type": "wildcard" - }, - { - "ecs": true, - "name": "process.name", - "type": "keyword" - } - ], - "risk_score": 73, - "rule_id": "c02c8b9f-5e1d-463c-a1b0-04edcdfe1a3d", - "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 macOS 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, for MacOS it is recommended to select \"Traditional Endpoints\".\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/current/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: macOS", - "Use Case: Threat Detection", - "Tactic: Privilege Escalation", - "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": "T1548", - "name": "Abuse Elevation Control Mechanism", - "reference": "https://attack.mitre.org/techniques/T1548/" - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0004", - "name": "Privilege Escalation", - "reference": "https://attack.mitre.org/tactics/TA0004/" - }, - "technique": [ - { - "id": "T1548", - "name": "Abuse Elevation Control Mechanism", - "reference": "https://attack.mitre.org/techniques/T1548/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "eql", - "version": 109 - }, - "id": "c02c8b9f-5e1d-463c-a1b0-04edcdfe1a3d_109", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/c124dc1b-cef2-4d01-8d74-ff6b0d5096b6_108.json b/packages/security_detection_engine/kibana/security_rule/c124dc1b-cef2-4d01-8d74-ff6b0d5096b6_108.json new file mode 100644 index 00000000000..ad26407232b --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/c124dc1b-cef2-4d01-8d74-ff6b0d5096b6_108.json @@ -0,0 +1,133 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects PowerShell scripts that uses Set-MpPreference with parameters that disable or weaken Defender. Attackers tamper with antivirus settings to reduce detection and enable follow-on payload execution.", + "from": "now-9m", + "index": [ + "winlogbeat-*", + "logs-windows.powershell*" + ], + "investigation_fields": { + "field_names": [ + "@timestamp", + "user.name", + "user.id", + "user.domain", + "powershell.file.script_block_text", + "powershell.file.script_block_id", + "powershell.sequence", + "powershell.total", + "file.path", + "file.directory", + "file.name", + "process.pid", + "host.name", + "host.id", + "powershell.file.script_block_length" + ] + }, + "language": "kuery", + "license": "Elastic License v2", + "name": "PowerShell Script with Windows Defender Tampering Capabilities", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This guide was created by humans with the assistance of generative AI. While its contents have been manually curated to include the most valuable information, always validate assumptions and adjust procedures to match your internal runbooks and incident triage and response policies.\n\n### Investigating PowerShell Script with Windows Defender Tampering Capabilities\n\nThis alert highlights PowerShell script block activity that attempts to change Windows Defender preferences in ways that can reduce host protections. These changes are frequently used to create a window for follow-on execution (for example, staging payloads, running tools, or maintaining access with reduced scanning and response).\n\nTriage should focus on (1) what protections were targeted and how, (2) who initiated the change and on which host(s), (3) whether the change took effect and persisted, and (4) whether there is surrounding activity that suggests initial access or follow-on malicious actions.\n\n#### Key alert fields to review\n\n- `user.name`, `user.domain`, `user.id`: Account execution context for correlation, prioritization, and scoping.\n- `host.name`, `host.id`: Host execution context for correlation, prioritization, and scoping.\n- `powershell.file.script_block_text`: Script block content that matched the detection logic.\n- `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`: Script block metadata to pivot to other fragments or reconstruct full script content when split across multiple events.\n- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file.\n- `powershell.file.script_block_length`: Script block length (size) context.\n\n#### Possible investigation steps\n\n- Review the script block content and determine the intended Defender impact:\n - Inspect `powershell.file.script_block_text` and enumerate each `Set-MpPreference` parameter present.\n - Capture whether the script is disabling protections (for example, real-time monitoring, script scanning, network file scanning) or changing default threat actions (low/moderate/high) to more permissive outcomes.\n - Note whether the script changes multiple settings in one execution, repeats the changes, or includes additional logic that suggests deliberate defense impairment rather than a single configuration adjustment.\n\n- Reconstruct full script content when it is split across multiple events:\n - If `powershell.total` is greater than 1, pivot on `powershell.file.script_block_id` and order fragments by `powershell.sequence` to rebuild the full script.\n - Ensure you capture all fragments for the same `powershell.file.script_block_id` on the same `host.id` and `user.id` near the alert time; missing fragments can hide follow-on behavior embedded in later chunks.\n\n- Establish scope across hosts and accounts:\n - Use `@timestamp`, `host.name` / `host.id`, and `user.name` / `user.domain` / `user.id` to determine whether the activity is isolated or distributed.\n - Look for the same user context making similar changes across multiple hosts in a short time window (suggesting automation or compromised credentials).\n - Look for multiple distinct user contexts making similar changes on the same host (suggesting lateral movement or multiple access paths).\n\n- Determine the execution and origin context:\n - If `file.path` or `file.name` is populated, treat the activity as file-backed scripting and capture the location for scoping (where else this script exists, who can write to it, and when it was last introduced).\n - If the file fields are not populated, treat the activity as potentially interactive or dynamically generated content and expand the search for adjacent script blocks from the same `user.id` on the same `host.id` around `@timestamp` to identify staging, execution flow, or repeated attempts.\n\n- Validate whether Defender settings were actually changed and whether the change persisted:\n - Using available endpoint security telemetry and configuration auditing, validate whether the targeted preferences were applied on the affected host(s) and whether they remained in the weakened state after the alert time.\n - Compare against your approved baseline for Defender settings and identify deviations that would materially reduce protection coverage.\n\n- Correlate with adjacent activity to identify initial access and follow-on execution:\n - Correlate by `host.id` and time to nearby process activity to identify the PowerShell host process and its launching context (interactive use vs scheduled/automated execution vs another process initiating PowerShell).\n - Review file and network telemetry around the same time for indicators of payload staging or execution (new files written, unusual outbound connections, or repeated attempts after the change).\n - Check for repeated Defender preference modifications over time on the same host (suggesting persistent tampering) and for other suspicious activity tied to the same `user.id`.\n\n### False positive analysis\n\nLegitimate activity can modify Defender preferences, but it should be explainable, consistent, and controlled.\n\n- Common benign drivers:\n - Approved endpoint management or administrative maintenance that adjusts scanning behavior for performance or operational compatibility.\n - Controlled troubleshooting where settings are temporarily changed and later restored.\n\n- Validation questions to reduce uncertainty:\n - Does `user.id` map to an expected administrative or management identity for this host population?\n - Is the activity aligned with known maintenance windows, change records, and documented procedures?\n - Is `file.path` (when present) consistent with a known, maintained script location, and does the script content align with an approved baseline?\n\nIf the activity is benign, document the owner, expected scope (hosts/users), expected recurrence, and the intended steady-state protection posture.\n\n### Response and remediation\n\nIf the activity is unauthorized or suspicious, treat it as a defense evasion attempt with potential follow-on actions.\n\n- Contain and preserve evidence:\n - Prioritize affected endpoints identified by `host.id` / `host.name` and preserve relevant evidence, including the full reconstructed script from `powershell.file.script_block_id` and `powershell.file.script_block_text`.\n - Capture the initiating identity context (`user.name`, `user.domain`, `user.id`) for incident scoping and credential review.\n\n- Restore protections and eliminate the change source:\n - Restore Windows Defender preferences to the approved baseline using authorized operational processes and verify protections are active.\n - If `file.path` is present, identify the responsible script and remove or disable unauthorized automation that applies the changes.\n - If the activity appears user-driven or interactive, investigate how the user obtained execution capability on the host and address the root cause.\n\n- Address potential account compromise and lateral movement:\n - Review recent activity associated with the initiating account and affected hosts for signs of credential misuse, unexpected access patterns, or follow-on execution.\n - Apply appropriate credential remediation for impacted identities and review privileged access assignments relevant to the affected endpoints.\n\n- Scope and monitor:\n - Hunt for the same Defender-tampering parameters within `powershell.file.script_block_text` across other hosts and users to identify additional impacted systems.\n - Continue monitoring for recurrence of similar preference changes tied to the same `user.id`, as repeated tampering may indicate persistence or an active intrusion.\n", + "query": "event.category: \"process\" and host.os.type:windows and\n(\n powershell.file.script_block_text: \"Set-MpPreference\" and\n powershell.file.script_block_text: (\n DisableArchiveScanning or DisableBehaviorMonitoring or\n DisableIntrusionPreventionSystem or DisableIOAVProtection or\n DisableRemovableDriveScanning or DisableBlockAtFirstSeen or\n DisableScanningMappedNetworkDrivesForFullScan or\n DisableScanningNetworkFiles or DisableScriptScanning or\n DisableRealtimeMonitoring or LowThreatDefaultAction or\n ModerateThreatDefaultAction or HighThreatDefaultAction\n )\n) and\nnot powershell.file.script_block_text : (\n (\"cmdletization\" and \"cdxml-Help.xml\") or\n (\"function Set-MpPreference\" and \"Microsoft.PowerShell.Cmdletization.GeneratedTypes.MpPreference.SubmitSamplesConsentType\")\n) and\nnot file.directory : \"C:\\ProgramData\\Microsoft\\Windows Defender Advanced Threat Protection\\SenseCM\" and\nnot user.id : \"S-1-5-18\"\n", + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.category", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.directory", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_text", + "type": "unknown" + }, + { + "ecs": true, + "name": "user.id", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "c124dc1b-cef2-4d01-8d74-ff6b0d5096b6", + "setup": "## Setup\n\nPowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104).\nSetup instructions: https://ela.st/powershell-logging-setup\n", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: PowerShell Logs", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1562", + "name": "Impair Defenses", + "reference": "https://attack.mitre.org/techniques/T1562/", + "subtechnique": [ + { + "id": "T1562.001", + "name": "Disable or Modify Tools", + "reference": "https://attack.mitre.org/techniques/T1562/001/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "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": "query", + "version": 108 + }, + "id": "c124dc1b-cef2-4d01-8d74-ff6b0d5096b6_108", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/c7908cac-337a-4f38-b50d-5eeb78bdb531_206.json b/packages/security_detection_engine/kibana/security_rule/c7908cac-337a-4f38-b50d-5eeb78bdb531_206.json deleted file mode 100644 index b6baf81e4b2..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/c7908cac-337a-4f38-b50d-5eeb78bdb531_206.json +++ /dev/null @@ -1,108 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "This rule detects when a user creates a pod/container running in privileged mode. A highly privileged container has access to the node's resources and breaks the isolation between containers. If compromised, an attacker can use the privileged container to gain access to the underlying host. Gaining access to the host may provide the adversary with the opportunity to achieve follow-on objectives, such as establishing persistence, moving laterally within the environment, or setting up a command and control channel on the host.", - "false_positives": [ - "By default a container is not allowed to access any devices on the host, but a \"privileged\" container is given access to all devices on the host. This allows the container nearly all the same access as processes running on the host. An administrator may want to run a privileged container to use operating system administrative capabilities such as manipulating the network stack or accessing hardware devices from within the cluster. Add exceptions for trusted container images using the query field \"kubernetes.audit.requestObject.spec.container.image\"" - ], - "index": [ - "logs-kubernetes.*" - ], - "language": "kuery", - "license": "Elastic License v2", - "name": "Kubernetes Privileged Pod 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 Kubernetes Privileged Pod Created\n\nKubernetes allows for the creation of privileged pods, which can access the host's resources, breaking container isolation. Adversaries may exploit this to escalate privileges, access sensitive data, or establish persistence. The detection rule identifies such events by monitoring audit logs for pod creation with privileged settings, excluding known safe images, to flag potential security threats.\n\n### Possible investigation steps\n\n- Review the Kubernetes audit logs to identify the user or service account responsible for creating the privileged pod by examining the `kubernetes.audit.annotations.authorization_k8s_io/decision` and `kubernetes.audit.verb:create` fields.\n- Investigate the context of the privileged pod creation by checking the `kubernetes.audit.requestObject.spec.containers.image` field to determine if the image used is known or potentially malicious.\n- Assess the necessity and legitimacy of the privileged pod by consulting with the relevant development or operations teams to understand if there was a valid reason for its creation.\n- Examine the `kubernetes.audit.objectRef.resource:pods` field to identify the specific pod and its associated namespace, and verify if it aligns with expected deployment patterns or environments.\n- Check for any subsequent suspicious activities or anomalies in the Kubernetes environment that may indicate further exploitation attempts, such as lateral movement or data exfiltration, following the creation of the privileged pod.\n\n### False positive analysis\n\n- Known safe images like \"docker.elastic.co/beats/elastic-agent:8.4.0\" are already excluded from triggering alerts. Ensure that any additional internal or third-party images that are verified as safe are added to the exclusion list to prevent unnecessary alerts.\n- Development and testing environments often use privileged pods for legitimate purposes. Consider creating separate rules or exceptions for these environments to avoid false positives while maintaining security in production.\n- Automated deployment tools or scripts might create privileged pods as part of their normal operation. Review these tools and, if they are deemed safe, add their specific actions or images to the exclusion list.\n- Regularly review and update the exclusion list to reflect changes in your environment, such as new safe images or changes in deployment practices, to maintain an accurate detection rule.\n\n### Response and remediation\n\n- Immediately isolate the affected node to prevent further exploitation and lateral movement within the cluster. This can be done by cordoning and draining the node to stop new pods from being scheduled and to safely evict existing pods.\n- Terminate the privileged pod to stop any ongoing malicious activity. Ensure that the termination is logged for further analysis.\n- Conduct a thorough review of the audit logs to identify any unauthorized access or actions taken by the privileged pod. Focus on any attempts to access sensitive data or escalate privileges.\n- Reset credentials and access tokens that may have been exposed or compromised due to the privileged pod's access to the host's resources.\n- Patch and update the Kubernetes environment and any affected nodes to address vulnerabilities that may have been exploited to create the privileged pod.\n- Implement network segmentation and firewall rules to limit the communication capabilities of pods, especially those with elevated privileges, to reduce the risk of lateral movement.\n- Escalate the incident to the security operations team for a comprehensive investigation and to assess the need for further security measures or incident response actions.", - "query": "event.dataset : \"kubernetes.audit_logs\"\n and kubernetes.audit.annotations.authorization_k8s_io/decision:\"allow\"\n and kubernetes.audit.objectRef.resource:pods\n and kubernetes.audit.verb:create\n and kubernetes.audit.requestObject.spec.containers.securityContext.privileged:true\n and not kubernetes.audit.requestObject.spec.containers.image: (\"docker.elastic.co/beats/elastic-agent:8.4.0\")\n", - "references": [ - "https://media.defense.gov/2021/Aug/03/2002820425/-1/-1/1/CTR_KUBERNETES%20HARDENING%20GUIDANCE.PDF", - "https://kubernetes.io/docs/tasks/configure-pod-container/security-context/" - ], - "related_integrations": [ - { - "package": "kubernetes", - "version": "^1.80.0" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "event.dataset", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.annotations.authorization_k8s_io/decision", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.objectRef.resource", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.requestObject.spec.containers.image", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.requestObject.spec.containers.securityContext.privileged", - "type": "boolean" - }, - { - "ecs": false, - "name": "kubernetes.audit.verb", - "type": "keyword" - } - ], - "risk_score": 47, - "rule_id": "c7908cac-337a-4f38-b50d-5eeb78bdb531", - "setup": "The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule.", - "severity": "medium", - "tags": [ - "Data Source: Kubernetes", - "Tactic: Execution", - "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": "T1611", - "name": "Escape to Host", - "reference": "https://attack.mitre.org/techniques/T1611/" - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0002", - "name": "Execution", - "reference": "https://attack.mitre.org/tactics/TA0002/" - }, - "technique": [ - { - "id": "T1610", - "name": "Deploy Container", - "reference": "https://attack.mitre.org/techniques/T1610/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "query", - "version": 206 - }, - "id": "c7908cac-337a-4f38-b50d-5eeb78bdb531_206", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/ca98c7cf-a56e-4057-a4e8-39603f7f0389_11.json b/packages/security_detection_engine/kibana/security_rule/ca98c7cf-a56e-4057-a4e8-39603f7f0389_11.json deleted file mode 100644 index 4591d967a8e..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/ca98c7cf-a56e-4057-a4e8-39603f7f0389_11.json +++ /dev/null @@ -1,126 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies a Windows trusted program running from locations often abused by adversaries to masquerade as a trusted program and loading a recently dropped DLL. This behavior may indicate an attempt to evade defenses via side-loading a malicious DLL within the memory space of a signed processes.", - "from": "now-9m", - "index": [ - "logs-endpoint.events.library-*" - ], - "language": "eql", - "license": "Elastic License v2", - "name": "Unsigned DLL Side-Loading from a Suspicious Folder", - "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 Unsigned DLL Side-Loading from a Suspicious Folder\n\nDLL side-loading exploits the trust of signed executables to load malicious DLLs, often from suspicious directories. Adversaries use this to bypass security measures by placing unsigned DLLs in locations mimicking legitimate paths. The detection rule identifies this by checking for trusted programs loading recently modified, unsigned DLLs from atypical directories, signaling potential evasion tactics.\n\n### Possible investigation steps\n\n- Review the process code signature to confirm the legitimacy of the trusted program that loaded the DLL. Check if the process is expected to run from the identified directory.\n- Examine the DLL's path and creation or modification time to determine if it aligns with typical user or system activity. Investigate why the DLL was recently modified or created.\n- Analyze the DLL's code signature status to understand why it is unsigned or has an error status. This can help identify if the DLL is potentially malicious.\n- Investigate the parent process and any associated child processes to understand the context of the DLL loading event. This can provide insights into how the DLL was introduced.\n- Check for any recent changes or anomalies in the system or user activity logs around the time the DLL was created or modified to identify potential indicators of compromise.\n- Correlate the alert with other security events or alerts in the environment to determine if this is part of a broader attack or isolated incident.\n\n### False positive analysis\n\n- Legitimate software updates or installations may temporarily load unsigned DLLs from atypical directories. Users can create exceptions for known update processes by verifying the source and ensuring the process is part of a legitimate update.\n- Custom or in-house applications might load unsigned DLLs from non-standard directories. Users should verify the application's behavior and, if deemed safe, exclude these specific paths or processes from the rule.\n- Development environments often involve testing unsigned DLLs in various directories. Developers can exclude these environments by specifying the directories or processes involved in the development workflow.\n- Some third-party security or system management tools may use unsigned DLLs for legitimate purposes. Users should confirm the tool's legitimacy and add exceptions for these tools to prevent false positives.\n\n### Response and remediation\n\n- Isolate the affected system from the network to prevent further spread of the potential threat and to contain any malicious activity.\n- Terminate the process associated with the unsigned DLL to stop any ongoing malicious operations.\n- Quarantine the suspicious DLL file and any related files for further analysis to understand the scope and nature of the threat.\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 malicious files or remnants.\n- Review and restore any altered system configurations or settings to their original state to ensure system integrity.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat has impacted other systems.\n- Implement additional monitoring and logging on the affected system and network to detect any recurrence or similar threats in the future.", - "query": "library where host.os.type == \"windows\" and\n\n process.code_signature.trusted == true and\n\n (dll.Ext.relative_file_creation_time <= 500 or dll.Ext.relative_file_name_modify_time <= 500) and\n\n not dll.code_signature.status : (\"trusted\", \"errorExpired\", \"errorCode_endpoint*\", \"errorChaining\") and\n\n /* Suspicious Paths */\n dll.path : (\"?:\\\\PerfLogs\\\\*.dll\",\n \"?:\\\\Users\\\\*\\\\Pictures\\\\*.dll\",\n \"?:\\\\Users\\\\*\\\\Music\\\\*.dll\",\n \"?:\\\\Users\\\\Public\\\\*.dll\",\n \"?:\\\\Users\\\\*\\\\Documents\\\\*.dll\",\n \"?:\\\\Windows\\\\Tasks\\\\*.dll\",\n \"?:\\\\Windows\\\\System32\\\\Tasks\\\\*.dll\",\n \"?:\\\\Intel\\\\*.dll\",\n \"?:\\\\AMD\\\\Temp\\\\*.dll\",\n \"?:\\\\Windows\\\\AppReadiness\\\\*.dll\",\n \"?:\\\\Windows\\\\ServiceState\\\\*.dll\",\n \"?:\\\\Windows\\\\security\\\\*.dll\",\n\t\t \"?:\\\\Windows\\\\System\\\\*.dll\",\n \"?:\\\\Windows\\\\IdentityCRL\\\\*.dll\",\n \"?:\\\\Windows\\\\Branding\\\\*.dll\",\n \"?:\\\\Windows\\\\csc\\\\*.dll\",\n \"?:\\\\Windows\\\\DigitalLocker\\\\*.dll\",\n \"?:\\\\Windows\\\\en-US\\\\*.dll\",\n \"?:\\\\Windows\\\\wlansvc\\\\*.dll\",\n \"?:\\\\Windows\\\\Prefetch\\\\*.dll\",\n \"?:\\\\Windows\\\\Fonts\\\\*.dll\",\n \"?:\\\\Windows\\\\diagnostics\\\\*.dll\",\n \"?:\\\\Windows\\\\TAPI\\\\*.dll\",\n \"?:\\\\Windows\\\\INF\\\\*.dll\",\n \"?:\\\\windows\\\\tracing\\\\*.dll\",\n \"?:\\\\windows\\\\IME\\\\*.dll\",\n \"?:\\\\Windows\\\\Performance\\\\*.dll\",\n \"?:\\\\windows\\\\intel\\\\*.dll\",\n \"?:\\\\windows\\\\ms\\\\*.dll\",\n \"?:\\\\Windows\\\\dot3svc\\\\*.dll\",\n \"?:\\\\Windows\\\\ServiceProfiles\\\\*.dll\",\n \"?:\\\\Windows\\\\panther\\\\*.dll\",\n \"?:\\\\Windows\\\\RemotePackages\\\\*.dll\",\n \"?:\\\\Windows\\\\OCR\\\\*.dll\",\n \"?:\\\\Windows\\\\appcompat\\\\*.dll\",\n \"?:\\\\Windows\\\\apppatch\\\\*.dll\",\n \"?:\\\\Windows\\\\addins\\\\*.dll\",\n \"?:\\\\Windows\\\\Setup\\\\*.dll\",\n \"?:\\\\Windows\\\\Help\\\\*.dll\",\n \"?:\\\\Windows\\\\SKB\\\\*.dll\",\n \"?:\\\\Windows\\\\Vss\\\\*.dll\",\n \"?:\\\\Windows\\\\Web\\\\*.dll\",\n \"?:\\\\Windows\\\\servicing\\\\*.dll\",\n \"?:\\\\Windows\\\\CbsTemp\\\\*.dll\",\n \"?:\\\\Windows\\\\Logs\\\\*.dll\",\n \"?:\\\\Windows\\\\WaaS\\\\*.dll\",\n \"?:\\\\Windows\\\\twain_32\\\\*.dll\",\n \"?:\\\\Windows\\\\ShellExperiences\\\\*.dll\",\n \"?:\\\\Windows\\\\ShellComponents\\\\*.dll\",\n \"?:\\\\Windows\\\\PLA\\\\*.dll\",\n \"?:\\\\Windows\\\\Migration\\\\*.dll\",\n \"?:\\\\Windows\\\\debug\\\\*.dll\",\n \"?:\\\\Windows\\\\Cursors\\\\*.dll\",\n \"?:\\\\Windows\\\\Containers\\\\*.dll\",\n \"?:\\\\Windows\\\\Boot\\\\*.dll\",\n \"?:\\\\Windows\\\\bcastdvr\\\\*.dll\",\n \"?:\\\\Windows\\\\TextInput\\\\*.dll\",\n \"?:\\\\Windows\\\\schemas\\\\*.dll\",\n \"?:\\\\Windows\\\\SchCache\\\\*.dll\",\n \"?:\\\\Windows\\\\Resources\\\\*.dll\",\n \"?:\\\\Windows\\\\rescache\\\\*.dll\",\n \"?:\\\\Windows\\\\Provisioning\\\\*.dll\",\n \"?:\\\\Windows\\\\PrintDialog\\\\*.dll\",\n \"?:\\\\Windows\\\\PolicyDefinitions\\\\*.dll\",\n \"?:\\\\Windows\\\\media\\\\*.dll\",\n \"?:\\\\Windows\\\\Globalization\\\\*.dll\",\n \"?:\\\\Windows\\\\L2Schemas\\\\*.dll\",\n \"?:\\\\Windows\\\\LiveKernelReports\\\\*.dll\",\n \"?:\\\\Windows\\\\ModemLogs\\\\*.dll\",\n \"?:\\\\Windows\\\\ImmersiveControlPanel\\\\*.dll\",\n \"?:\\\\$Recycle.Bin\\\\*.dll\") and\n\n\t /* DLL loaded from the process.executable current directory */\n\t endswith~(substring(dll.path, 0, length(dll.path) - (length(dll.name) + 1)), substring(process.executable, 0, length(process.executable) - (length(process.name) + 1)))\n", - "references": [ - "https://www.elastic.co/security-labs/Hunting-for-Suspicious-Windows-Libraries-for-Execution-and-Evasion" - ], - "related_integrations": [ - { - "package": "endpoint", - "version": "^9.0.0" - } - ], - "required_fields": [ - { - "ecs": false, - "name": "dll.Ext.relative_file_creation_time", - "type": "unknown" - }, - { - "ecs": false, - "name": "dll.Ext.relative_file_name_modify_time", - "type": "unknown" - }, - { - "ecs": true, - "name": "dll.code_signature.status", - "type": "keyword" - }, - { - "ecs": true, - "name": "dll.name", - "type": "keyword" - }, - { - "ecs": true, - "name": "dll.path", - "type": "keyword" - }, - { - "ecs": true, - "name": "host.os.type", - "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" - } - ], - "risk_score": 47, - "rule_id": "ca98c7cf-a56e-4057-a4e8-39603f7f0389", - "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: Windows", - "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": "T1036", - "name": "Masquerading", - "reference": "https://attack.mitre.org/techniques/T1036/", - "subtechnique": [ - { - "id": "T1036.001", - "name": "Invalid Code Signature", - "reference": "https://attack.mitre.org/techniques/T1036/001/" - } - ] - }, - { - "id": "T1574", - "name": "Hijack Execution Flow", - "reference": "https://attack.mitre.org/techniques/T1574/", - "subtechnique": [ - { - "id": "T1574.002", - "name": "DLL Side-Loading", - "reference": "https://attack.mitre.org/techniques/T1574/002/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "eql", - "version": 11 - }, - "id": "ca98c7cf-a56e-4057-a4e8-39603f7f0389_11", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/cde1bafa-9f01-4f43-a872-605b678968b0_220.json b/packages/security_detection_engine/kibana/security_rule/cde1bafa-9f01-4f43-a872-605b678968b0_220.json new file mode 100644 index 00000000000..70d1009d4d6 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/cde1bafa-9f01-4f43-a872-605b678968b0_220.json @@ -0,0 +1,126 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects PowerShell scripts containing function names and helpers from common offensive frameworks and tools used for discovery, credential access, injection, persistence, and exfiltration. Attackers often reuse these public functions with minimal changes, leaving recognizable function-name artifacts.", + "filters": [ + { + "meta": { + "negate": true + }, + "query": { + "wildcard": { + "file.path": { + "case_insensitive": true, + "value": "?:\\\\ProgramData\\\\Microsoft\\\\Windows Defender Advanced Threat Protection\\\\DataCollection\\\\*" + } + } + } + } + ], + "from": "now-9m", + "index": [ + "winlogbeat-*", + "logs-windows.powershell*" + ], + "investigation_fields": { + "field_names": [ + "@timestamp", + "user.name", + "user.id", + "user.domain", + "powershell.file.script_block_text", + "powershell.file.script_block_id", + "powershell.sequence", + "powershell.total", + "file.path", + "file.directory", + "file.name", + "process.pid", + "host.name", + "host.id", + "powershell.file.script_block_length" + ] + }, + "language": "kuery", + "license": "Elastic License v2", + "name": "Potential PowerShell HackTool Script by Function Names", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This guide was created by humans with the assistance of generative AI. While its contents have been manually curated to include the most valuable information, always validate assumptions and adjust procedures to match your internal runbooks and incident triage and response policies.\n\n### Investigating Potential PowerShell HackTool Script by Function Names\n\nThis rule identifies PowerShell Script Block Logging events where the captured script content includes function names commonly reused by offensive PowerShell toolkits. Script blocks can contain function definitions (tool staging) and/or function invocation (active use). Prioritize determining what capability is present, how the script was introduced, and whether follow-on activity occurred.\n\n#### Key alert fields to review\n\n- `user.name`, `user.domain`, `user.id`: Account execution context for correlation, prioritization, and scoping.\n- `host.name`, `host.id`: Host execution context for correlation, prioritization, and scoping.\n- `powershell.file.script_block_text`: Script block content that matched the detection logic.\n- `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`: Script block metadata to pivot to other fragments or reconstruct full script content when split across multiple events.\n- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file.\n- `powershell.file.script_block_length`: Script block length (size) context.\n\n#### Possible investigation steps\n\n- Review `powershell.file.script_block_text` to determine intent and urgency:\n - Identify the function name(s) present and map them to likely capability. Examples include:\n - Credential access: `Invoke-Mimikatz`, `Invoke-Kerberoast`, `Invoke-DCSync`, `Get-GPPPassword`, `Get-LSASecret`.\n - Injection or token manipulation: `Invoke-ReflectivePEInjection`, `Create-RemoteThread`, `Inject-RemoteShellcode`, `Invoke-TokenManipulation`.\n - Remote execution or lateral movement: `Invoke-PsExec`, `Invoke-SMBExec`, `Invoke-WmiCommand`, `Invoke-PSRemoting`, `Invoke-DCOM`.\n - Staging, persistence, or exfiltration: `Invoke-DownloadCradle`, `Add-Persistence`, `HTTP-Backdoor`, `Do-Exfiltration`.\n - Determine whether the script block primarily defines functions (tool staging) or calls them (active use). If only definitions are present, look for follow-on script blocks from the same host and user that invoke the functions.\n - Capture any embedded targets or indicators visible in the text (other usernames, hostnames, domains, remote paths, URLs, or IP addresses).\n\n- Reconstruct the complete script when it is split across multiple events:\n - Pivot using `host.name` (or `host.id`) and `powershell.file.script_block_id` to collect related script blocks around `@timestamp`.\n - Order fragments using `powershell.sequence` and confirm completeness using `powershell.total`.\n - Use `powershell.file.script_block_length` as a size signal to distinguish a full toolkit/module from a small launcher or single command.\n\n- Establish script origin and execution context:\n - If `file.path` / `file.name` (and `file.directory`) are present, treat the script as an on-disk artifact. Validate whether its location and naming align with approved scripts and expected administrative workflows for that host and user.\n - If file fields are not present, treat the activity as potentially interactive or in-memory. Correlate other endpoint telemetry from the same `host.id` and time window to identify how PowerShell was started and what else executed immediately before and after.\n\n- Validate the account and host context:\n - Review `user.name`, `user.domain`, and `user.id` for privilege level and whether the activity aligns with expected responsibilities and working hours.\n - Review `host.name` and `host.id` to understand the system role and whether advanced PowerShell activity is expected on that host.\n\n- Scope for additional related activity on the same host:\n - Search for other script blocks on the same `host.id` and `user.id` near the alert time to identify staging, follow-on commands, or cleanup actions.\n - Pivot on `powershell.file.script_block_id` to ensure all fragments are reviewed and to detect repeated execution of the same script content.\n\n- Scope for related activity across the environment:\n - Search for additional script blocks containing the same distinctive function name(s) or matching snippets of `powershell.file.script_block_text` to identify reuse and potential spread.\n - If `file.path` or `file.name` is present, check for the same script artifact referenced on other hosts.\n\n- Correlate with adjacent telemetry (as available) to confirm impact and intent:\n - Process telemetry to identify the initiating process (parent of PowerShell) and any suspicious child processes spawned after the script executed.\n - Authentication telemetry to identify anomalous logons or access patterns involving the same user around the execution window.\n - Network and DNS telemetry to identify outbound connections, internal scanning, or remote management activity aligned with `@timestamp`.\n - Persistence telemetry to identify new or modified services, scheduled tasks, autoruns, or registry changes that align with the observed script capability.\n\n### False positive analysis\n\n- Internal security or IT teams may run proof-of-concept or validation scripts for training, detection testing, or incident response. Confirm script ownership, change control, and expected distribution.\n\n### Response and remediation\n\n- If the activity is unauthorized or suspicious:\n - Contain the affected host to prevent additional execution and lateral movement.\n - Preserve evidence by saving all related script block events (reconstruct full content using `powershell.file.script_block_id`, `powershell.sequence`, and `powershell.total`) and collecting any referenced on-disk script identified by `file.path`.\n - Prioritize impact assessment based on the functions observed (credential access, injection, remote execution, persistence, or exfiltration) and look for corroborating activity in adjacent telemetry.\n - Scope for additional impacted systems and accounts by searching for the same function names or script snippets across other hosts and users.\n - Remove identified artifacts and persistence mechanisms, and monitor for re-execution using the same function-name patterns.\n\n- If the activity is confirmed benign:\n - Document the justification (owner, purpose, expected hosts/users, and time window) and retain the reconstructed script content for future baselining.\n - Where feasible, limit high-risk PowerShell tooling to controlled administrative hosts and approved accounts to reduce recurrence.\n", + "query": "event.category:process and host.os.type:windows and\n powershell.file.script_block_text : (\n \"Add-DomainGroupMember\" or \"Add-DomainObjectAcl\" or\n \"Add-RemoteConnection\" or \"Add-ServiceDacl\" or\n \"Add-Win32Type\" or \"Convert-ADName\" or\n \"Convert-LDAPProperty\" or \"ConvertFrom-LDAPLogonHours\" or\n \"ConvertFrom-UACValue\" or \"Copy-ArrayOfMemAddresses\" or\n \"Create-NamedPipe\" or \"Create-ProcessWithToken\" or\n \"Create-RemoteThread\" or \"Create-SuspendedWinLogon\" or\n \"Create-WinLogonProcess\" or \"Emit-CallThreadStub\" or\n \"Enable-SeAssignPrimaryTokenPrivilege\" or \"Enable-SeDebugPrivilege\" or\n \"Enum-AllTokens\" or \"Export-PowerViewCSV\" or\n \"Find-AVSignature\" or \"Find-AppLockerLog\" or\n \"Find-DomainLocalGroupMember\" or \"Find-DomainObjectPropertyOutlier\" or\n \"Find-DomainProcess\" or \"Find-DomainShare\" or\n \"Find-DomainUserEvent\" or \"Find-DomainUserLocation\" or\n \"Find-InterestingDomainAcl\" or \"Find-InterestingDomainShareFile\" or\n \"Find-InterestingFile\" or \"Find-LocalAdminAccess\" or\n \"Find-PSScriptsInPSAppLog\" or \"Find-PathDLLHijack\" or\n \"Find-ProcessDLLHijack\" or \"Find-RDPClientConnection\" or\n \"Get-AllAttributesForClass\" or \"Get-CachedGPPPassword\" or\n \"Get-DecryptedCpassword\" or \"Get-DecryptedSitelistPassword\" or\n \"Get-DelegateType\" or \"New-RelayEnumObject\" or\n \"Get-DomainDFSShare\" or \"Get-DomainDFSShareV1\" or\n \"Get-DomainDFSShareV2\" or \"Get-DomainDNSRecord\" or\n \"Get-DomainDNSZone\" or \"Get-DomainFileServer\" or\n \"Get-DomainForeignGroupMember\" or \"Get-DomainForeignUser\" or\n \"Get-DomainGPO\" or \"Get-DomainGPOComputerLocalGroupMapping\" or\n \"Get-DomainGPOLocalGroup\" or \"Get-DomainGPOUserLocalGroupMapping\" or\n \"Get-DomainGUIDMap\" or \"Get-DomainGroup\" or\n \"Get-DomainGroupMember\" or \"Get-DomainGroupMemberDeleted\" or\n \"Get-DomainManagedSecurityGroup\" or \"Get-DomainOU\" or\n \"Get-DomainObject\" or \"Get-DomainObjectAcl\" or\n \"Get-DomainObjectAttributeHistory\" or \"Get-DomainObjectLinkedAttributeHistory\" or\n \"Get-DomainPolicyData\" or \"Get-DomainSID\" or\n \"Get-DomainSPNTicket\" or \"Get-DomainSearcher\" or\n \"Get-DomainSite\" or \"Get-DomainSubnet\" or\n \"Get-DomainTrust\" or \"Get-DomainTrustMapping\" or\n \"Get-DomainUser\" or \"Get-DomainUserEvent\" or\n \"Get-Forest\" or \"Get-ForestDomain\" or\n \"Get-ForestGlobalCatalog\" or \"Get-ForestSchemaClass\" or\n \"Get-ForestTrust\" or \"Get-GPODelegation\" or\n \"Get-GPPAutologon\" or \"Get-GPPInnerField\" or\n \"Get-GPPInnerFields\" or \"Get-GPPPassword\" or\n \"Get-GptTmpl\" or \"Get-GroupsXML\" or\n \"Get-HttpStatus\" or \"Get-ImageNtHeaders\" or\n \"Get-Keystrokes\" or \"New-SOASerialNumberArray\" or\n \"Get-MemoryProcAddress\" or \"Get-MicrophoneAudio\" or\n \"Get-ModifiablePath\" or \"Get-ModifiableRegistryAutoRun\" or\n \"Get-ModifiableScheduledTaskFile\" or \"Get-ModifiableService\" or\n \"Get-ModifiableServiceFile\" or \"Get-Name\" or\n \"Get-NetComputerSiteName\" or \"Get-NetLocalGroup\" or\n \"Get-NetLocalGroupMember\" or \"Get-NetLoggedon\" or\n \"Get-NetRDPSession\" or \"Get-NetSession\" or\n \"Get-NetShare\" or \"Get-PEArchitecture\" or\n \"Get-PEBasicInfo\" or \"Get-PEDetailedInfo\" or\n \"Get-PathAcl\" or \"Get-PrimaryToken\" or\n \"Get-ProcAddress\" or \"Get-ProcessTokenGroup\" or\n \"Get-ProcessTokenPrivilege\" or \"Get-ProcessTokenType\" or\n \"Get-RegLoggedOn\" or \"Get-RegistryAlwaysInstallElevated\" or\n \"Get-RegistryAutoLogon\" or \"Get-RemoteProcAddress\" or\n \"Get-Screenshot\" or \"Get-ServiceDetail\" or\n \"Get-SiteListPassword\" or \"Get-SitelistField\" or\n \"Get-System\" or \"Get-SystemNamedPipe\" or\n \"Get-SystemToken\" or \"Get-ThreadToken\" or\n \"Get-TimedScreenshot\" or \"Get-TokenInformation\" or\n \"Get-TopPort\" or \"Get-UnattendedInstallFile\" or\n \"Get-UniqueTokens\" or \"Get-UnquotedService\" or\n \"Get-VaultCredential\" or \"Get-VaultElementValue\" or\n \"Get-VirtualProtectValue\" or \"Get-VolumeShadowCopy\" or\n \"Get-WMIProcess\" or \"Get-WMIRegCachedRDPConnection\" or\n \"Get-WMIRegLastLoggedOn\" or \"Get-WMIRegMountedDrive\" or\n \"Get-WMIRegProxy\" or \"Get-WebConfig\" or\n \"Get-Win32Constants\" or \"Get-Win32Functions\" or\n \"Get-Win32Types\" or \"Import-DllImports\" or\n \"Import-DllInRemoteProcess\" or \"Inject-LocalShellcode\" or\n \"Inject-RemoteShellcode\" or \"Install-ServiceBinary\" or\n \"Invoke-CompareAttributesForClass\" or \"Invoke-CreateRemoteThread\" or\n \"Invoke-CredentialInjection\" or \"Invoke-DllInjection\" or\n \"Invoke-EventVwrBypass\" or \"Invoke-ImpersonateUser\" or\n \"Invoke-Kerberoast\" or \"Invoke-MemoryFreeLibrary\" or\n \"Invoke-MemoryLoadLibrary\" or\n \"Invoke-Mimikatz\" or \"Invoke-NinjaCopy\" or\n \"Invoke-PatchDll\" or \"Invoke-Portscan\" or\n \"Invoke-PrivescAudit\" or \"Invoke-ReflectivePEInjection\" or\n \"Invoke-ReverseDnsLookup\" or \"Invoke-RevertToSelf\" or\n \"Invoke-ServiceAbuse\" or \"Invoke-Shellcode\" or\n \"Invoke-TokenManipulation\" or \"Invoke-UserImpersonation\" or\n \"Invoke-WmiCommand\" or \"Mount-VolumeShadowCopy\" or\n \"New-ADObjectAccessControlEntry\" or \"New-DomainGroup\" or\n \"New-DomainUser\" or \"New-DynamicParameter\" or\n \"New-InMemoryModule\" or\n \"New-ThreadedFunction\" or \"New-VolumeShadowCopy\" or\n \"Out-CompressedDll\" or \"Out-EncodedCommand\" or\n \"Out-EncryptedScript\" or \"Out-Minidump\" or\n \"PortScan-Alive\" or \"Portscan-Port\" or\n \"Remove-DomainGroupMember\" or \"Remove-DomainObjectAcl\" or\n \"Remove-RemoteConnection\" or \"Remove-VolumeShadowCopy\" or\n \"Restore-ServiceBinary\" or \"Set-DesktopACLToAllowEveryone\" or\n \"Set-DesktopACLs\" or \"Set-DomainObject\" or\n \"Set-DomainObjectOwner\" or \"Set-DomainUserPassword\" or\n \"Set-ServiceBinaryPath\" or \"Sub-SignedIntAsUnsigned\" or\n \"Test-AdminAccess\" or \"Test-MemoryRangeValid\" or\n \"Test-ServiceDaclPermission\" or \"Update-ExeFunctions\" or\n \"Update-MemoryAddresses\" or \"Update-MemoryProtectionFlags\" or\n \"Write-BytesToMemory\" or \"Write-HijackDll\" or\n \"Write-PortscanOut\" or \"Write-ServiceBinary\" or\n \"Write-UserAddMSI\" or \"Invoke-Privesc\" or\n \"func_get_proc_address\" or \"Invoke-BloodHound\" or\n \"Invoke-HostEnum\" or \"Get-BrowserInformation\" or\n \"Get-DomainAccountPolicy\" or \"Get-DomainAdmins\" or\n \"Get-AVProcesses\" or \"Get-AVInfo\" or\n \"Get-RecycleBin\" or \"Invoke-BruteForce\" or\n \"Get-PassHints\" or \"Invoke-SessionGopher\" or\n \"Get-LSASecret\" or \"Get-PassHashes\" or\n \"Invoke-WdigestDowngrade\" or \"Get-ChromeDump\" or\n \"Invoke-DomainPasswordSpray\" or \"Get-FoxDump\" or\n \"New-HoneyHash\" or \"Invoke-DCSync\" or\n \"Invoke-PowerDump\" or \"Invoke-SSIDExfil\" or\n \"Invoke-PowerShellTCP\" or \"Add-Exfiltration\" or\n \"Do-Exfiltration\" or \"Invoke-DropboxUpload\" or\n \"Invoke-ExfilDataToGitHub\" or \"Invoke-EgressCheck\" or\n \"Invoke-PostExfil\" or \"Create-MultipleSessions\" or\n \"Invoke-NetworkRelay\" or \"New-GPOImmediateTask\" or\n \"Invoke-WMIDebugger\" or \"Invoke-SQLOSCMD\" or\n \"Invoke-SMBExec\" or \"Invoke-PSRemoting\" or\n \"Invoke-ExecuteMSBuild\" or \"Invoke-DCOM\" or\n \"Invoke-InveighRelay\" or \"Invoke-PsExec\" or\n \"Find-ActiveUsersWMI\" or\n \"Get-SystemDrivesWMI\" or \"Get-ActiveNICSWMI\" or\n \"Remove-Persistence\" or \"DNS_TXT_Pwnage\" or\n \"Execute-OnTime\" or \"HTTP-Backdoor\" or\n \"Add-ConstrainedDelegationBackdoor\" or \"Add-RegBackdoor\" or\n \"Add-ScrnSaveBackdoor\" or \"Gupt-Backdoor\" or\n \"Invoke-ADSBackdoor\" or \"Add-Persistence\" or\n \"Invoke-ResolverBackdoor\" or \"Invoke-EventLogBackdoor\" or\n \"Invoke-DeadUserBackdoor\" or \"Invoke-DisableMachineAcctChange\" or\n \"Invoke-AccessBinary\" or \"Add-NetUser\" or\n \"Invoke-Schtasks\" or \"Invoke-JSRatRegsvr\" or\n \"Invoke-JSRatRundll\" or \"Invoke-PoshRatHttps\" or\n \"Invoke-PsGcatAgent\" or \"Remove-PoshRat\" or\n \"Install-SSP\" or \"Invoke-BackdoorLNK\" or\n \"PowerBreach\" or \"InstallEXE-Persistence\" or\n \"RemoveEXE-Persistence\" or \"Install-ServiceLevel-Persistence\" or\n \"Remove-ServiceLevel-Persistence\" or \"Invoke-Prompt\" or\n \"Invoke-PacketCapture\" or \"Start-WebcamRecorder\" or\n \"Get-USBKeyStrokes\" or \"Invoke-KeeThief\" or\n \"Get-Keystrokes\" or \"Invoke-NetRipper\" or\n \"Get-EmailItems\" or \"Invoke-MailSearch\" or\n \"Invoke-SearchGAL\" or \"Get-WebCredentials\" or\n \"Start-CaptureServer\" or \"Invoke-PowerShellIcmp\" or\n \"Invoke-PowerShellTcpOneLine\" or \"Invoke-PowerShellTcpOneLineBind\" or\n \"Invoke-PowerShellUdp\" or \"Invoke-PowerShellUdpOneLine\" or\n \"Run-EXEonRemote\" or \"Download-Execute-PS\" or\n \"Out-RundllCommand\" or \"Set-RemoteWMI\" or\n \"Set-DCShadowPermissions\" or \"Invoke-PowerShellWMI\" or\n \"Invoke-Vnc\" or \"Invoke-LockWorkStation\" or\n \"Invoke-EternalBlue\" or \"Invoke-ShellcodeMSIL\" or\n \"Invoke-MetasploitPayload\" or \"Invoke-DowngradeAccount\" or\n \"Invoke-RunAs\" or \"ExetoText\" or\n \"Disable-SecuritySettings\" or \"Set-MacAttribute\" or\n \"Invoke-MS16032\" or \"Invoke-BypassUACTokenManipulation\" or\n \"Invoke-SDCLTBypass\" or \"Invoke-FodHelperBypass\" or\n \"Invoke-EventVwrBypass\" or \"Invoke-EnvBypass\" or\n \"Get-ServiceUnquoted\" or \"Get-ServiceFilePermission\" or\n \"Get-ServicePermission\" or\n \"Enable-DuplicateToken\" or \"Invoke-PsUaCme\" or\n \"Invoke-Tater\" or \"Invoke-WScriptBypassUAC\" or\n \"Invoke-AllChecks\" or \"Find-TrustedDocuments\" or\n \"Invoke-Interceptor\" or \"Invoke-PoshRatHttp\" or\n \"Invoke-ExecCommandWMI\" or \"Invoke-KillProcessWMI\" or\n \"Invoke-CreateShareandExecute\" or \"Invoke-RemoteScriptWithOutput\" or\n \"Invoke-SchedJobManipulation\" or \"Invoke-ServiceManipulation\" or\n \"Invoke-PowerOptionsWMI\" or \"Invoke-DirectoryListing\" or\n \"Invoke-FileTransferOverWMI\" or \"Invoke-WMImplant\" or\n \"Invoke-WMIObfuscatedPSCommand\" or \"Invoke-WMIDuplicateClass\" or\n \"Invoke-WMIUpload\" or \"Invoke-WMIRemoteExtract\" or \"Invoke-winPEAS\" or\n \"Invoke-AzureHound\" or \"Invoke-SharpHound\" or \"Invoke-DownloadCradle\" or\n \"Invoke-AppPathBypass\"\n ) and\n not powershell.file.script_block_text : (\n \"sentinelbreakpoints\" and \"Set-PSBreakpoint\"\n ) and\n not user.id : (\"S-1-5-18\" or \"S-1-5-19\")\n", + "references": [ + "https://github.com/atc-project/atc-data/blob/master/docs/Logging_Policies/LP_0109_windows_powershell_script_block_log.md", + "https://github.com/BC-SECURITY/Empire", + "https://www.microsoft.com/en-us/security/blog/2025/05/27/new-russia-affiliated-actor-void-blizzard-targets-critical-sectors-for-espionage/" + ], + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.category", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_text", + "type": "unknown" + }, + { + "ecs": true, + "name": "user.id", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "cde1bafa-9f01-4f43-a872-605b678968b0", + "setup": "## Setup\n\nPowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104).\nSetup instructions: https://ela.st/powershell-logging-setup\n", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Execution", + "Data Source: PowerShell Logs", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.001", + "name": "PowerShell", + "reference": "https://attack.mitre.org/techniques/T1059/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 220 + }, + "id": "cde1bafa-9f01-4f43-a872-605b678968b0_220", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/cf575427-0839-4c69-a9e6-99fde02606f3_3.json b/packages/security_detection_engine/kibana/security_rule/cf575427-0839-4c69-a9e6-99fde02606f3_3.json new file mode 100644 index 00000000000..8392d051d36 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/cf575427-0839-4c69-a9e6-99fde02606f3_3.json @@ -0,0 +1,66 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "building_block_type": "default", + "description": "This rule leverages alert data from various Discovery building block rules to alert on signals with unusual unique host.id and user.id entries.", + "from": "now-9m", + "history_window_start": "now-7d", + "index": [ + ".alerts-security.*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "Deprecated - Unusual Discovery Activity by User", + "new_terms_fields": [ + "host.id", + "user.id" + ], + "query": "host.os.type:windows and event.kind:signal and kibana.alert.rule.rule_id:(\n \"d68e95ad-1c82-4074-a12a-125fe10ac8ba\" or \"7b8bfc26-81d2-435e-965c-d722ee397ef1\" or\n \"0635c542-1b96-4335-9b47-126582d2c19a\" or \"6ea55c81-e2ba-42f2-a134-bccf857ba922\" or\n \"e0881d20-54ac-457f-8733-fe0bc5d44c55\" or \"06568a02-af29-4f20-929c-f3af281e41aa\" or\n \"c4e9ed3e-55a2-4309-a012-bc3c78dad10a\" or \"51176ed2-2d90-49f2-9f3d-17196428b169\" or\n \"1d72d014-e2ab-4707-b056-9b96abe7b511\"\n)\n", + "required_fields": [ + { + "ecs": true, + "name": "event.kind", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": false, + "name": "kibana.alert.rule.rule_id", + "type": "unknown" + } + ], + "risk_score": 21, + "rule_id": "cf575427-0839-4c69-a9e6-99fde02606f3", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Discovery", + "Rule Type: Higher-Order Rule", + "Rule Type: BBR" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0007", + "name": "Discovery", + "reference": "https://attack.mitre.org/tactics/TA0007/" + }, + "technique": [] + } + ], + "timestamp_override": "event.ingested", + "type": "new_terms", + "version": 3 + }, + "id": "cf575427-0839-4c69-a9e6-99fde02606f3_3", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/d43f2b43-02a1-4219-8ce9-10929a32a618_4.json b/packages/security_detection_engine/kibana/security_rule/d43f2b43-02a1-4219-8ce9-10929a32a618_4.json deleted file mode 100644 index 715cc6b7d63..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/d43f2b43-02a1-4219-8ce9-10929a32a618_4.json +++ /dev/null @@ -1,153 +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", - "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Potential PowerShell Obfuscation via Backtick-Escaped Variable Expansion\n\nPowerShell, a powerful scripting language in Windows environments, can be exploited by adversaries using obfuscation techniques like backtick-escaped variable expansion to evade detection. This method involves disguising malicious scripts to bypass security measures. The detection rule identifies scripts with excessive length and specific obfuscation patterns, flagging potential threats for further analysis.\n\n### Possible investigation steps\n\n- Review the `powershell.file.script_block_text` field to understand the content of the script and identify any suspicious or malicious commands.\n- Examine the `file.path` and `file.name` fields to determine the origin and context of the script execution, which may provide insights into whether the script is part of a legitimate process or potentially malicious activity.\n- Check the `host.name` and `agent.id` fields to identify the affected system and correlate with other security events or logs from the same host for additional context.\n- Analyze the `user.id` field to determine which user account executed the script, and assess whether this activity aligns with the user's typical behavior or role.\n- Investigate the `powershell.file.script_block_id` and `powershell.sequence` fields to trace the execution flow of the script and identify any related script blocks that may have been executed in sequence.\n- Consider the `count` field to evaluate the extent of obfuscation used in the script, which may indicate the level of sophistication or intent behind the script.\n\n### False positive analysis\n\n- Scripts with legitimate administrative functions may use backtick-escaped variable expansion for complex string manipulations. Review the script's context and purpose to determine if it aligns with expected administrative tasks.\n- Automated scripts generated by trusted software might include obfuscation patterns as part of their normal operation. Verify the source and integrity of the software to ensure it is from a reputable vendor.\n- Developers and IT professionals may use obfuscation techniques during testing or development phases. Establish a process to whitelist known development environments or user accounts to reduce unnecessary alerts.\n- PowerShell scripts that are part of legitimate security tools or monitoring solutions may trigger the rule. Identify and exclude these tools by their file path or script block ID to prevent false positives.\n- Regularly update the list of known false positives based on historical data and feedback from users to refine the detection rule and improve its accuracy.\n\n### Response and remediation\n\n- Isolate the affected host immediately to prevent further spread of the potentially malicious script across the network.\n- Terminate any suspicious PowerShell processes identified by the alert to halt the execution of obfuscated scripts.\n- Conduct a thorough review of the script block text and associated file paths to identify and remove any malicious scripts or files from the system.\n- Reset credentials for any user accounts involved in the alert to mitigate the risk of compromised credentials being used for further attacks.\n- Escalate the incident to the security operations team for a deeper investigation into potential lateral movement or additional compromised systems.\n- Implement enhanced monitoring on the affected host and similar systems to detect any recurrence of obfuscation techniques or related suspicious activities.\n- Update endpoint protection and intrusion detection systems with indicators of compromise (IOCs) derived from the analysis to improve detection capabilities for similar threats in the future.\n", - "query": "from logs-windows.powershell_operational* metadata _id, _version, _index\n| where event.code == \"4104\"\n\n// Filter out smaller scripts that are unlikely to implement obfuscation using the patterns we are looking for\n| eval Esql.script_block_length = length(powershell.file.script_block_text)\n| where Esql.script_block_length > 500\n\n// replace the patterns we are looking for with the \ud83d\udd25 emoji to enable counting them\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| eval Esql.script_block_tmp = replace(powershell.file.script_block_text, \"\"\"\\$\\{(\\w++`){2,}\\w++\\}\"\"\", \"\ud83d\udd25\")\n\n// count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| eval Esql.script_block_pattern_count = length(Esql.script_block_tmp) - length(replace(Esql.script_block_tmp, \"\ud83d\udd25\", \"\"))\n\n// keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| keep\n Esql.script_block_pattern_count,\n Esql.script_block_length,\n Esql.script_block_tmp,\n powershell.file.script_block_text,\n powershell.file.script_block_id,\n file.path,\n file.name,\n powershell.sequence,\n powershell.total,\n _id,\n _index,\n host.name,\n agent.id,\n user.id\n\n// Filter for scripts that match the pattern at least once\n| where Esql.script_block_pattern_count >= 1\n", - "related_integrations": [ - { - "package": "windows", - "version": "^3.0.0" - } - ], - "required_fields": [ - { - "ecs": false, - "name": "Esql.script_block_length", - "type": "integer" - }, - { - "ecs": false, - "name": "Esql.script_block_pattern_count", - "type": "integer" - }, - { - "ecs": false, - "name": "Esql.script_block_tmp", - "type": "keyword" - }, - { - "ecs": false, - "name": "_id", - "type": "keyword" - }, - { - "ecs": false, - "name": "_index", - "type": "keyword" - }, - { - "ecs": true, - "name": "agent.id", - "type": "keyword" - }, - { - "ecs": true, - "name": "file.name", - "type": "keyword" - }, - { - "ecs": true, - "name": "file.path", - "type": "keyword" - }, - { - "ecs": true, - "name": "host.name", - "type": "keyword" - }, - { - "ecs": false, - "name": "powershell.file.script_block_id", - "type": "keyword" - }, - { - "ecs": false, - "name": "powershell.file.script_block_text", - "type": "text" - }, - { - "ecs": false, - "name": "powershell.sequence", - "type": "long" - }, - { - "ecs": false, - "name": "powershell.total", - "type": "long" - }, - { - "ecs": true, - "name": "user.id", - "type": "keyword" - } - ], - "risk_score": 21, - "rule_id": "d43f2b43-02a1-4219-8ce9-10929a32a618", - "setup": "## Setup\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nAdministrative Templates >\nWindows PowerShell >\nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n", - "severity": "low", - "tags": [ - "Domain: Endpoint", - "OS: Windows", - "Use Case: Threat Detection", - "Tactic: Defense Evasion", - "Data Source: PowerShell Logs", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0005", - "name": "Defense Evasion", - "reference": "https://attack.mitre.org/tactics/TA0005/" - }, - "technique": [ - { - "id": "T1027", - "name": "Obfuscated Files or Information", - "reference": "https://attack.mitre.org/techniques/T1027/" - }, - { - "id": "T1140", - "name": "Deobfuscate/Decode Files or Information", - "reference": "https://attack.mitre.org/techniques/T1140/" - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0002", - "name": "Execution", - "reference": "https://attack.mitre.org/tactics/TA0002/" - }, - "technique": [ - { - "id": "T1059", - "name": "Command and Scripting Interpreter", - "reference": "https://attack.mitre.org/techniques/T1059/", - "subtechnique": [ - { - "id": "T1059.001", - "name": "PowerShell", - "reference": "https://attack.mitre.org/techniques/T1059/001/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 4 - }, - "id": "d43f2b43-02a1-4219-8ce9-10929a32a618_4", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/d43f2b43-02a1-4219-8ce9-10929a32a618_8.json b/packages/security_detection_engine/kibana/security_rule/d43f2b43-02a1-4219-8ce9-10929a32a618_8.json new file mode 100644 index 00000000000..357b271f709 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/d43f2b43-02a1-4219-8ce9-10929a32a618_8.json @@ -0,0 +1,212 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects PowerShell scripts that uses backtick-escaped characters inside `${}` variable expansion (multiple backticks between word characters) to reconstruct strings at runtime. Attackers use variable-expansion obfuscation to split keywords, hide commands, and evade static analysis and AMSI.", + "from": "now-9m", + "investigation_fields": { + "field_names": [ + "@timestamp", + "user.name", + "user.id", + "user.domain", + "powershell.file.script_block_text", + "powershell.file.script_block_id", + "powershell.sequence", + "powershell.total", + "file.path", + "file.directory", + "file.name", + "process.pid", + "host.name", + "host.id", + "powershell.file.script_block_length" + ] + }, + "language": "esql", + "license": "Elastic License v2", + "name": "Potential PowerShell Obfuscation via Backtick-Escaped Variable Expansion", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This guide was created by humans with the assistance of generative AI. While its contents have been manually curated to include the most valuable information, always validate assumptions and adjust procedures to match your internal runbooks and incident triage and response policies.\n\n### Investigating Potential PowerShell Obfuscation via Backtick-Escaped Variable Expansion\n\nThis rule identifies Windows PowerShell Script Block Logging events where backtick-escaped characters are embedded within `${}` variable expansion. This technique can be used to split tokens and reconstruct variable names or keywords at runtime, reducing the effectiveness of simple string-based detections and content scanning.\n\nFocus analysis on (1) who executed the script, (2) where it executed, (3) how much of the script is obfuscated, and (4) what the script ultimately does after deobfuscation. Higher `Esql.script_block_pattern_count`, elevated `powershell.file.script_block_entropy_bits`, and unexpected script origin (for example, unusual `file.path`) increase the likelihood of malicious intent.\n\n#### Key alert fields to review\n\n- `user.name`, `user.domain`, `user.id`: Account execution context for correlation, prioritization, and scoping.\n- `host.name`, `host.id`: Host execution context for correlation, prioritization, and scoping.\n- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file.\n- `powershell.file.script_block_text`: Script block content that matched the detection logic.\n- `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`: Script block metadata to pivot to other fragments or reconstruct full script content when split across multiple events.\n- `Esql.script_block_tmp`: Transformed script block where detection patterns replace original content with a marker to support scoring/counting and quickly spot match locations.\n- `Esql.script_block_pattern_count`: Count of matches for the detection pattern(s) observed in the script block content.\n- `powershell.file.script_block_entropy_bits`: Shannon entropy of the script block. Higher values may indicate obfuscation.\n- `powershell.file.script_block_surprisal_stdev`: Standard deviation of surprisal across the script block. Low values indicate uniform randomness. High values indicate mixed patterns and variability.\n- `powershell.file.script_block_unique_symbols`: Count of distinct characters present in the script block.\n- `powershell.file.script_block_length`: Script block length (size) context.\n\n#### Possible investigation steps\n\n- Validate execution scope and context:\n - Review `host.name` / `host.id` to understand where the script ran and whether the endpoint role makes this activity unexpected.\n - Review `user.name`, `user.domain`, and `user.id` to determine whether the account is expected to run PowerShell on this host and to identify any unusual account usage patterns in your environment.\n - If `file.path` / `file.name` / `file.directory` are present, determine whether the script appears to originate from an expected location (for example, a managed scripts directory) versus an unusual or user-writable location.\n\n- Reconstruct the complete script before interpreting intent:\n - Pivot on `powershell.file.script_block_id` and collect all related fragments.\n - Use `powershell.sequence` and `powershell.total` to verify you have the full set of fragments and to order them correctly.\n - Review the reconstructed `powershell.file.script_block_text` for staging behavior (for example, an initial deobfuscation routine followed by a second stage that performs the primary action).\n\n- Locate the obfuscated variable expansions and normalize the content:\n - Use `Esql.script_block_tmp` to quickly identify the positions of suspicious `${}` expansions, then review the corresponding sections in `powershell.file.script_block_text`.\n - Use `Esql.script_block_pattern_count` to estimate how pervasive the obfuscation is. A higher count is more consistent with deliberate evasion than isolated escaping.\n - In the matched `${}` segments, assess what the obfuscated expansion is intended to represent by mentally removing backtick escapes and looking for recognizable tokens (cmdlet/function names, variable names, or string literals) that the script is trying to hide.\n\n- Assess behavior indicated by the script content:\n - Identify whether the script uses dynamic invocation patterns, such as building an invocation target at runtime or executing reconstructed strings.\n - Look for decoding and deobfuscation constructs (string concatenation, character-by-character reconstruction, data transformation, decompression) that may reveal embedded or second-stage content.\n - Extract and document any clear indicators contained in the script text (remote endpoints, file paths, registry paths, service/task names, or additional scripts referenced). Use these indicators to scope impact across hosts.\n\n- Use alert-side obfuscation metrics to prioritize and focus review:\n - Compare `powershell.file.script_block_entropy_bits`, `powershell.file.script_block_unique_symbols`, and `powershell.file.script_block_surprisal_stdev` against what is typical in your environment for administrative scripts.\n - Treat scripts with high entropy and many unique symbols as higher risk, especially when combined with multiple obfuscated `${}` expansions.\n\n- Scope prevalence and recurrence:\n - Search for other Script Block Logging events on the same `host.id` and `user.id` that include similar backtick-escaped `${}` patterns.\n - Look for repeated occurrences of the same `file.name` / `file.path` across multiple hosts, which may indicate a shared script or distributed execution.\n - If the script contains unique strings or indicators, use them to identify additional affected endpoints.\n\n### False positive analysis\n\n- Legitimate scripts that implement complex string building or variable-name handling and happen to use backticks within `${}` expansion (more common in developer tooling, templating, or edge-case input handling).\n- Auto-generated PowerShell produced by administrative automation that uses nonstandard escaping or runtime string construction.\n\nWhen evaluating potential false positives, weigh consistency (same `user.id`, `host.id`, and `file.path` over time) against indicators of compromise (unexpected user/host pairing, high obfuscation density, high entropy, or evidence of follow-on actions).\n\n### Response and remediation\n\n- If the activity is suspicious or confirmed malicious:\n - Contain the affected endpoint to prevent additional execution and limit potential lateral movement.\n - Preserve evidence from the alert, including the full reconstructed `powershell.file.script_block_text`, `powershell.file.script_block_id`, `powershell.sequence` / `powershell.total`, and any `file.path` / `file.name` values.\n - If an on-disk source is indicated by `file.path`, collect the referenced script and related files for review and remove or quarantine malicious artifacts according to your procedures.\n - Investigate for follow-on effects suggested by the script content (persistence, payload delivery, configuration changes) and remediate any identified artifacts.\n - Review the impacted `user.id` for compromise, revoke active sessions as appropriate, and reset credentials based on your incident response policy.\n - Use extracted indicators and distinctive script fragments to hunt for additional affected hosts and users.\n\n- If the activity is verified benign:\n - Document the legitimate script source, expected `file.path` / `file.name`, and the normal execution context (`user.id`, `host.id`) to speed up future triage.\n - Monitor for deviations in execution context or significant changes in obfuscation metrics (for example, increased `Esql.script_block_pattern_count` or higher entropy) that could indicate abuse of an otherwise legitimate script.\n", + "query": "from logs-windows.powershell_operational* metadata _id, _version, _index\n| where event.code == \"4104\"\n\n// Filter out smaller scripts that are unlikely to implement obfuscation using the patterns we are looking for\n| eval Esql.script_block_length = length(powershell.file.script_block_text)\n| where Esql.script_block_length > 500\n\n// replace the patterns we are looking for with the \ud83d\udd25 emoji to enable counting them\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| eval Esql.script_block_tmp = replace(powershell.file.script_block_text, \"\"\"\\$\\{(\\w++`){2,}\\w++\\}\"\"\", \"\ud83d\udd25\")\n\n// count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| eval Esql.script_block_pattern_count = length(Esql.script_block_tmp) - length(replace(Esql.script_block_tmp, \"\ud83d\udd25\", \"\"))\n\n// keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| keep\n Esql.script_block_pattern_count,\n Esql.script_block_length,\n Esql.script_block_tmp,\n powershell.file.*,\n file.path,\n file.name,\n powershell.sequence,\n powershell.total,\n _id,\n _version,\n _index,\n host.name,\n host.id,\n agent.id,\n user.id\n\n// Filter for scripts that match the pattern at least once\n| where Esql.script_block_pattern_count >= 1\n", + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.script_block_length", + "type": "integer" + }, + { + "ecs": false, + "name": "Esql.script_block_pattern_count", + "type": "integer" + }, + { + "ecs": false, + "name": "Esql.script_block_tmp", + "type": "keyword" + }, + { + "ecs": false, + "name": "_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "_index", + "type": "keyword" + }, + { + "ecs": false, + "name": "_version", + "type": "long" + }, + { + "ecs": true, + "name": "agent.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.path", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.name", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_entropy_bits", + "type": "double" + }, + { + "ecs": false, + "name": "powershell.file.script_block_entropy_normalized", + "type": "double" + }, + { + "ecs": false, + "name": "powershell.file.script_block_hash", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_length", + "type": "long" + }, + { + "ecs": false, + "name": "powershell.file.script_block_surprisal_stdev", + "type": "double" + }, + { + "ecs": false, + "name": "powershell.file.script_block_text", + "type": "text" + }, + { + "ecs": false, + "name": "powershell.file.script_block_unique_symbols", + "type": "long" + }, + { + "ecs": false, + "name": "powershell.sequence", + "type": "long" + }, + { + "ecs": false, + "name": "powershell.total", + "type": "long" + }, + { + "ecs": true, + "name": "user.id", + "type": "keyword" + } + ], + "risk_score": 73, + "rule_id": "d43f2b43-02a1-4219-8ce9-10929a32a618", + "setup": "## Setup\n\nPowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104).\nSetup instructions: https://ela.st/powershell-logging-setup\n", + "severity": "high", + "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": 8 + }, + "id": "d43f2b43-02a1-4219-8ce9-10929a32a618_8", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/d54b649d-46d0-4b4c-a9a7-1bc9fc458d3c_1.json b/packages/security_detection_engine/kibana/security_rule/d54b649d-46d0-4b4c-a9a7-1bc9fc458d3c_1.json new file mode 100644 index 00000000000..d4fce01c567 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/d54b649d-46d0-4b4c-a9a7-1bc9fc458d3c_1.json @@ -0,0 +1,126 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects the loading of a kernel module from an unusual location. Threat actors may use this technique to maintain persistence on a system by loading a kernel module into the kernel namespace. This behavior is strongly related to the presence of a rootkit on the system.", + "from": "now-9m", + "index": [ + "logs-endpoint.events.process*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Kernel Module Load from Unusual Location", + "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 Kernel Module Load from Unusual Location\n\nThis rule detects attempts to load Linux kernel modules from atypical directories, which can indicate an attacker trying to run code in kernel space for stealth and long-term persistence. Adversaries often drop a malicious `.ko` into writable paths like `/tmp` or `/dev/shm` after initial access, then use `insmod` or `modprobe` to insert it and hide processes, files, or network activity as a rootkit.\n\n### Possible investigation steps\n\n- Capture the full command line and resolve any referenced `.ko` path, then collect the module file for hashing and static analysis to determine provenance and known-malware matches. \n- Confirm whether the module is currently loaded by querying `lsmod`/`/proc/modules`, then map it to its on-disk location with `modinfo -n ` (or `/sys/module//sections/*`) to validate it was loaded from the suspicious directory. \n- Review recent kernel and audit telemetry (`dmesg`, `/var/log/kern.log`, `journalctl -k`, and any audit records) around the event time for insertion messages, signature/taint indicators, and any follow-on errors suggesting tampering. \n- Identify the initiating user/session and execution chain (parent process tree, TTY/SSH source, container context), then determine whether the action aligns with legitimate admin activity or coincides with other compromise signals on the host. \n- Hunt for persistence and repeatability by checking for recurring module-load attempts and inspecting boot-time and scheduled execution paths (systemd units, init scripts, cron, rc.local) that could reload the module after reboot.\n\n### False positive analysis\n\n- A system administrator or automated maintenance workflow may build or test an out-of-tree kernel module and load it with `insmod`/`modprobe` from a staging directory such as `/tmp`, `/root`, or `/mnt` before installing it into standard module paths. \n- A legitimate bootstrapping or recovery operation may load a required driver module from nonstandard media or temporary runtime locations (e.g., `/boot`, `/run`, `/var/run`, or `/mnt`) during troubleshooting, initramfs/early-boot tasks, or mounting encrypted/storage devices.\n\n### Response and remediation\n\n- Isolate the affected Linux host from the network and disable external access (e.g., revoke SSH keys or block inbound SSH) to prevent additional module loads or lateral movement while preserving evidence. \n- If the suspicious module is currently loaded, record `lsmod` and `modinfo` output, then unload it where safe (`modprobe -r `/`rmmod `) and quarantine the corresponding `.ko` from the unusual path (e.g., `/tmp`, `/dev/shm`, `/home`, `/mnt`) for hashing and malware analysis. \n- Remove persistence mechanisms that would reload the module by deleting or disabling any related systemd units, init scripts, cron entries, and boot-time hooks, and validate `/etc/modules-load.d/`, `/lib/modules/$(uname -r)/`, and `depmod` outputs for unauthorized additions. \n- Recover the host by restoring known-good kernel/module packages and rebuilding the initramfs, then reboot and verify no unexpected modules remain in `/proc/modules` and no new load attempts occur from writable directories. \n- Escalate immediately to IR/forensics and consider full host rebuild if the module is unsigned/unknown, the kernel is tainted, module removal fails, or post-reboot evidence indicates stealth behavior consistent with a rootkit. \n- Harden by restricting module loading (enable Secure Boot/module signature enforcement where supported, set `kernel.modules_disabled=1` after boot on fixed-function systems, and limit `CAP_SYS_MODULE` to trusted admins), and enforce file integrity monitoring/permissions to prevent `.ko` creation in world-writable locations.", + "query": "process where host.os.type == \"linux\" and event.type == \"start\" and event.action == \"exec\" and (\n (process.name == \"kmod\" and process.args == \"insmod\" and process.args like~ \"*.ko*\") or\n (process.name == \"kmod\" and process.args == \"modprobe\" and not process.args in (\"-r\", \"--remove\")) or\n (process.name == \"insmod\" and process.args like~ \"*.ko*\") or\n (process.name == \"modprobe\" and not process.args in (\"-r\", \"--remove\"))\n) and (\n process.working_directory like (\n \"/tmp/*\", \"/var/tmp/*\", \"/dev/shm/*\", \"/run/*\", \"/var/run/*\", \"/home/*/*\", \"/root/*\",\n \"/var/www/*\", \"/boot/*\", \"/srv/*\", \"/mnt/*\"\n ) or\n process.parent.working_directory like (\n \"/tmp/*\", \"/var/tmp/*\", \"/dev/shm/*\", \"/run/*\", \"/var/run/*\", \"/home/*/*\", \"/root/*\",\n \"/var/www/*\", \"/boot/*\", \"/srv/*\", \"/mnt/*\"\n ) or\n process.args like (\n \"/tmp/*\", \"/var/tmp/*\", \"/dev/shm/*\", \"/run/*\", \"/var/run/*\", \"/home/*/*\", \"/root/*\",\n \"/var/www/*\", \"/boot/*\", \"/srv/*\", \"/mnt/*\", \"./*\"\n )\n) and\nnot (\n process.parent.executable == \"/usr/bin/podman\" or\n process.working_directory like \"/tmp/newroot\"\n)\n", + "references": [ + "https://decoded.avast.io/davidalvarez/linux-threat-hunting-syslogk-a-kernel-rootkit-found-under-development-in-the-wild/" + ], + "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" + }, + { + "ecs": true, + "name": "process.parent.executable", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.working_directory", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.working_directory", + "type": "keyword" + } + ], + "risk_score": 73, + "rule_id": "d54b649d-46d0-4b4c-a9a7-1bc9fc458d3c", + "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", + "Tactic: Persistence", + "Tactic: Defense Evasion", + "Threat: Rootkit", + "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": "T1547", + "name": "Boot or Logon Autostart Execution", + "reference": "https://attack.mitre.org/techniques/T1547/", + "subtechnique": [ + { + "id": "T1547.006", + "name": "Kernel Modules and Extensions", + "reference": "https://attack.mitre.org/techniques/T1547/006/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1014", + "name": "Rootkit", + "reference": "https://attack.mitre.org/techniques/T1014/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 1 + }, + "id": "d54b649d-46d0-4b4c-a9a7-1bc9fc458d3c_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/d591d7af-399b-4888-b705-ae612690c48d_2.json b/packages/security_detection_engine/kibana/security_rule/d591d7af-399b-4888-b705-ae612690c48d_2.json new file mode 100644 index 00000000000..a6ec12a0587 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/d591d7af-399b-4888-b705-ae612690c48d_2.json @@ -0,0 +1,96 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects Suricata high severity alerts that are observed for the first time in the previous 5 days of alert history. Analysts can use this to prioritize triage and response.", + "from": "now-7205m", + "interval": "5m", + "language": "esql", + "license": "Elastic License v2", + "name": "Newly Observed High Severity Suricata Alert", + "note": "## Triage and analysis\n\n### Investigating Newly Observed High Severity Suricata Alert\n\nThis rule surfaces newly observed, low-frequency high severity suricata alerts within the last 5 days.\n\nBecause the alert has not been seen previously for this rule and host, it should be prioritized for validation to determine\nwhether it represents a true compromise or rare benign activity.\n\n### Investigation Steps\n\n- Identify the source address, affected host and review the associated rule name to understand the behavior that triggered the alert.\n- Validate the source address under which the activity occurred and assess whether it aligns with normal behavior.\n- Refer to the specific alert details like event.original to get more context.\n\n### False Positive Considerations\n\n- Vulnerability scanners and pentesting.\n- Administrative scripts or automation tools can trigger detections when first introduced.\n- Development or testing environments may produce one-off behaviors that resemble malicious techniques.\n\n### Response and Remediation\n\n- If the activity is confirmed malicious, isolate the affected host to prevent further execution or lateral movement.\n- Terminate malicious processes and remove any dropped files or persistence mechanisms.\n- Collect forensic artifacts to understand initial access and execution flow.\n- Patch or remediate any vulnerabilities or misconfigurations that enabled the behavior.\n- If benign, document the finding and consider tuning or exception handling to reduce future noise.\n- Continue monitoring the host and environment for recurrence of the behavior or related alerts.", + "query": "FROM logs-suricata.*\n\n // high severity alerts\n| where event.module == \"suricata\" and event.kind == \"signal\" and event.severity == 1 and\n rule.name is not null and\n not rule.name like \"SURICATA STREAM*\"\n\n| STATS Esql.alerts_count = count(*),\n Esql.first_time_seen = MIN(@timestamp),\n Esql.distinct_count_src_ip = COUNT_DISTINCT(source.ip),\n Esql.distinct_count_dst_ip = COUNT_DISTINCT(destination.ip),\n src_ip_values = VALUES(source.ip),\n dst_ip_values = VALUES(destination.ip),\n url_dom = VALUES(url.domain),\n url_path = VALUES(url.path) by rule.name, event.type\n\n| eval Esql.recent = DATE_DIFF(\"minute\", Esql.first_time_seen, now())\n // first time seen is within 10m of the rule execution time\n| where Esql.recent <= 10 and\n// exclude high volume alerts such as vuln-scanners\n Esql.alerts_count <= 5 and Esql.distinct_count_src_ip <= 2 and Esql.distinct_count_dst_ip <= 2\n\n// move dynamic fields to ECS quivalent for rule exceptions\n| eval source.ip = MV_FIRST(src_ip_values),\n destination.ip = MV_FIRST(dst_ip_values),\n url.domain = MV_FIRST(url_dom),\n url.path = MV_FIRST(url_path)\n| keep rule.name, event.type, Esql.*, source.ip, destination.ip, url.domain, url.path\n", + "references": [ + "https://www.elastic.co/docs/reference/integrations/suricata" + ], + "related_integrations": [ + { + "package": "suricata", + "version": "^2.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.alerts_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.distinct_count_dst_ip", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.distinct_count_src_ip", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.first_time_seen", + "type": "date" + }, + { + "ecs": false, + "name": "Esql.recent", + "type": "integer" + }, + { + "ecs": true, + "name": "destination.ip", + "type": "ip" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "rule.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.ip", + "type": "ip" + }, + { + "ecs": true, + "name": "url.domain", + "type": "keyword" + }, + { + "ecs": true, + "name": "url.path", + "type": "wildcard" + } + ], + "risk_score": 99, + "rule_id": "d591d7af-399b-4888-b705-ae612690c48d", + "severity": "critical", + "tags": [ + "Use Case: Threat Detection", + "Rule Type: Higher-Order Rule", + "Resources: Investigation Guide", + "Domain: Network", + "Data Source: Suricata" + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 2 + }, + "id": "d591d7af-399b-4888-b705-ae612690c48d_2", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/da0ebebe-5ad3-4277-95e7-889f5a69b959_2.json b/packages/security_detection_engine/kibana/security_rule/da0ebebe-5ad3-4277-95e7-889f5a69b959_2.json new file mode 100644 index 00000000000..47ef5dbcb86 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/da0ebebe-5ad3-4277-95e7-889f5a69b959_2.json @@ -0,0 +1,110 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects the use of dmidecode to gather system information from a Linux host when executed from a parent shell process. Adversaries may use dmidecode to collect detailed hardware and system information, which can aid in further exploitation or lateral movement within a network, or be used as a fingerprint for a compromised system.", + "from": "now-9m", + "index": [ + "logs-endpoint.events.*", + "endgame-*", + "logs-sentinel_one_cloud_funnel.*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "System Information Discovery via dmidecode from Parent Shell", + "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 System Information Discovery via dmidecode from Parent Shell\n\nThis rule flags dmidecode launched from a parent shell, signaling collection of hardware and firmware inventory that adversaries use to profile a host and inform exploitation or lateral movement. A typical pattern is an intruder running bash -c 'dmidecode -t system -t bios' within a post-exploitation script to harvest model, serial, BIOS vendor, and hypervisor indicators, then tailoring payload choices or host-based evasion accordingly.\n\n### Possible investigation steps\n\n- Extract the full parent shell command payload to see exact dmidecode arguments, targeted DMI types, and any output redirection or piping to grep, gzip, curl, scp, or similar utilities indicating data collection or exfiltration.\n- Correlate execution context by tying the parent shell to the user, TTY versus non-interactive origin (cron/systemd/SSH), source IP, and presence of unexpected sudo/root elevation to judge intent and privilege.\n- Pivot on the parent PID and session to list adjacent commands within the timeline to identify broader discovery or staging chains and any script or binary loader used.\n- Search for captured output by reviewing recent file writes under /tmp, /var/tmp, /dev/shm, and home directories for DMI dumps, hardware inventory files, or compressed archives, and triage ownership and timestamps.\n- Investigate network activity from the shell and its children around the event for outbound connections, especially HTTP/S3/SSH transfers that could carry dmidecode output, and capture destination details for enrichment.\n\n### False positive analysis\n\n- A system administrator runs a shell with -c to execute dmidecode during manual troubleshooting; corroborate with an interactive TTY, a known admin user, and absence of adjacent collection or network activity.\n- A legitimate cron or systemd maintenance/provisioning job calls a shell with -c to run dmidecode for hardware inventory; verify the scheduled unit or service, script location under /etc, and expected run cadence.\n\n### Response and remediation\n\n- Immediately kill the shell process running '-c \"dmidecode ...\"', terminate its children (e.g., grep, gzip, curl, scp), and isolate the host if the command chained output to a network transfer.\n- Block observed exfil destinations by adding temporary egress rules for the IP/domain referenced in the parent shell (curl/wget/scp targets), and confiscate any DMI dumps or archives found under /tmp, /var/tmp, or /dev/shm.\n- Remove persistence by deleting scripts and jobs that call dmidecode, including entries under /etc/cron.*, systemd units in /etc/systemd/system, or shell scripts dropped in home directories and /opt, and clear residual output files.\n- Recover by validating integrity of /usr/sbin/dmidecode and shell binaries (bash/sh/zsh), restoring from backup if tampering is detected, and re-enable network only after rotating passwords and SSH keys for affected accounts.\n- Escalate to incident response if dmidecode output is compressed/encoded then sent externally (e.g., '/tmp/dmi.txt.gz' piped to curl or scp), if run via sudo by an unexpected user, or observed on multiple hosts in a short window.\n- Harden by restricting dmidecode use to approved scripts via sudoers and AppArmor/SELinux profiles, alerting on shell '-c' hardware inventory commands, auditing writes to /tmp and /var/tmp, and replacing ad-hoc inventory with signed, centrally managed tooling.\n", + "query": "process where host.os.type == \"linux\" and event.type == \"start\" and event.action in (\"exec\", \"exec_event\", \"start\") and\nprocess.name == \"dmidecode\" and process.parent.name in (\"bash\", \"dash\", \"sh\", \"tcsh\", \"csh\", \"zsh\", \"ksh\", \"fish\") and\nprocess.parent.args == \"-c\" and not (\n process.parent.command_line in (\n \"/bin/sh -c /usr/sbin/dmidecode | /bin/grep VMware\", \"sh -c dmidecode -s system-manufacturer\"\n ) or\n ?process.working_directory in (\n \"/data/oem_agent/agent_inst/sysman/emd\", \"/opt/rapid7/ir_agent/components/insight_agent/common\", \"/opt/veeam/transport\",\n \"/data/app/oracle/agent/agent_inst/sysman/emd\", \"/home/nessus\", \"/opt/commvault\", \"/opt/nessus_agent/var/nessus/mod/com.tenable.nessus_agent/data\"\n ) or\n process.parent.args like \"printf*\"\n)\n", + "references": [ + "https://research.checkpoint.com/2024/29676/" + ], + "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.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": "da0ebebe-5ad3-4277-95e7-889f5a69b959", + "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": "low", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Discovery", + "Data Source: Elastic Endgame", + "Data Source: Elastic Defend", + "Data Source: SentinelOne", + "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": "eql", + "version": 2 + }, + "id": "da0ebebe-5ad3-4277-95e7-889f5a69b959_2", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/da7f7a93-26e1-49ce-b336-963c6dc17c7b_2.json b/packages/security_detection_engine/kibana/security_rule/da7f7a93-26e1-49ce-b336-963c6dc17c7b_2.json new file mode 100644 index 00000000000..bfc0b2eaec3 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/da7f7a93-26e1-49ce-b336-963c6dc17c7b_2.json @@ -0,0 +1,74 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule uses alerts data to determine when multiple unique machine learning jobs involving the same influencer field are triggered. Analysts can use this to prioritize triage and response machine learning alerts.", + "from": "now-45m", + "interval": "30m", + "language": "esql", + "license": "Elastic License v2", + "name": "Multiple Machine Learning Alerts by Influencer Field", + "note": "## Triage and analysis\n\n### Multiple Machine Learning Alerts by Influencer Field\n\nAttackers may trigger multiple alerts by performing suspicious actions under a compromised user entity. The detection rule identifies such patterns by correlating diverse machine learning alerts linked to the same entity, excluding known system accounts, thus prioritizing potential threats for analysts.\n\n### Possible investigation steps\n\n- Review the alert details to identify the specific influencer field involved to gather initial context.\n- Examine the timeline and sequence of the triggered alerts to understand the pattern of activity associated with the influencer field, noting any unusual or unexpected actions.\n- Cross-reference the user activity with known legitimate activities or scheduled tasks to rule out false positives, ensuring that the actions are not part of normal operations.\n- Investigate the source and destination IP addresses associated with the alerts to identify any suspicious or unauthorized access points.\n- Check for any recent changes in user permissions or group memberships that could indicate privilege escalation attempts.\n- Look into any recent login attempts or authentication failures for the user account to detect potential brute force or credential stuffing attacks.\n- Collaborate with the user or their manager to verify if the activities were authorized or if the account might be compromised.\n\n### False positive analysis\n\n- Alerts triggered by automated system processes or scripts that mimic user behavior can be false positives. To manage these, identify and exclude known benign scripts or processes from the rule.\n- Frequent alerts from users in roles that inherently require access to multiple systems or sensitive data, such as IT administrators, may not indicate compromise. Implement role-based exceptions to reduce noise.\n- Alerts generated by legitimate software updates or maintenance activities can be mistaken for suspicious behavior. Schedule these activities during known maintenance windows and exclude them from the rule during these times.\n- Users involved in testing or development environments may trigger multiple alerts due to their work nature. Create exceptions for these environments to prevent unnecessary alerts.\n- High-volume users, such as those in customer support or sales, may naturally generate more alerts. Monitor these users separately and adjust the rule to focus on unusual patterns rather than volume alone.\n\n### Response and remediation\n\n- Isolate the affected user account immediately to prevent further unauthorized access. Disable the account or change the password to stop any ongoing malicious activity.\n- Conduct a thorough review of the affected user's recent activities and access logs to identify any unauthorized actions or data access. This will help in understanding the scope of the compromise.\n- Remove any malicious software or unauthorized tools that may have been installed on the user's system. Use endpoint detection and response (EDR) tools to scan and clean the system.\n- Restore any altered or deleted data from backups, ensuring that the restored data is free from any malicious modifications.\n- Notify relevant stakeholders, including IT security teams and management, about the incident and the steps being taken to address it. This ensures that everyone is aware and can provide support if needed.\n- Implement additional monitoring on the affected user account and related systems to detect any further suspicious activities. This includes setting up alerts for unusual login attempts or data access patterns.\n- Review and update access controls and permissions for the affected user and similar accounts to prevent future incidents. Ensure that least privilege principles are applied.", + "query": "from .alerts-security.*\n| where kibana.alert.rule.type == \"machine_learning\" and\n not KQL(\"\"\"kibana.alert.rule.tags : \"Rule Type: Higher-Order Rule\" \"\"\")\n| stats Esql.count_distinct_job_id = COUNT_DISTINCT(job_id),\n Esql.job_id_values = VALUES(job_id),\n Esql.rule_name_values = VALUES(kibana.alert.rule.name),\n Esql.influencer_field_values = VALUES(influencers.influencer_field_values),\n Esql.influencer_field_name = VALUES(influencers.influencer_field_name) by influencers.influencer_field_values, process.name, host.name\n| where Esql.count_distinct_job_id >= 3 and not influencers.influencer_field_values in (\"root\", \"SYSTEM\")\n| KEEP influencers.influencer_field_values, process.name, host.name, Esql.*\n", + "references": [ + "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html" + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.count_distinct_job_id", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.influencer_field_name", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.influencer_field_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.job_id_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.rule_name_values", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.name", + "type": "keyword" + }, + { + "ecs": false, + "name": "influencers.influencer_field_values", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + } + ], + "risk_score": 73, + "rule_id": "da7f7a93-26e1-49ce-b336-963c6dc17c7b", + "severity": "high", + "tags": [ + "Use Case: Threat Detection", + "Rule Type: Higher-Order Rule", + "Resources: Investigation Guide", + "Rule Type: Machine Learning" + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 2 + }, + "id": "da7f7a93-26e1-49ce-b336-963c6dc17c7b_2", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/db7dbad5-08d2-4d25-b9b1-d3a1e4a15efd_214.json b/packages/security_detection_engine/kibana/security_rule/db7dbad5-08d2-4d25-b9b1-d3a1e4a15efd_214.json new file mode 100644 index 00000000000..3a99fa137d1 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/db7dbad5-08d2-4d25-b9b1-d3a1e4a15efd_214.json @@ -0,0 +1,135 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects attempts to execute a program on the host from the Windows Subsystem for Linux. Adversaries may enable and use WSL for Linux to avoid detection.", + "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": "Execution via Windows Subsystem for Linux", + "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 Execution via Windows Subsystem for Linux\n\nWindows Subsystem for Linux (WSL) allows users to run Linux binaries natively on Windows, providing a seamless integration of Linux tools. Adversaries may exploit WSL to execute malicious scripts or binaries, bypassing traditional Windows security mechanisms. The detection rule identifies suspicious executions initiated by WSL processes, excluding known safe executables, to flag potential misuse for defense evasion.\n\n### Possible investigation steps\n\n- Review the process details to identify the executable path and determine if it matches any known malicious or suspicious binaries not listed in the safe executables.\n- Investigate the parent process, specifically wsl.exe or wslhost.exe, to understand how the execution was initiated and if it aligns with expected user behavior or scheduled tasks.\n- Check the user account associated with the process execution to verify if the activity is consistent with the user's typical behavior or if the account may have been compromised.\n- Analyze the event dataset, especially if it is from crowdstrike.fdr, to gather additional context about the process execution and any related activities on the host.\n- Correlate the alert with other security events or logs from data sources like Microsoft Defender for Endpoint or SentinelOne to identify any related suspicious activities or patterns.\n- Assess the risk score and severity in the context of the organization's environment to prioritize the investigation and response actions accordingly.\n\n### False positive analysis\n\n- Legitimate administrative tasks using WSL may trigger alerts. Users can create exceptions for known administrative scripts or binaries that are frequently executed via WSL.\n- Development environments often use WSL for compiling or testing code. Exclude specific development tools or scripts that are regularly used by developers to prevent unnecessary alerts.\n- Automated system maintenance scripts running through WSL can be mistaken for malicious activity. Identify and whitelist these scripts to reduce false positives.\n- Security tools or monitoring solutions that leverage WSL for legitimate purposes should be identified and excluded from detection to avoid interference with their operations.\n- Frequent use of WSL by specific users or groups for non-malicious purposes can be managed by creating user-based exceptions, allowing their activities to proceed without triggering alerts.\n\n### Response and remediation\n\n- Isolate the affected system from the network to prevent further malicious activity and lateral movement.\n- Terminate any suspicious processes identified as being executed via WSL that are not part of the known safe executables list.\n- Conduct a thorough review of the affected system's WSL configuration and installed Linux distributions to identify unauthorized changes or installations.\n- Remove any unauthorized or malicious scripts and binaries found within the WSL environment.\n- Restore the system from a known good backup if malicious activity has compromised system integrity.\n- Update and patch the system to ensure all software, including WSL, is up to date to mitigate known vulnerabilities.\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.", + "query": "process where host.os.type == \"windows\" and event.type : \"start\" and process.command_line != null and\n process.parent.name : (\"wsl.exe\", \"wslhost.exe\") and\n not process.executable : (\n \"?:\\\\Program Files (x86)\\\\*\",\n \"?:\\\\Program Files\\\\*\",\n \"?:\\\\Program Files*\\\\WindowsApps\\\\MicrosoftCorporationII.WindowsSubsystemForLinux_*\\\\wsl*.exe\",\n \"?:\\\\Windows\\\\System32\\\\conhost.exe\",\n \"?:\\\\Windows\\\\System32\\\\lxss\\\\wslhost.exe\",\n \"?:\\\\Windows\\\\System32\\\\WerFault.exe\",\n \"?:\\\\Windows\\\\System32\\\\wsl.exe\",\n \"?:\\\\Windows\\\\Sys?????\\\\wslconfig.exe\"\n ) and\n not (\n /* Crowdstrike specific exclusion as it uses NT Object paths */\n (event.dataset == \"crowdstrike.fdr\" or event.action == \"ProcessRollup2\") and\n process.executable : (\n \"\\\\Device\\\\HarddiskVolume*\\\\Program Files (x86)\\\\*\",\n \"\\\\Device\\\\HarddiskVolume*\\\\Program Files\\\\*\",\n \"\\\\Device\\\\HarddiskVolume*\\\\Program Files*\\\\WindowsApps\\\\MicrosoftCorporationII.WindowsSubsystemForLinux_*\\\\wsl*.exe\",\n \"\\\\Device\\\\HarddiskVolume*\\\\Windows\\\\System32\\\\conhost.exe\",\n \"\\\\Device\\\\HarddiskVolume*\\\\Windows\\\\System32\\\\lxss\\\\wslhost.exe\",\n \"\\\\Device\\\\HarddiskVolume*\\\\Windows\\\\System32\\\\WerFault.exe\",\n \"\\\\Device\\\\HarddiskVolume*\\\\Windows\\\\System32\\\\wsl.exe\",\n \"\\\\Device\\\\HarddiskVolume*\\\\Windows\\\\Sys?????\\\\wslconfig.exe\"\n )\n ) and\n not (\n (process.name : \"cmd.exe\" and process.command_line : \"*echo*%USERPROFILE%*\") or\n (process.name : \"git.exe\" and process.command_line : \"git.exe -c log.*\") or\n (process.name : \"powershell.exe\" and process.command_line : \"powershell.exe -Command $env:USERPROFILE\") or\n (process.name : \"Code.exe\" and process.command_line : (\"*cli.js --folder-uri=vscode-remote://wsl*\", \"ms-vscode-remote.remote-wsl\"))\n )\n", + "references": [ + "https://learn.microsoft.com/en-us/windows/wsl/wsl-config" + ], + "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": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.command_line", + "type": "wildcard" + }, + { + "ecs": true, + "name": "process.executable", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.name", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "db7dbad5-08d2-4d25-b9b1-d3a1e4a15efd", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: Elastic Endgame", + "Data Source: Elastic Defend", + "Data Source: Windows Security Event Logs", + "Data Source: Microsoft Defender for Endpoint", + "Data Source: SentinelOne", + "Data Source: Crowdstrike", + "Resources: Investigation Guide", + "Data Source: Sysmon" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1202", + "name": "Indirect Command Execution", + "reference": "https://attack.mitre.org/techniques/T1202/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 214 + }, + "id": "db7dbad5-08d2-4d25-b9b1-d3a1e4a15efd_214", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/df7fda76-c92b-4943-bc68-04460a5ea5ba_206.json b/packages/security_detection_engine/kibana/security_rule/df7fda76-c92b-4943-bc68-04460a5ea5ba_206.json deleted file mode 100644 index 6c65fa8ee65..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/df7fda76-c92b-4943-bc68-04460a5ea5ba_206.json +++ /dev/null @@ -1,109 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "This rule detects an attempt to create or modify a pod attached to the host PID namespace. HostPID allows a pod to access all the processes running on the host and could allow an attacker to take malicious action. When paired with ptrace this can be used to escalate privileges outside of the container. When paired with a privileged container, the pod can see all of the processes on the host. An attacker can enter the init system (PID 1) on the host. From there, they could execute a shell and continue to escalate privileges to root.", - "false_positives": [ - "An administrator or developer may want to use a pod that runs as root and shares the hosts IPC, Network, and PID namespaces for debugging purposes. If something is going wrong in the cluster and there is no easy way to SSH onto the host nodes directly, a privileged pod of this nature can be useful for viewing things like iptable rules and network namespaces from the host's perspective. Add exceptions for trusted container images using the query field \"kubernetes.audit.requestObject.spec.container.image\"" - ], - "index": [ - "logs-kubernetes.*" - ], - "language": "kuery", - "license": "Elastic License v2", - "name": "Kubernetes Pod Created With HostPID", - "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 Kubernetes Pod Created With HostPID\n\nKubernetes allows pods to share the host's process ID (PID) namespace, enabling visibility into host processes. While useful for debugging, this can be exploited by attackers to escalate privileges, especially when combined with privileged containers. The detection rule identifies attempts to create or modify pods with HostPID enabled, excluding known safe images, to flag potential privilege escalation activities.\n\n### Possible investigation steps\n\n- Review the Kubernetes audit logs to identify the user or service account responsible for the pod creation or modification attempt. Look for the `kubernetes.audit.user.username` field to determine who initiated the action.\n- Examine the `kubernetes.audit.requestObject.spec.containers.image` field to identify the container images used in the pod. Verify if any unknown or suspicious images are being deployed.\n- Check the `kubernetes.audit.annotations.authorization_k8s_io/decision` field to confirm that the action was allowed and investigate the context or reason for this decision.\n- Investigate the `kubernetes.audit.objectRef.resource` and `kubernetes.audit.verb` fields to understand the specific action taken (create, update, or patch) and the resource involved.\n- Assess the necessity and legitimacy of using HostPID in the pod's configuration by consulting with the relevant development or operations teams. Determine if there is a valid use case or if it was potentially misconfigured or maliciously set.\n- Review any recent changes in the Kubernetes environment or related configurations that might have led to this alert, focusing on changes around the time the alert was triggered.\n\n### False positive analysis\n\n- Known safe images like \"docker.elastic.co/beats/elastic-agent:8.4.0\" are already excluded, but other internal tools or monitoring agents that require HostPID for legitimate reasons might trigger false positives. Review and identify such images and add them to the exclusion list.\n- Development or testing environments often use HostPID for debugging purposes. Consider creating a separate rule or exception for these environments to prevent unnecessary alerts.\n- Some system maintenance tasks might require temporary use of HostPID. Document these tasks and schedule them during known maintenance windows, then adjust the rule to exclude these specific time frames.\n- Regularly review audit logs to identify patterns of benign HostPID usage. Use this information to refine the rule and reduce false positives by updating the exclusion criteria.\n- Collaborate with development and operations teams to understand legitimate use cases for HostPID in your environment, and adjust the rule to accommodate these scenarios without compromising security.\n\n### Response and remediation\n\n- Immediately isolate the affected pod to prevent further interaction with the host processes. This can be done by cordoning the node or deleting the pod if necessary.\n- Review and revoke any unnecessary permissions or roles that may have allowed the creation of pods with HostPID enabled. Ensure that only trusted users and service accounts have the ability to create such pods.\n- Conduct a thorough investigation of the container images used in the pod to ensure they are from trusted sources and have not been tampered with. Remove any untrusted or suspicious images from the registry.\n- Check for any unauthorized access or changes to the host system's processes and files. If any malicious activity is detected, take steps to restore affected systems from backups and patch any vulnerabilities.\n- Implement network segmentation to limit the communication between pods and the host system, reducing the risk of lateral movement by an attacker.\n- Enhance monitoring and logging to capture detailed audit logs of Kubernetes API activities, focusing on changes to pod specifications and the use of HostPID. This will aid in detecting similar threats in the future.\n- Escalate the incident to the security operations team for further analysis and to determine if additional security measures or incident response actions are required.", - "query": "event.dataset : \"kubernetes.audit_logs\"\n and kubernetes.audit.annotations.authorization_k8s_io/decision:\"allow\"\n and kubernetes.audit.objectRef.resource:\"pods\"\n and kubernetes.audit.verb:(\"create\" or \"update\" or \"patch\")\n and kubernetes.audit.requestObject.spec.hostPID:true\n and not kubernetes.audit.requestObject.spec.containers.image: (\"docker.elastic.co/beats/elastic-agent:8.4.0\")\n", - "references": [ - "https://research.nccgroup.com/2021/11/10/detection-engineering-for-kubernetes-clusters/#part3-kubernetes-detections", - "https://kubernetes.io/docs/concepts/security/pod-security-policy/#host-namespaces", - "https://bishopfox.com/blog/kubernetes-pod-privilege-escalation" - ], - "related_integrations": [ - { - "package": "kubernetes", - "version": "^1.80.0" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "event.dataset", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.annotations.authorization_k8s_io/decision", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.objectRef.resource", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.requestObject.spec.containers.image", - "type": "keyword" - }, - { - "ecs": false, - "name": "kubernetes.audit.requestObject.spec.hostPID", - "type": "boolean" - }, - { - "ecs": false, - "name": "kubernetes.audit.verb", - "type": "keyword" - } - ], - "risk_score": 47, - "rule_id": "df7fda76-c92b-4943-bc68-04460a5ea5ba", - "setup": "The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule.", - "severity": "medium", - "tags": [ - "Data Source: Kubernetes", - "Tactic: Execution", - "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": "T1611", - "name": "Escape to Host", - "reference": "https://attack.mitre.org/techniques/T1611/" - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0002", - "name": "Execution", - "reference": "https://attack.mitre.org/tactics/TA0002/" - }, - "technique": [ - { - "id": "T1610", - "name": "Deploy Container", - "reference": "https://attack.mitre.org/techniques/T1610/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "query", - "version": 206 - }, - "id": "df7fda76-c92b-4943-bc68-04460a5ea5ba_206", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/df9c0e92-5dee-4f1d-a760-3a5c039e4382_2.json b/packages/security_detection_engine/kibana/security_rule/df9c0e92-5dee-4f1d-a760-3a5c039e4382_2.json new file mode 100644 index 00000000000..344deed6d44 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/df9c0e92-5dee-4f1d-a760-3a5c039e4382_2.json @@ -0,0 +1,99 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule correlates security alerts with processes exhibiting unusually high CPU utilization on the same host and process ID within a short time window. This behavior may indicate malicious activity such as malware execution, cryptomining, exploit payload execution, or abuse of system resources following initial compromise.", + "from": "now-9m", + "interval": "5m", + "language": "esql", + "license": "Elastic License v2", + "name": "Detection Alert on a Process Exhibiting CPU Spike", + "note": "## Triage and analysis\n\n### Investigating Detection Alert on a Process Exhibiting CPU Spike\n\nThis rule identifies processes that both triggered a security alert and exhibited unusually high CPU utilization on the\nsame host and process ID within a short time window. This combination may indicate malicious execution, resource abuse, or\npost-compromise activity.\n\n### Possible investigation steps\n- Review the correlated alert(s) to understand why the process was flagged by Elastic Defend.\n- Examine the process name, command line, and SHA-256 hash to determine whether the process is expected or known to be malicious.\n- Validate the observed CPU usage and duration to determine whether the spike is abnormal for this process and host.\n- Check for related process activity such as parent/child processes, suspicious process spawning, or privilege escalation attempts.\n- Review additional host telemetry including:\n - Network connections initiated by the process\n - File creation or modification events\n - Persistence mechanisms (services, scheduled tasks, registry keys)\n- Determine whether similar activity is observed on other hosts, which may indicate a broader compromise.\n\n### False positive analysis\n- Legitimate high-CPU processes such as software updates, backup agents, security scans, or system maintenance tasks.\n- Resource-intensive but benign applications (e.g., compilers, video encoding, data processing jobs).\n- Security tools or monitoring agents temporarily consuming high CPU.\n\n### Response and remediation\n- If malicious activity is confirmed, isolate the affected host to prevent further impact.\n- Terminate the offending process if safe to do so.\n- Remove any identified malicious binaries or artifacts and eliminate persistence mechanisms.\n- Apply relevant patches or configuration changes to remediate the root cause.\n- Monitor the environment for recurrence of similar high-CPU processes combined with security alerts.\n- Escalate the incident if multiple hosts or indicators suggest coordinated or widespread activity.", + "query": "FROM metrics-*, .alerts-security.* METADATA _index\n| where not KQL(\"\"\"kibana.alert.rule.tags : \"Rule Type: Higher-Order Rule\" \"\"\")\n| eval\n // processes with more than 70% total CPU use\n cpu_metrics_pids = CASE(_index like \".ds-metrics-system.process-*\" and system.process.cpu.total.norm.pct >= 0.7, process.pid, null),\n // any security alert with process.name and ID populated excluding low severity ones\n alerts_pids = CASE(_index like \".internal.alerts-security.*\" and kibana.alert.rule.name is not null and process.name is not null and process.pid is not null and host.id is not null and kibana.alert.risk_score > 21, process.pid, null)\n| stats pid_with_cpu_spike = COUNT_DISTINCT(cpu_metrics_pids), pid_with_alerts = COUNT_DISTINCT(alerts_pids),\n Esql.max_cpu_pct = MAX(system.process.cpu.total.norm.pct),\n Esql.alerts = VALUES(kibana.alert.rule.name),\n Esql.process_hash_sha256 = VALUES(process.hash.sha256),\n process_path = VALUES(process.executable),\n parent_process_path = VALUES(process.parent.executable),\n user_name = VALUES(user.name),\n cmdline = VALUES(process.command_line) by process.pid, process.name, host.id\n| where pid_with_cpu_spike > 0 and pid_with_alerts > 0\n// populate fields to use in rule exceptions\n| eval process.hash.sha256 = MV_FIRST(Esql.process_hash_sha256),\n process.executable = MV_FIRST(process_path),\n process.parent.executable = MV_FIRST(parent_process_path),\n process.command_line = MV_FIRST(cmdline),\n user.name = MV_FIRST(user_name)\n| KEEP user.name, host.id, process.*, Esql.*\n", + "required_fields": [ + { + "ecs": false, + "name": "Esql.alerts", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.max_cpu_pct", + "type": "double" + }, + { + "ecs": false, + "name": "Esql.process_hash_sha256", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.command_line", + "type": "wildcard" + }, + { + "ecs": true, + "name": "process.executable", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.hash.sha256", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.executable", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.pid", + "type": "long" + }, + { + "ecs": true, + "name": "user.name", + "type": "keyword" + } + ], + "risk_score": 73, + "rule_id": "df9c0e92-5dee-4f1d-a760-3a5c039e4382", + "setup": "## Setup\n\nThis rule requires host CPU metrics collected via the Elastic Agent **System** integration.\n\n### System Metrics Integration Setup\nThe System integration collects host-level metrics such as CPU usage, load, memory, and process statistics and sends them to Elasticsearch using Elastic Agent.\n\n#### Prerequisite Requirements:\n- Elastic Agent managed by Fleet\n- A Fleet Server configured and reachable\n Refer to the Fleet Server setup guide:\n https://www.elastic.co/guide/en/fleet/current/fleet-server.html\n\n#### The following steps should be executed in order to enable CPU metrics collection:\n- Go to the Kibana home page and click **Add integrations**.\n- In the search bar, enter **System** and select the **System** integration.\n- Click **Add System**.\n- Configure an integration name and optionally add a description.\n- Under **Metrics**, ensure the following datasets are enabled:\n - `system.cpu`\n - `system.load` (optional but recommended)\n - `system.process` (optional, if process-level CPU is required)\n- Review optional and advanced settings as needed.\n- Add the integration to an existing agent policy or create a new agent policy.\n- Deploy the Elastic Agent to the hosts from which CPU metrics should be collected.\n- Click **Save and Continue** to finalize the setup.\n\n#### Validation\nAfter deployment, verify CPU metrics ingestion by confirming the presence of documents in:\n- `metrics-system.cpu-*`\n- `metrics-system.load-*` (if enabled)\n\nFor more details on the System integration and available metrics, refer to the documentation:\nhttps://docs.elastic.co/integrations/system\n", + "severity": "high", + "tags": [ + "Use Case: Threat Detection", + "Rule Type: Higher-Order Rule", + "Resources: Investigation Guide", + "Domain: Endpoint", + "Tactic: Impact" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0040", + "name": "Impact", + "reference": "https://attack.mitre.org/tactics/TA0040/" + }, + "technique": [] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 2 + }, + "id": "df9c0e92-5dee-4f1d-a760-3a5c039e4382_2", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/e26f042e-c590-4e82-8e05-41e81bd822ad_321.json b/packages/security_detection_engine/kibana/security_rule/e26f042e-c590-4e82-8e05-41e81bd822ad_321.json new file mode 100644 index 00000000000..21bf21170c7 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/e26f042e-c590-4e82-8e05-41e81bd822ad_321.json @@ -0,0 +1,165 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects PowerShell scripts that invoke Reflection.Assembly or Assembly.Load to load .NET assemblies. Attackers use this method to load executables and DLLs without writing to the disk, bypassing security solutions.", + "filters": [ + { + "meta": { + "negate": true + }, + "query": { + "wildcard": { + "file.path": { + "case_insensitive": true, + "value": "C:\\Program Files\\Microsoft Monitoring Agent\\Agent\\Health Service State\\Monitoring Host Temporary Files*\\AvailabilityGroupMonitoring.ps1" + } + } + } + }, + { + "meta": { + "negate": true + }, + "query": { + "wildcard": { + "file.path": { + "case_insensitive": true, + "value": "?:\\\\ProgramData\\\\Microsoft\\\\Windows Defender Advanced Threat Protection\\\\DataCollection\\\\*" + } + } + } + } + ], + "from": "now-9m", + "index": [ + "winlogbeat-*", + "logs-windows.powershell*" + ], + "investigation_fields": { + "field_names": [ + "@timestamp", + "user.name", + "user.id", + "user.domain", + "powershell.file.script_block_text", + "powershell.file.script_block_id", + "powershell.sequence", + "powershell.total", + "file.path", + "file.directory", + "file.name", + "process.pid", + "host.name", + "host.id", + "powershell.file.script_block_length" + ] + }, + "language": "kuery", + "license": "Elastic License v2", + "name": "Suspicious .NET Reflection via PowerShell", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This guide was created by humans with the assistance of generative AI. While its contents have been manually curated to include the most valuable information, always validate assumptions and adjust procedures to match your internal runbooks and incident triage and response policies.\n\n### Investigating Suspicious .NET Reflection via PowerShell\n\nThis alert indicates PowerShell script block content attempted to load a .NET assembly using reflection-based APIs (for example, `[System.Reflection.Assembly]::Load` or `Assembly.Load(...)`). While this can be used for legitimate extensibility, it is also commonly used to execute .NET payloads in memory and reduce file-based artifacts.\n\n#### Key alert fields to review\n\n- `user.name`, `user.domain`, `user.id`: Account execution context for correlation, prioritization, and scoping.\n- `host.name`, `host.id`: Host execution context for correlation, prioritization, and scoping.\n- `powershell.file.script_block_text`: Script block content that matched the detection logic.\n- `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`: Script block metadata to pivot to other fragments or reconstruct full script content when split across multiple events.\n- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file.\n- `powershell.file.script_block_length`: Script block length (size) context.\n\n#### Possible investigation steps\n\n- Triage the execution context:\n - Identify the affected host and user using `host.name`, `host.id`, `user.name`, `user.domain`, and `user.id`.\n - Prioritize alerts where the user is unexpected for the host role, or where the same user appears across multiple hosts in a short time window.\n- Analyze the assembly load behavior in `powershell.file.script_block_text`:\n - Identify what is being passed into the load call (assembly name vs. byte array or dynamically generated content).\n - Check for indicators of staged content within the same script block, such as long encoded blobs, dynamic string construction, or multiple transformation steps (decoding, decompression, or concatenation) that produce the assembly bytes.\n - Look for immediate follow-on actions suggesting the loaded assembly is executed (for example, accessing types/methods and invoking them after the load).\n- Reconstruct the full script block when needed:\n - If the content appears partial, group related events by `powershell.file.script_block_id` and order by `powershell.sequence` to `powershell.total` to rebuild the full script block before assessing intent.\n - Use `powershell.file.script_block_length` as a signal for embedded content (large or unusually variable sizes can indicate payload staging).\n- Determine script origin and persistence indicators:\n - If `file.path`/`file.name` are present, assess whether the script is stored in an expected location for the user and host role, or in a user-writable / temporary directory indicated by `file.directory`.\n - If `file.path` is present, retrieve and review the corresponding script file for additional context (embedded payloads, additional functions, or execution logic not visible in a single script block event).\n - If `file.path` is not present, treat the activity as potentially interactive or remotely delivered and rely on `powershell.file.script_block_id` and time-based pivots to gather surrounding context.\n- Scope related PowerShell activity on the same host and user:\n - Pivot on `host.id` and `user.id` to identify additional script blocks around the alert time that may show setup, staging, or follow-on actions.\n - Check for repeated `Assembly.Load` usage across multiple `powershell.file.script_block_id` values, which may indicate iterative execution attempts or multiple payload stages.\n- Scope across the environment:\n - Search for the same `file.path`/`file.name` and similar `powershell.file.script_block_text` patterns on other hosts to identify propagation or reuse.\n - Identify whether the same `user.id` is associated with similar script blocks across multiple `host.id` values to assess potential lateral movement or shared automation.\n- Correlate with adjacent telemetry (if available in your environment):\n - Process telemetry: Determine how PowerShell was launched and by what parent process around the alert time to understand delivery (interactive use, scheduled execution, service context, or another process).\n - Network telemetry: Review outbound activity near the alert time for signs of payload retrieval, staging infrastructure, or command-and-control.\n - File/registry telemetry: Look for newly created or modified scripts, DLLs, or persistence-related changes temporally aligned with the script block execution.\n - Authentication telemetry: Review logon patterns for the same user and host around the alert time to identify unusual access patterns that could explain the execution.\n- If response actions are available:\n - Collect host DNS cache and a snapshot of running/installed services to support scoping and to identify suspicious services or recent name resolution consistent with payload staging.\n\n### False positive analysis\n\n- Legitimate scripts may load assemblies to support internal tooling, plugin models, packaged dependencies, or automation tasks that embed .NET functionality in PowerShell.\n- Benign activity is more likely when:\n - `file.path`/`file.name` map to a known, owned script with a stable operational purpose.\n - The same `user.id` consistently runs the same script on the same `host.id` as part of normal operations.\n - `powershell.file.script_block_text` is readable and clearly loads expected assemblies without embedded blobs or multi-step content staging.\n- Suspicious activity is more likely when:\n - The assembly is loaded from dynamically generated bytes (encoded or transformed content) and is followed by reflection-based invocation.\n - The script originates from an unusual `file.directory` or the execution context (`user.name`/`host.name`) is inconsistent with expected administrative workflows.\n- If confirmed benign, document the owning team, expected execution pattern, and the specific script identity (`file.path`/`file.name`) to enable narrowly scoped tuning.\n\n### Response and remediation\n\n- If the activity is confirmed or strongly suspected to be malicious:\n - Isolate the affected host to prevent further in-memory execution and follow-on activity.\n - Preserve evidence from the alert:\n - Export the full reconstructed script block content using `powershell.file.script_block_id` with `powershell.sequence`/`powershell.total`.\n - Capture `host.id`, `host.name`, `user.id`, `user.name`, `user.domain`, and any associated `file.path`/`file.name` context.\n - Identify and contain related activity:\n - Hunt for additional related script blocks on the same host/user and across other hosts for similar `powershell.file.script_block_text` patterns.\n - Contain any identified infrastructure or artifacts based on indicators found in the script content (for example, domains, IPs, or downloaded file names).\n - Remediate:\n - Remove persistence and stop any related malicious processes discovered during triage and correlation.\n - Review the impacted account (`user.id`) for compromise and rotate credentials as appropriate, prioritizing privileged access.\n - Validate the host is remediated and monitored for recurrence before returning it to service.\n- If the activity is benign but requires reduction in alert volume:\n - Record the approved use case and expected execution context (host role, user role, and script location).\n - Apply targeted tuning anchored to stable identifiers (for example, specific `file.path` and expected accounts) rather than broadly suppressing assembly load behavior.\n - Review PowerShell governance and monitoring to ensure in-memory loading is limited to approved workflows.\n", + "query": "event.category:process and host.os.type:windows and\n(\n powershell.file.script_block_text : (\n \"[System.Reflection.Assembly]::Load\" or\n \"[Reflection.Assembly]::Load\" or\n \"Assembly.Load(\"\n ) and\n powershell.file.script_block_text : (\n \"FromBase64String\" or \"GzipStream\" or \"DeflateStream\" or \"IO.Compression\" or\n \"MemoryStream\" or \"DownloadData\" or \"WebClient\" or \"ReadAllBytes\"\n )\n)\n", + "references": [ + "https://docs.microsoft.com/en-us/dotnet/api/system.reflection.assembly.load" + ], + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.category", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_text", + "type": "unknown" + } + ], + "risk_score": 47, + "rule_id": "e26f042e-c590-4e82-8e05-41e81bd822ad", + "setup": "## Setup\n\nPowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104).\nSetup instructions: https://ela.st/powershell-logging-setup\n", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Tactic: Execution", + "Resources: Investigation Guide", + "Data Source: PowerShell Logs" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1055", + "name": "Process Injection", + "reference": "https://attack.mitre.org/techniques/T1055/", + "subtechnique": [ + { + "id": "T1055.001", + "name": "Dynamic-link Library Injection", + "reference": "https://attack.mitre.org/techniques/T1055/001/" + }, + { + "id": "T1055.002", + "name": "Portable Executable Injection", + "reference": "https://attack.mitre.org/techniques/T1055/002/" + } + ] + }, + { + "id": "T1620", + "name": "Reflective Code Loading", + "reference": "https://attack.mitre.org/techniques/T1620/" + } + ] + }, + { + "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": "query", + "version": 321 + }, + "id": "e26f042e-c590-4e82-8e05-41e81bd822ad_321", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/e819b7eb-c2d4-4adc-b0c9-658aeb140450_2.json b/packages/security_detection_engine/kibana/security_rule/e819b7eb-c2d4-4adc-b0c9-658aeb140450_2.json new file mode 100644 index 00000000000..f842ad19854 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/e819b7eb-c2d4-4adc-b0c9-658aeb140450_2.json @@ -0,0 +1,121 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects multiple lateral movement alerts from a user that was observed for the first time in the previous 5 days of alerts history. Analysts can use this high-order detection to prioritize triage and response.", + "from": "now-7200m", + "interval": "9m", + "language": "esql", + "license": "Elastic License v2", + "name": "Lateral Movement Alerts from a Newly Observed User", + "note": "## Triage and analysis\n\n### Investigating Lateral Movement Alerts from a Newly Observed User\n\nThis rule surfaces newly observed, low-frequency source user triggering multiple lateral movement alerts.\n\nBecause the alert has not been seen previously for this rule and host, it should be prioritized for validation to determine\nwhether it represents a true compromise or rare benign activity.\n\n### Investigation Steps\n\n- Identify the source user, affected hosts and review the associated rule name to understand the behavior that triggered the alert.\n- Validate the source address and user context under which the activity occurred and assess whether it aligns with normal behavior for that address.\n- Refer to the specific rule investigation guide for further actions.\n\n### False Positive Considerations\n\n- Administrative scripts or automation tools can trigger behavior-based detections when first introduced.\n- Security tooling, IT management agents, or EDR integrations may generate new behavior alerts during updates or configuration changes.\n- Development or testing environments may produce one-off behaviors that resemble malicious techniques.\n\n### Response and Remediation\n\n- If the activity is confirmed malicious, isolate the affected host to prevent further execution or lateral movement.\n- Terminate malicious processes and remove any dropped files or persistence mechanisms.\n- Collect forensic artifacts to understand initial access and execution flow.\n- Patch or remediate any vulnerabilities or misconfigurations that enabled the behavior.\n- If benign, document the finding and consider tuning or exception handling to reduce future noise.\n- Continue monitoring the host and environment for recurrence of the behavior or related alerts.", + "query": "FROM .alerts-security.* METADATA _index\n\n// Lateral Movement related rules\n| where kibana.alert.rule.threat.tactic.name is not null and user.id is not null and \n (to_string(user.id) like \"S-1-5-21*\" or to_string(user.id) like \"S-1-12-*\") and\n host.id is not null and KQL(\"\"\"kibana.alert.rule.threat.tactic.name : \"Lateral Movement\" \"\"\") and\n not KQL(\"\"\"kibana.alert.rule.tags : \"Rule Type: Higher-Order Rule\" \"\"\")\n\n// aggregate stats by user.id\n| stats Esql.first_time_seen = MIN(@timestamp),\n Esql.alerts_count = count(*),\n Esql.unique_rules_count = COUNT_DISTINCT(kibana.alert.rule.name),\n Esql.unique_count_host_id = COUNT_DISTINCT(host.id),\n Esql.rule_name_values = VALUES(kibana.alert.rule.name),\n Esql.host_id_values = VALUES(host.id),\n Esql.host_ip_values = VALUES(host.ip),\n Esql.source_ip_values = VALUES(source.ip),\n Esql.process_cmd_line = VALUES(process.command_line),\n Esql.tactic_name_values = VALUES(kibana.alert.rule.threat.tactic.name) by user.id, user.name\n\n// at least 2 unique lateral movement detection rules from same user.id and that was first seen in last 5 days\n| eval Esql.date_diff = DATE_DIFF(\"minute\", Esql.first_time_seen, now())\n| where Esql.unique_rules_count >= 2 and\n // matches are within 10m of the rule execution time to avoid alert duplicates\n Esql.date_diff <= 10\n| eval source.ip = MV_FIRST(Esql.source_ip_values), host.id = MV_FIRST(Esql.host_id_values) \n| KEEP Esql.*, user.id, user.name, host.id, source.ip\n", + "references": [ + "https://www.elastic.co/docs/solutions/security/detect-and-alert/about-detection-rules" + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.alerts_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.date_diff", + "type": "integer" + }, + { + "ecs": false, + "name": "Esql.first_time_seen", + "type": "date" + }, + { + "ecs": false, + "name": "Esql.host_id_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.host_ip_values", + "type": "ip" + }, + { + "ecs": false, + "name": "Esql.process_cmd_line", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.rule_name_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.source_ip_values", + "type": "ip" + }, + { + "ecs": false, + "name": "Esql.tactic_name_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.unique_count_host_id", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.unique_rules_count", + "type": "long" + }, + { + "ecs": true, + "name": "host.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.ip", + "type": "ip" + }, + { + "ecs": true, + "name": "user.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "user.name", + "type": "keyword" + } + ], + "risk_score": 73, + "rule_id": "e819b7eb-c2d4-4adc-b0c9-658aeb140450", + "severity": "high", + "tags": [ + "OS: Windows", + "Use Case: Threat Detection", + "Rule Type: Higher-Order Rule", + "Tactic: Lateral Movement", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0008", + "name": "Lateral Movement", + "reference": "https://attack.mitre.org/tactics/TA0008/" + }, + "technique": [] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 2 + }, + "id": "e819b7eb-c2d4-4adc-b0c9-658aeb140450_2", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/e903ce9a-5ce6-4246-bb14-75ed3ec2edf5_11.json b/packages/security_detection_engine/kibana/security_rule/e903ce9a-5ce6-4246-bb14-75ed3ec2edf5_11.json new file mode 100644 index 00000000000..c7a3c3fba72 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/e903ce9a-5ce6-4246-bb14-75ed3ec2edf5_11.json @@ -0,0 +1,212 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects PowerShell scripts that uses format placeholders like \"{0}{1}\" with the -f operator or ::Format to reorder strings at runtime. Attackers use format-based reconstruction to hide commands or payload strings and evade static analysis and AMSI.", + "from": "now-9m", + "investigation_fields": { + "field_names": [ + "@timestamp", + "user.name", + "user.id", + "user.domain", + "powershell.file.script_block_text", + "powershell.file.script_block_id", + "powershell.sequence", + "powershell.total", + "file.path", + "file.directory", + "file.name", + "process.pid", + "host.name", + "host.id", + "powershell.file.script_block_length" + ] + }, + "language": "esql", + "license": "Elastic License v2", + "name": "Potential PowerShell Obfuscation via String Reordering", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This guide was created by humans with the assistance of generative AI. While its contents have been manually curated to include the most valuable information, always validate assumptions and adjust procedures to match your internal runbooks and incident triage and response policies.\n\n### Investigating Potential PowerShell Obfuscation via String Reordering\n\nThis alert indicates a PowerShell script block used indexed format placeholders (for example, \"{0}{1}\") with runtime formatting (for example, the `-f` operator or `::Format`) to reorder and reconstruct strings. This technique can hide meaningful strings (commands, URLs, artifact names) from straightforward text inspection and can be used as part of staged execution.\n\nBecause the detection requires repeated occurrences of these patterns in a larger script block, triage should focus on (1) execution context (host and user), (2) script origin (file-backed vs. in-memory/interactive), and (3) what strings are being reconstructed and what actions they enable.\n\n#### Key alert fields to review\n\n- `user.name`, `user.domain`, `user.id`: Account execution context for correlation, prioritization, and scoping.\n- `host.name`, `host.id`: Host execution context for correlation, prioritization, and scoping.\n- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file.\n- `powershell.file.script_block_text`: Script block content that matched the detection logic.\n- `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`: Script block metadata to pivot to other fragments or reconstruct full script content when split across multiple events.\n- `Esql.script_block_tmp`: Transformed script block where detection patterns replace original content with a marker to support scoring/counting and quickly spot match locations.\n- `Esql.script_block_pattern_count`: Count of matches for the detection pattern(s) observed in the script block content.\n- `powershell.file.script_block_entropy_bits`: Shannon entropy of the script block. Higher values may indicate obfuscation.\n- `powershell.file.script_block_surprisal_stdev`: Standard deviation of surprisal across the script block. Low values indicate uniform randomness. High values indicate mixed patterns and variability.\n- `powershell.file.script_block_unique_symbols`: Count of distinct characters present in the script block.\n- `powershell.file.script_block_length`: Script block length (size) context.\n\n#### Possible investigation steps\n\n- Confirm the execution context and initial scope:\n - Identify the affected endpoint using `host.name` and `host.id`. Check for other security alerts or suspicious activity on the same host around the alert time.\n - Identify the account context using `user.name`, `user.domain`, and `user.id`. Prioritize alerts where the user is unexpected for the host role or where the user does not typically run PowerShell.\n - If `file.path` / `file.directory` / `file.name` are present, capture the script location and assess whether the path and filename are expected for that host and user. If file fields are missing, treat the activity as potentially interactive or in-memory and increase emphasis on correlated telemetry.\n\n- Review the script block content and determine what is being reconstructed:\n - Start with `Esql.script_block_tmp` to quickly locate where formatting patterns occur, then use `powershell.file.script_block_text` as the authoritative source for analysis and evidence.\n - Identify how formatting is used:\n - Placeholder-only or placeholder-heavy format strings that primarily consist of `{n}` tokens.\n - Out-of-order placeholder indexes (for example, `{3}{0}{2}{1}`) and repeated reordering blocks.\n - Multiple reconstruction stages where formatted output is subsequently reformatted or concatenated.\n - Reconstruct key strings by mapping placeholder indexes to the arguments/fragments used in each formatting operation. Record any reconstructed strings that indicate follow-on behavior (remote addresses, filenames, persistence identifiers, or execution flow).\n\n- Use the available scoring and statistics fields to guide prioritization:\n - Review `Esql.script_block_pattern_count` to understand how heavily the script relies on formatting-based reconstruction. Higher counts generally increase suspicion.\n - Review `powershell.file.script_block_entropy_bits`, `powershell.file.script_block_unique_symbols`, `powershell.file.script_block_surprisal_stdev`, and `powershell.file.script_block_length` to differentiate structured, readable scripts from highly variable or packed content.\n - Treat these values as supporting signals; base the decision primarily on reconstructed strings and correlated activity.\n\n- Reconstruct full script content when split across multiple events:\n - Pivot on `powershell.file.script_block_id` to gather all fragments for the same script block.\n - Order fragments using `powershell.sequence` and confirm completeness using `powershell.total` before drawing conclusions.\n\n- Correlate and validate impact using adjacent telemetry available in your environment:\n - Review other PowerShell script blocks from the same `host.id` and `user.id` to identify staging, deobfuscation, or follow-on execution.\n - Correlate with endpoint telemetry for the same host and timeframe to understand how PowerShell was started and what occurred next (process ancestry, network activity, file/registry changes, and authentication activity). Use reconstructed strings to focus this correlation.\n\n- Expand the hunt to assess prevalence:\n - Search for the same or similar content in `powershell.file.script_block_text` (shared fragments, repeated placeholder patterns) across other hosts.\n - Use `Esql.script_block_pattern_count` and the script block statistics fields to identify other high-similarity or high-complexity scripts that may represent the same technique.\n\n### False positive analysis\n\n- Legitimate automation can use indexed placeholders to build dynamic output, reports, or templated configuration content. Benign usage is more likely when the resulting strings are human-readable and the script has an expected on-disk origin (`file.path` / `file.name`) and consistent execution over time.\n- Some internally developed frameworks generate PowerShell dynamically and may include repeated formatting patterns. Validate ownership of the script source and whether execution by the identified `user.id` on the identified `host.id` is expected.\n- Localization or templating logic may use indexed placeholders. This is typically associated with readable templates and stable execution patterns rather than multi-stage reconstruction of operational strings.\n\n### Response and remediation\n\n- If malicious or suspicious activity is confirmed:\n - Contain the affected endpoint identified by `host.name` / `host.id` to prevent further execution and limit lateral movement.\n - Preserve evidence, including `powershell.file.script_block_text`, `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`, and the alert enrichment fields (`Esql.script_block_tmp`, `Esql.script_block_pattern_count`, and script block statistics).\n - Use reconstructed strings to drive scoping and impact assessment (look for related activity on the same host, and search for the same indicators across other hosts and users).\n\n- Eradication and recovery:\n - Identify the execution mechanism and remove it (for example, an unexpected script file, a startup trigger, or other persistence identified during correlation).\n - Remove or quarantine related artifacts discovered during analysis and validate that similar activity is not occurring on other endpoints.\n\n- If the activity is determined to be benign:\n - Document the expected script source (`file.path` / `file.name`), the responsible team, and the expected execution context (`host.id`, `user.id`) to support faster triage of future alerts.\n - Monitor for deviations from the established baseline (new hosts, new users, or materially different reconstructed strings).\n", + "query": "from logs-windows.powershell_operational* metadata _id, _version, _index\n| where event.code == \"4104\" and powershell.file.script_block_text like \"*{0}*\"\n\n// Filter out smaller scripts that are unlikely to implement obfuscation using the patterns we are looking for\n| eval Esql.script_block_length = length(powershell.file.script_block_text)\n| where Esql.script_block_length > 500\n\n// replace the patterns we are looking for with the \ud83d\udd25 emoji to enable counting them\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| eval Esql.script_block_tmp = replace(\n powershell.file.script_block_text,\n \"\"\"((\\{\\d+\\}){2,}[\"']\\s?-f|::Format[^\\{]+(\\{\\d+\\}){2,})\"\"\",\n \"\ud83d\udd25\"\n)\n\n// count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| eval Esql.script_block_pattern_count = length(Esql.script_block_tmp) - length(replace(Esql.script_block_tmp, \"\ud83d\udd25\", \"\"))\n\n// keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| keep\n Esql.script_block_pattern_count,\n Esql.script_block_length,\n Esql.script_block_tmp,\n powershell.file.*,\n file.path,\n file.directory,\n powershell.sequence,\n powershell.total,\n _id,\n _version,\n _index,\n host.name,\n host.id,\n agent.id,\n user.id\n\n// Filter for scripts that match the pattern at least five times\n| where Esql.script_block_pattern_count >= 5\n\n// Exclude Noisy Patterns\n\n// Icinga Framework\n| where not file.directory == \"C:\\\\Program Files\\\\WindowsPowerShell\\\\Modules\\\\icinga-powershell-framework\\\\cache\"\n // ESQL requires this condition, otherwise it only returns matches where file.directory exists.\n or file.directory IS NULL\n\n| where not (powershell.file.script_block_text LIKE \"*GitBranchStatus*\" AND \n powershell.file.script_block_text LIKE \"*$s.BranchBehindStatusSymbol.Text*\")\n| where not\n // https://wtfbins.wtf/17\n (\n (powershell.file.script_block_text like \"*sentinelbreakpoints*\" or\n powershell.file.script_block_text like \"*:::::\\\\\\\\windows\\\\\\\\sentinel*\")\n and\n (powershell.file.script_block_text like \"*$local:Bypassed*\" or\n powershell.file.script_block_text like \"*origPSExecutionPolicyPreference*\")\n )\n", + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.script_block_length", + "type": "integer" + }, + { + "ecs": false, + "name": "Esql.script_block_pattern_count", + "type": "integer" + }, + { + "ecs": false, + "name": "Esql.script_block_tmp", + "type": "keyword" + }, + { + "ecs": false, + "name": "_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "_index", + "type": "keyword" + }, + { + "ecs": false, + "name": "_version", + "type": "long" + }, + { + "ecs": true, + "name": "agent.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.directory", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.path", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.name", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_entropy_bits", + "type": "double" + }, + { + "ecs": false, + "name": "powershell.file.script_block_entropy_normalized", + "type": "double" + }, + { + "ecs": false, + "name": "powershell.file.script_block_hash", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_length", + "type": "long" + }, + { + "ecs": false, + "name": "powershell.file.script_block_surprisal_stdev", + "type": "double" + }, + { + "ecs": false, + "name": "powershell.file.script_block_text", + "type": "text" + }, + { + "ecs": false, + "name": "powershell.file.script_block_unique_symbols", + "type": "long" + }, + { + "ecs": false, + "name": "powershell.sequence", + "type": "long" + }, + { + "ecs": false, + "name": "powershell.total", + "type": "long" + }, + { + "ecs": true, + "name": "user.id", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "e903ce9a-5ce6-4246-bb14-75ed3ec2edf5", + "setup": "## Setup\n\nPowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104).\nSetup instructions: https://ela.st/powershell-logging-setup\n", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: PowerShell Logs", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1027", + "name": "Obfuscated Files or Information", + "reference": "https://attack.mitre.org/techniques/T1027/" + }, + { + "id": "T1140", + "name": "Deobfuscate/Decode Files or Information", + "reference": "https://attack.mitre.org/techniques/T1140/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.001", + "name": "PowerShell", + "reference": "https://attack.mitre.org/techniques/T1059/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 11 + }, + "id": "e903ce9a-5ce6-4246-bb14-75ed3ec2edf5_11", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/e903ce9a-5ce6-4246-bb14-75ed3ec2edf5_7.json b/packages/security_detection_engine/kibana/security_rule/e903ce9a-5ce6-4246-bb14-75ed3ec2edf5_7.json deleted file mode 100644 index 914f714802c..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/e903ce9a-5ce6-4246-bb14-75ed3ec2edf5_7.json +++ /dev/null @@ -1,153 +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\" and powershell.file.script_block_text like \"*{0}*\"\n\n// Filter out smaller scripts that are unlikely to implement obfuscation using the patterns we are looking for\n| eval Esql.script_block_length = length(powershell.file.script_block_text)\n| where Esql.script_block_length > 500\n\n// replace the patterns we are looking for with the \ud83d\udd25 emoji to enable counting them\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| eval Esql.script_block_tmp = replace(\n powershell.file.script_block_text,\n \"\"\"((\\{\\d+\\}){2,}[\"']\\s?-f|::Format[^\\{]+(\\{\\d+\\}){2,})\"\"\",\n \"\ud83d\udd25\"\n)\n\n// count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| eval Esql.script_block_pattern_count = length(Esql.script_block_tmp) - length(replace(Esql.script_block_tmp, \"\ud83d\udd25\", \"\"))\n\n// keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| keep\n Esql.script_block_pattern_count,\n Esql.script_block_length,\n Esql.script_block_tmp,\n powershell.file.script_block_text,\n powershell.file.script_block_id,\n file.path,\n file.directory,\n powershell.sequence,\n powershell.total,\n _id,\n _index,\n host.name,\n agent.id,\n user.id\n\n// Filter for scripts that match the pattern at least four times\n| where Esql.script_block_pattern_count >= 4\n\n// Exclude Noisy Patterns\n\n// Icinga Framework\n| where not file.directory == \"C:\\\\Program Files\\\\WindowsPowerShell\\\\Modules\\\\icinga-powershell-framework\\\\cache\"\n // ESQL requires this condition, otherwise it only returns matches where file.directory exists.\n or file.directory IS NULL\n\n| where not (powershell.file.script_block_text LIKE \"*GitBranchStatus*\" AND \n powershell.file.script_block_text LIKE \"*$s.BranchBehindStatusSymbol.Text*\")\n| where not\n // https://wtfbins.wtf/17\n (\n (powershell.file.script_block_text like \"*sentinelbreakpoints*\" or\n powershell.file.script_block_text like \"*:::::\\\\\\\\windows\\\\\\\\sentinel*\")\n and\n (powershell.file.script_block_text like \"*$local:Bypassed*\" or\n powershell.file.script_block_text like \"*origPSExecutionPolicyPreference*\")\n )\n", - "related_integrations": [ - { - "package": "windows", - "version": "^3.0.0" - } - ], - "required_fields": [ - { - "ecs": false, - "name": "Esql.script_block_length", - "type": "integer" - }, - { - "ecs": false, - "name": "Esql.script_block_pattern_count", - "type": "integer" - }, - { - "ecs": false, - "name": "Esql.script_block_tmp", - "type": "keyword" - }, - { - "ecs": false, - "name": "_id", - "type": "keyword" - }, - { - "ecs": false, - "name": "_index", - "type": "keyword" - }, - { - "ecs": true, - "name": "agent.id", - "type": "keyword" - }, - { - "ecs": true, - "name": "file.directory", - "type": "keyword" - }, - { - "ecs": true, - "name": "file.path", - "type": "keyword" - }, - { - "ecs": true, - "name": "host.name", - "type": "keyword" - }, - { - "ecs": false, - "name": "powershell.file.script_block_id", - "type": "keyword" - }, - { - "ecs": false, - "name": "powershell.file.script_block_text", - "type": "text" - }, - { - "ecs": false, - "name": "powershell.sequence", - "type": "long" - }, - { - "ecs": false, - "name": "powershell.total", - "type": "long" - }, - { - "ecs": true, - "name": "user.id", - "type": "keyword" - } - ], - "risk_score": 21, - "rule_id": "e903ce9a-5ce6-4246-bb14-75ed3ec2edf5", - "setup": "## Setup\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nAdministrative Templates >\nWindows PowerShell >\nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n", - "severity": "low", - "tags": [ - "Domain: Endpoint", - "OS: Windows", - "Use Case: Threat Detection", - "Tactic: Defense Evasion", - "Data Source: PowerShell Logs", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0005", - "name": "Defense Evasion", - "reference": "https://attack.mitre.org/tactics/TA0005/" - }, - "technique": [ - { - "id": "T1027", - "name": "Obfuscated Files or Information", - "reference": "https://attack.mitre.org/techniques/T1027/" - }, - { - "id": "T1140", - "name": "Deobfuscate/Decode Files or Information", - "reference": "https://attack.mitre.org/techniques/T1140/" - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0002", - "name": "Execution", - "reference": "https://attack.mitre.org/tactics/TA0002/" - }, - "technique": [ - { - "id": "T1059", - "name": "Command and Scripting Interpreter", - "reference": "https://attack.mitre.org/techniques/T1059/", - "subtechnique": [ - { - "id": "T1059.001", - "name": "PowerShell", - "reference": "https://attack.mitre.org/techniques/T1059/001/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 7 - }, - "id": "e903ce9a-5ce6-4246-bb14-75ed3ec2edf5_7", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/e9b0902b-c515-413b-b80b-a8dcebc81a66_8.json b/packages/security_detection_engine/kibana/security_rule/e9b0902b-c515-413b-b80b-a8dcebc81a66_8.json new file mode 100644 index 00000000000..4002c4dcc25 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/e9b0902b-c515-413b-b80b-a8dcebc81a66_8.json @@ -0,0 +1,63 @@ +{ + "attributes": { + "anomaly_threshold": 70, + "author": [ + "Elastic" + ], + "description": "A machine learning job has detected an abnormal volume of remote files shared on the host indicating potential lateral movement activity. One of the primary goals of attackers after gaining access to a network is to locate and exfiltrate valuable information. Attackers might perform multiple small transfers to match normal egress activity in the network, to evade detection.", + "from": "now-90m", + "interval": "15m", + "license": "Elastic License v2", + "machine_learning_job_id": "lmd_high_count_remote_file_transfer", + "name": "Spike in Remote File Transfers", + "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 Spike in Remote File Transfers\n\nRemote file transfer technologies facilitate data sharing across networks, essential for collaboration and operations. However, adversaries exploit these to move laterally within a network, often transferring data stealthily to avoid detection. The 'Spike in Remote File Transfers' detection rule leverages machine learning to identify unusual transfer volumes, signaling potential malicious activity by comparing against established network baselines.\n\n### Possible investigation steps\n\n- Review the alert details to identify the specific host and time frame associated with the abnormal file transfer activity.\n- Analyze network logs and remote file transfer logs to determine the source and destination of the transfers, focusing on any unusual or unauthorized endpoints.\n- Cross-reference the identified host with known assets and user accounts to verify if the activity aligns with expected behavior or if it involves unauthorized access.\n- Investigate any associated user accounts for signs of compromise, such as unusual login times or locations, by reviewing authentication logs.\n- Check for any recent changes or anomalies in the network baseline that could explain the spike in file transfers, such as new software deployments or legitimate large data migrations.\n- Correlate the detected activity with other security alerts or incidents to identify potential patterns or coordinated attacks within the network.\n\n### False positive analysis\n\n- Regularly scheduled data backups or synchronization tasks can trigger false positives. Identify these tasks and create exceptions to prevent them from being flagged.\n- Automated software updates or patch management systems may cause spikes in file transfers. Exclude these systems from the rule to reduce false alerts.\n- Internal data sharing between departments for legitimate business purposes might be misidentified. Establish a baseline for these activities and adjust the detection thresholds accordingly.\n- High-volume data transfers during specific business operations, such as end-of-month reporting, can be mistaken for malicious activity. Temporarily adjust the rule settings during these periods to accommodate expected increases in transfer volumes.\n- Frequent file transfers from trusted external partners or vendors should be monitored and, if consistently benign, added to an allowlist to minimize unnecessary alerts.\n\n### Response and remediation\n\n- Isolate the affected host immediately to prevent further lateral movement and potential data exfiltration. Disconnect it from the network to contain the threat.\n- Conduct a thorough analysis of the transferred files to determine if sensitive data was involved and assess the potential impact of the data exposure.\n- Review and terminate any unauthorized remote access sessions or services on the affected host to prevent further exploitation.\n- Reset credentials for any accounts that were used or potentially compromised during the incident to prevent unauthorized access.\n- Apply security patches and updates to the affected systems to address any vulnerabilities that may have been exploited by the attackers.\n- Monitor network traffic for any additional unusual remote file transfer activities, using enhanced logging and alerting 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.", + "references": [ + "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html", + "https://docs.elastic.co/en/integrations/lmd", + "https://www.elastic.co/blog/detecting-lateral-movement-activity-a-new-kibana-integration", + "https://www.elastic.co/blog/remote-desktop-protocol-connections-elastic-security" + ], + "related_integrations": [ + { + "package": "lmd", + "version": "^2.0.0" + }, + { + "package": "endpoint", + "version": "^8.2.0" + } + ], + "risk_score": 21, + "rule_id": "e9b0902b-c515-413b-b80b-a8dcebc81a66", + "setup": "## Setup\n\nThis rule requires the `host.ip` field to be populated.\nFor **Elastic Defend** events on versions **8.18 and above**, this field is **disabled by default**.\n\nIf you are using **Elastic Defend**, ensure host IP collection is enabled by following the configuration steps in the\n[helper guide](https://www.elastic.co/docs/solutions/security/configure-elastic-defend/configure-data-volume-for-elastic-endpoint#host-fields).\n\nThe rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration.\n\n### Lateral Movement Detection Setup\nThe Lateral Movement Detection integration detects lateral movement activity by identifying abnormalities in file and Windows RDP events. Anomalies are detected using Elastic's Anomaly Detection feature.\n\n#### Prerequisite Requirements:\n- Fleet is required for Lateral Movement Detection.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n- File events collected by the [Elastic Defend](https://docs.elastic.co/en/integrations/endpoint) integration.\n- To install Elastic Defend, refer to the [documentation](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n\n#### The following steps should be executed to install assets associated with the Lateral Movement Detection integration:\n- Go to the Kibana homepage. Under Management, click Integrations.\n- In the query bar, search for Lateral Movement Detection and select the integration to see more details about it.\n- Follow the instructions under the **Installation** section.\n- For this rule to work, complete the instructions through **Add preconfigured anomaly detection jobs**.\n", + "severity": "low", + "tags": [ + "Use Case: Lateral Movement Detection", + "Rule Type: ML", + "Rule Type: Machine Learning", + "Tactic: Lateral Movement", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0008", + "name": "Lateral Movement", + "reference": "https://attack.mitre.org/tactics/TA0008/" + }, + "technique": [ + { + "id": "T1210", + "name": "Exploitation of Remote Services", + "reference": "https://attack.mitre.org/techniques/T1210/" + } + ] + } + ], + "type": "machine_learning", + "version": 8 + }, + "id": "e9b0902b-c515-413b-b80b-a8dcebc81a66_8", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/ec8efb0c-604d-42fa-ac46-ed1cfbc38f78_209.json b/packages/security_detection_engine/kibana/security_rule/ec8efb0c-604d-42fa-ac46-ed1cfbc38f78_209.json deleted file mode 100644 index 0a34b6db93d..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/ec8efb0c-604d-42fa-ac46-ed1cfbc38f78_209.json +++ /dev/null @@ -1,117 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic", - "Gary Blackwell", - "Austin Songer" - ], - "description": "Identifies when a new Inbox forwarding rule is created in Microsoft 365. Inbox rules process messages in the Inbox based on conditions and take actions. In this case, the rules will forward the emails to a defined address. Attackers can abuse Inbox Rules to intercept and exfiltrate email data without making organization-wide configuration changes or having the corresponding privileges.", - "false_positives": [ - "Users and Administrators can create inbox rules for legitimate purposes. Verify if it complies with the company policy and done with the user's consent. Exceptions can be added to this rule to filter expected behavior." - ], - "from": "now-30m", - "index": [ - "filebeat-*", - "logs-o365*" - ], - "language": "kuery", - "license": "Elastic License v2", - "name": "Microsoft 365 Inbox Forwarding Rule 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 Microsoft 365 Inbox Forwarding Rule Created\n\nMicrosoft 365 allows users to create inbox rules to automate email management, such as forwarding messages to another address. While useful, attackers can exploit these rules to secretly redirect emails, facilitating data exfiltration. The detection rule monitors for the creation of such forwarding rules, focusing on successful events that specify forwarding parameters, thus identifying potential unauthorized email redirection activities.\n\n### Possible investigation steps\n\n- Review the event details to identify the user account associated with the creation of the forwarding rule by examining the o365.audit.Parameters.\n- Check the destination email address specified in the forwarding rule (ForwardTo, ForwardAsAttachmentTo, or RedirectTo) to determine if it is an external or suspicious address.\n- Investigate the user's recent activity logs in Microsoft 365 to identify any unusual or unauthorized actions, focusing on event.dataset:o365.audit and event.provider:Exchange.\n- Verify if the user has a legitimate reason to create such a forwarding rule by consulting with their manager or reviewing their role and responsibilities.\n- Assess if there have been any recent security incidents or alerts related to the user or the destination email address to identify potential compromise.\n- Consider disabling the forwarding rule temporarily and notifying the user and IT security team if the rule appears suspicious or unauthorized.\n\n### False positive analysis\n\n- Legitimate forwarding rules set by users for convenience or workflow purposes may trigger alerts. Review the context of the rule creation, such as the user and the destination address, to determine if it aligns with normal business operations.\n- Automated systems or third-party applications that integrate with Microsoft 365 might create forwarding rules as part of their functionality. Identify these systems and consider excluding their associated accounts from the rule.\n- Temporary forwarding rules set during user absence, such as vacations or leaves, can be mistaken for malicious activity. Implement a process to document and approve such rules, allowing for their exclusion from monitoring during the specified period.\n- Internal forwarding to trusted domains or addresses within the organization might not pose a security risk. Establish a list of trusted internal addresses and configure exceptions for these in the detection rule.\n- Frequent rule changes by specific users, such as IT administrators or support staff, may be part of their job responsibilities. Monitor these accounts separately and adjust the rule to reduce noise from expected behavior.\n\n### Response and remediation\n\n- Immediately disable the forwarding rule by accessing the affected user's mailbox settings in Microsoft 365 and removing any unauthorized forwarding rules.\n- Conduct a thorough review of the affected user's email account for any signs of compromise, such as unusual login activity or unauthorized changes to account settings.\n- Reset the password for the affected user's account and enforce multi-factor authentication (MFA) to prevent further unauthorized access.\n- Notify the user and relevant IT security personnel about the incident, providing details of the unauthorized rule and any potential data exposure.\n- Escalate the incident to the security operations team for further investigation and to determine if other accounts may have been targeted or compromised.\n- Implement additional monitoring on the affected account and similar high-risk accounts to detect any further suspicious activity or rule changes.\n- Review and update email security policies and configurations to prevent similar incidents, ensuring that forwarding rules are monitored and restricted as necessary.", - "query": "event.dataset:o365.audit and event.provider:Exchange and\nevent.category:web and event.action:(\"New-InboxRule\" or \"Set-InboxRule\") and\n (\n o365.audit.Parameters.ForwardTo:* or\n o365.audit.Parameters.ForwardAsAttachmentTo:* or\n o365.audit.Parameters.RedirectTo:*\n )\n and event.outcome:success\n", - "references": [ - "https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/responding-to-a-compromised-email-account?view=o365-worldwide", - "https://docs.microsoft.com/en-us/powershell/module/exchange/new-inboxrule?view=exchange-ps", - "https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/detect-and-remediate-outlook-rules-forms-attack?view=o365-worldwide", - "https://raw.githubusercontent.com/PwC-IR/Business-Email-Compromise-Guide/main/Extractor%20Cheat%20Sheet.pdf" - ], - "related_integrations": [ - { - "package": "o365", - "version": "^2.0.0" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "event.action", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.category", - "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.Parameters.ForwardAsAttachmentTo", - "type": "keyword" - }, - { - "ecs": false, - "name": "o365.audit.Parameters.ForwardTo", - "type": "keyword" - }, - { - "ecs": false, - "name": "o365.audit.Parameters.RedirectTo", - "type": "keyword" - } - ], - "risk_score": 47, - "rule_id": "ec8efb0c-604d-42fa-ac46-ed1cfbc38f78", - "setup": "The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.", - "severity": "medium", - "tags": [ - "Domain: Cloud", - "Data Source: Microsoft 365", - "Use Case: Configuration Audit", - "Tactic: Collection", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0009", - "name": "Collection", - "reference": "https://attack.mitre.org/tactics/TA0009/" - }, - "technique": [ - { - "id": "T1114", - "name": "Email Collection", - "reference": "https://attack.mitre.org/techniques/T1114/", - "subtechnique": [ - { - "id": "T1114.003", - "name": "Email Forwarding Rule", - "reference": "https://attack.mitre.org/techniques/T1114/003/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "query", - "version": 209 - }, - "id": "ec8efb0c-604d-42fa-ac46-ed1cfbc38f78_209", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/ef395dff-be12-4a6e-8919-d87d627c2174_4.json b/packages/security_detection_engine/kibana/security_rule/ef395dff-be12-4a6e-8919-d87d627c2174_4.json new file mode 100644 index 00000000000..632d7d8b301 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/ef395dff-be12-4a6e-8919-d87d627c2174_4.json @@ -0,0 +1,122 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects the use of SSH options that may indicate tunneling or port forwarding on Linux systems. This behavior is commonly associated with malicious activity, such as establishing a port forward, proxy or an encrypted tunnel to exfiltrate data.", + "from": "now-9m", + "index": [ + "endgame-*", + "logs-crowdstrike.fdr*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Potential Linux Tunneling and/or Port Forwarding via SSH Option", + "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 Linux Tunneling and/or Port Forwarding via SSH Option\n\nSSH is a secure protocol used for encrypted communication over networks, often employed for remote administration. Adversaries exploit SSH options like port forwarding to create tunnels, facilitating covert data exfiltration or unauthorized access. The detection rule identifies suspicious SSH commands indicative of tunneling by monitoring specific SSH options, helping to flag potential misuse for further investigation.\n\n### Possible investigation steps\n\n- Review the process command line details to identify the specific SSH options used, such as ProxyCommand, LocalForward, RemoteForward, DynamicForward, Tunnel, GatewayPorts, ExitOnForwardFailure, or ProxyJump, to understand the nature of the potential tunneling or port forwarding.\n- Examine the user account associated with the SSH process to determine if the activity aligns with their typical behavior or if it appears suspicious.\n- Check the source and destination IP addresses involved in the SSH connection to identify any unusual or unauthorized endpoints that may indicate malicious activity.\n- Investigate the timing and frequency of the SSH connections to assess whether they coincide with known business operations or if they suggest unauthorized access patterns.\n- Correlate the event with other security logs or alerts from the same host or network segment to identify any additional indicators of compromise or related suspicious activities.\n\n### False positive analysis\n\n- Legitimate administrative tasks using SSH options like ProxyCommand or LocalForward can trigger the rule. To manage this, create exceptions for known administrative scripts or users frequently using these options for valid purposes.\n- Automated backup or synchronization processes that use SSH tunneling for secure data transfer may be flagged. Identify these processes and exclude them by specifying the associated process names or user accounts.\n- Development or testing environments where developers use SSH tunneling for accessing remote services might cause alerts. Implement exceptions for specific IP addresses or user groups associated with these environments.\n- Monitoring or logging tools that utilize SSH for secure data collection can be mistaken for malicious activity. Whitelist these tools by their process names or command-line patterns to prevent false positives.\n- Internal network services that rely on SSH port forwarding for legitimate communication should be reviewed and excluded based on their known behavior and usage patterns.\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 SSH sessions identified by the detection rule to halt potential tunneling or port forwarding activities.\n- Conduct a thorough review of SSH configuration files and logs on the affected system to identify unauthorized changes or access patterns.\n- Reset credentials for any accounts that were used in the suspicious SSH activity to prevent further unauthorized access.\n- Implement network segmentation to limit SSH access to only necessary systems and services, reducing the risk of lateral movement.\n- Escalate the incident to the security operations team for further investigation and to determine if additional systems are compromised.\n- Enhance monitoring and logging of SSH activities across the network to detect similar threats in the future, ensuring alerts are promptly reviewed and acted upon.\n", + "query": "process where host.os.type == \"linux\" and event.type == \"start\" and event.action in (\"exec\", \"exec_event\", \"start\", \"ProcessRollup2\") and\nprocess.name in (\"ssh\", \"sshd\") and process.args like \"-o*\" and\nprocess.command_line like~ (\n \"*ProxyCommand*\", \"*LocalForward*\", \"*RemoteForward*\", \"*DynamicForward*\", \"*Tunnel*\", \"*GatewayPorts*\",\n \"*ExitOnForwardFailure*\", \"*ProxyCommand*\", \"*ProxyJump*\"\n) and \nnot (\n ?process.parent.args == \"/usr/bin/pvedaemon\" or\n ?process.parent.command_line in (\"pvedaemon\", \"pve-ha-lrm\") or\n ?process.working_directory like \"*ansible*\" or\n process.command_line like \"*ansible*\"\n)\n", + "references": [ + "https://blog.bitsadmin.com/living-off-the-foreign-land-windows-as-offensive-platform", + "https://book.hacktricks.xyz/generic-methodologies-and-resources/tunneling-and-port-forwarding" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "crowdstrike", + "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.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.working_directory", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "ef395dff-be12-4a6e-8919-d87d627c2174", + "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- Enter a name for the agent policy in \"New agent policy name\". If other agent policies already exist, you can click the \"Existing hosts\" tab and select an existing policy instead.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- To complete the integration, select \"Add Elastic Agent to your hosts\" and continue to the next section to install the Elastic Agent on your hosts.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Command and Control", + "Data Source: Elastic Defend", + "Data Source: Elastic Endgame", + "Data Source: Crowdstrike", + "Data Source: SentinelOne", + "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": 4 + }, + "id": "ef395dff-be12-4a6e-8919-d87d627c2174_4", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/f06414a6-f2a4-466d-8eba-10f85e8abf71_413.json b/packages/security_detection_engine/kibana/security_rule/f06414a6-f2a4-466d-8eba-10f85e8abf71_413.json new file mode 100644 index 00000000000..fd4a12f1a83 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/f06414a6-f2a4-466d-8eba-10f85e8abf71_413.json @@ -0,0 +1,85 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies when an administrator role is assigned to an Okta user or group. Adversaries may assign administrator privileges to compromised accounts to establish persistence, escalate privileges, and maintain long-term access to the environment. This detection monitors for both user-level and group-level administrator privilege grants, which can be used to bypass security controls and perform unauthorized administrative actions.", + "false_positives": [ + "Administrator roles may be assigned to Okta users or groups by authorized Super Admin users during normal IT operations such as onboarding, role changes, or organizational restructuring. Verify that the behavior was expected and authorized. Exceptions can be added to this rule to filter known administrators, service accounts, or automated provisioning systems." + ], + "index": [ + "logs-okta*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "Okta User Assigned Administrator Role", + "note": "## Triage and analysis\n\n### Investigating Okta User Assigned Administrator Role\n\nOkta administrator roles provide elevated permissions to manage users, applications, policies, and security settings within the Okta environment. Adversaries who compromise Okta accounts may assign administrator privileges to establish persistence and maintain control over the identity infrastructure. This rule detects when administrator roles are granted to users or groups, which can indicate privilege escalation or persistence techniques.\n\n#### Possible investigation steps:\n- Identify the actor who performed the privilege grant by examining the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, and `okta.actor.display_name` fields.\n- Determine the target user or group that received administrator privileges by reviewing the `okta.target` fields.\n- Review the specific administrator role granted by examining the `okta.debug_context.debug_data.flattened.privilegeGranted` field.\n- Determine the client used by the actor. Review the `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.zone`, `okta.client.device`, and `okta.client.id` fields.\n- Check if the source IP is associated with known malicious activity, VPN/proxy services, or unusual geolocations.\n- Examine the `okta.request.ip_chain` field to determine if the actor used a proxy or VPN.\n- Review the actor's recent authentication history and session activity for suspicious patterns.\n- Verify whether the privilege grant was part of a legitimate change request or administrative workflow.\n- Check for any other suspicious activities performed by the actor or target account around the same time.\n- Review audit logs for any administrative actions performed after the privilege grant.\n\n### False positive analysis:\n- Legitimate administrators may assign roles during normal IT operations such as onboarding, role changes, or incident response.\n- Automated provisioning systems or service accounts may assign administrator roles as part of authorized workflows.\n- During organizational changes or access certification processes, multiple role assignments may occur.\n- Create exceptions for known administrators, service accounts, or specific groups that regularly perform legitimate role assignments.\n\n### Response and remediation:\n- If the privilege grant is unauthorized, immediately revoke the administrator role from the affected user or group.\n- Reset credentials and revoke active sessions for both the actor and target accounts if compromise is suspected.\n- Enforce multi-factor authentication (MFA) re-enrollment for affected accounts.\n- Review all administrative actions performed by the target account after the privilege grant.\n- Check for other indicators of compromise such as unauthorized MFA device registrations, policy modifications, or suspicious authentication patterns.\n- Alert security leadership and identity management teams about the unauthorized privilege escalation.\n- Review and strengthen privileged access management controls, including requiring approval workflows for administrator role assignments.\n- Consider implementing anomaly detection for administrator role assignments from unusual sources or at unusual times.\n- If broader compromise is suspected, conduct a comprehensive security investigation including forensic analysis of Okta audit logs.\n", + "query": "event.dataset:okta.system\n and event.action: (user.account.privilege.grant or group.privilege.grant)\n and okta.debug_context.debug_data.flattened.privilegeGranted: *administrator*\n", + "references": [ + "https://help.okta.com/en/prod/Content/Topics/Security/administrators-admin-comparison.htm", + "https://developer.okta.com/docs/reference/api/system-log/", + "https://developer.okta.com/docs/reference/api/event-types/", + "https://cloud.google.com/blog/topics/threat-intelligence/expansion-shinyhunters-saas-data-theft", + "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy", + "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security", + "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta", + "https://www.elastic.co/security-labs/okta-and-lapsus-what-you-need-to-know" + ], + "related_integrations": [ + { + "package": "okta", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": false, + "name": "okta.debug_context.debug_data.flattened.privilegeGranted", + "type": "unknown" + } + ], + "risk_score": 47, + "rule_id": "f06414a6-f2a4-466d-8eba-10f85e8abf71", + "severity": "medium", + "tags": [ + "Domain: Identity", + "Data Source: Okta", + "Data Source: Okta System 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/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 413 + }, + "id": "f06414a6-f2a4-466d-8eba-10f85e8abf71_413", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/f0dbff4c-1aa7-4458-9ed5-ada472f64970_3.json b/packages/security_detection_engine/kibana/security_rule/f0dbff4c-1aa7-4458-9ed5-ada472f64970_3.json new file mode 100644 index 00000000000..e6116ce0209 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/f0dbff4c-1aa7-4458-9ed5-ada472f64970_3.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-7d", + "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": 3 + }, + "id": "f0dbff4c-1aa7-4458-9ed5-ada472f64970_3", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/f37f3054-d40b-49ac-aa9b-a786c74c58b8_105.json b/packages/security_detection_engine/kibana/security_rule/f37f3054-d40b-49ac-aa9b-a786c74c58b8_105.json deleted file mode 100644 index 02970551cc9..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/f37f3054-d40b-49ac-aa9b-a786c74c58b8_105.json +++ /dev/null @@ -1,96 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies the attempted use of a heap-based buffer overflow vulnerability for the Sudo binary in Unix-like systems (CVE-2021-3156). Successful exploitation allows an unprivileged user to escalate to the root user.", - "false_positives": [ - "This rule could generate false positives if the process arguments leveraged by the exploit are shared by custom scripts using the Sudo or Sudoedit binaries. Only Sudo versions 1.8.2 through 1.8.31p2 and 1.9.0 through 1.9.5p1 are affected; if those versions are not present on the endpoint, this could be a false positive." - ], - "from": "now-9m", - "index": [ - "auditbeat-*", - "logs-endpoint.events.*" - ], - "language": "kuery", - "license": "Elastic License v2", - "name": "Sudo Heap-Based Buffer Overflow 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 Sudo Heap-Based Buffer Overflow Attempt\n\nSudo is a critical utility in Unix-like systems, allowing users to execute commands with elevated privileges. A heap-based buffer overflow in Sudo (CVE-2021-3156) can be exploited by attackers to gain root access. Adversaries may craft specific command-line arguments to trigger this vulnerability. The detection rule identifies suspicious Sudo or Sudoedit invocations with particular argument patterns, signaling potential exploitation attempts.\n\n### Possible investigation steps\n\n- Review the alert details to confirm the presence of suspicious Sudo or Sudoedit invocations with the specific argument patterns: process.args containing a backslash followed by either \"-i\" or \"-s\".\n- Examine the process execution context by gathering additional details such as the user account associated with the process, the parent process, and the command line used.\n- Check the system logs for any other unusual or unauthorized activities around the time of the alert to identify potential lateral movement or further exploitation attempts.\n- Investigate the history of the user account involved to determine if there have been any previous suspicious activities or privilege escalation attempts.\n- Assess the system for any signs of compromise or unauthorized changes, such as new user accounts, modified files, or unexpected network connections.\n- Verify the current version of Sudo installed on the system to determine if it is vulnerable to CVE-2021-3156 and consider applying patches or updates if necessary.\n\n### False positive analysis\n\n- Routine administrative tasks using sudo or sudoedit with interactive or shell options may trigger the rule. Review the context of these commands and consider excluding specific user accounts or scripts that are known to perform legitimate administrative functions.\n- Automated scripts or cron jobs that use sudo with the -i or -s options for legitimate purposes can be flagged. Identify these scripts and add them to an exception list to prevent unnecessary alerts.\n- Development or testing environments where users frequently test commands with elevated privileges might generate false positives. Implement a separate monitoring policy for these environments or exclude known test accounts.\n- Security tools or monitoring solutions that simulate attacks for testing purposes may inadvertently trigger the rule. Ensure these tools are recognized and excluded from triggering alerts by adding them to an exception list.\n- Users with legitimate reasons to frequently switch to root using sudo -i or sudo -s should be identified, and their activities should be monitored separately to avoid false positives.\n\n### Response and remediation\n\n- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the attacker.\n- Terminate any suspicious sudo or sudoedit processes identified by the detection rule to halt ongoing exploitation attempts.\n- Apply the latest security patches and updates to the Sudo utility on all affected systems to remediate the vulnerability (CVE-2021-3156).\n- Conduct a thorough review of system logs and process execution history to identify any unauthorized access or privilege escalation activities.\n- Reset passwords for all user accounts on the affected system, especially those with elevated privileges, to mitigate potential credential compromise.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the scope of the breach.\n- Implement enhanced monitoring and alerting for sudo and sudoedit command executions across the network to detect similar exploitation attempts in the future.", - "query": "event.category:process and event.type:start and\n process.name:(sudo or sudoedit) and\n process.args:(*\\\\ and (\"-i\" or \"-s\"))\n", - "references": [ - "https://cve.mitre.org/cgi-bin/cvename.cgi?name=2021-3156", - "https://blog.qualys.com/vulnerabilities-research/2021/01/26/cve-2021-3156-heap-based-buffer-overflow-in-sudo-baron-samedit", - "https://www.bleepingcomputer.com/news/security/latest-macos-big-sur-also-has-sudo-root-privilege-escalation-flaw", - "https://www.sudo.ws/alerts/unescape_overflow.html" - ], - "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": "process.args", - "type": "keyword" - }, - { - "ecs": true, - "name": "process.name", - "type": "keyword" - } - ], - "risk_score": 73, - "rule_id": "f37f3054-d40b-49ac-aa9b-a786c74c58b8", - "severity": "high", - "tags": [ - "Domain: Endpoint", - "OS: Linux", - "OS: macOS", - "Use Case: Threat Detection", - "Tactic: Privilege Escalation", - "Use Case: Vulnerability", - "Data Source: Elastic Defend", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0004", - "name": "Privilege Escalation", - "reference": "https://attack.mitre.org/tactics/TA0004/" - }, - "technique": [ - { - "id": "T1068", - "name": "Exploitation for Privilege Escalation", - "reference": "https://attack.mitre.org/techniques/T1068/" - } - ] - } - ], - "threshold": { - "field": [ - "host.hostname" - ], - "value": 100 - }, - "timestamp_override": "event.ingested", - "type": "threshold", - "version": 105 - }, - "id": "f37f3054-d40b-49ac-aa9b-a786c74c58b8_105", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/f38633f4-3b31-4c80-b13d-e77c70ce8254_5.json b/packages/security_detection_engine/kibana/security_rule/f38633f4-3b31-4c80-b13d-e77c70ce8254_5.json deleted file mode 100644 index abba6fbfd81..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/f38633f4-3b31-4c80-b13d-e77c70ce8254_5.json +++ /dev/null @@ -1,133 +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,\n// match will ignore the | and look for the individual words\n| where powershell.file.script_block_text : \"rahc|metsys|stekcos|tcejboimw|ecalper|ecnerferpe|noitcennoc|nioj|eman|vne|gnirts|tcejbo-wen|_23niw|noisserpxe|ekovni|daolnwod\"\n\n// replace the patterns we are looking for with the \ud83d\udd25 emoji to enable counting them\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| eval Esql.script_block_tmp = replace(\n powershell.file.script_block_text,\n \"\"\"(?i)(rahc|metsys|stekcos|tcejboimw|ecalper|ecnerferpe|noitcennoc|nioj|eman\\.|:vne$|gnirts|tcejbo-wen|_23niw|noisserpxe|ekovni|daolnwod)\"\"\",\n \"\ud83d\udd25\"\n)\n\n// count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| eval Esql.script_block_pattern_count = length(Esql.script_block_tmp) - length(replace(Esql.script_block_tmp, \"\ud83d\udd25\", \"\"))\n\n// keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| keep\n Esql.script_block_pattern_count,\n Esql.script_block_tmp,\n powershell.file.script_block_text,\n powershell.file.script_block_id,\n file.path,\n powershell.sequence,\n powershell.total,\n _id,\n _index,\n agent.id\n\n// Filter for scripts that match the pattern at least twice\n| where Esql.script_block_pattern_count >= 2\n", - "related_integrations": [ - { - "package": "windows", - "version": "^3.0.0" - } - ], - "required_fields": [ - { - "ecs": false, - "name": "Esql.script_block_pattern_count", - "type": "integer" - }, - { - "ecs": false, - "name": "Esql.script_block_tmp", - "type": "keyword" - }, - { - "ecs": false, - "name": "_id", - "type": "keyword" - }, - { - "ecs": false, - "name": "_index", - "type": "keyword" - }, - { - "ecs": true, - "name": "agent.id", - "type": "keyword" - }, - { - "ecs": true, - "name": "file.path", - "type": "keyword" - }, - { - "ecs": false, - "name": "powershell.file.script_block_id", - "type": "keyword" - }, - { - "ecs": false, - "name": "powershell.file.script_block_text", - "type": "text" - }, - { - "ecs": false, - "name": "powershell.sequence", - "type": "long" - }, - { - "ecs": false, - "name": "powershell.total", - "type": "long" - } - ], - "risk_score": 21, - "rule_id": "f38633f4-3b31-4c80-b13d-e77c70ce8254", - "setup": "## Setup\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nAdministrative Templates >\nWindows PowerShell >\nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n", - "severity": "low", - "tags": [ - "Domain: Endpoint", - "OS: Windows", - "Use Case: Threat Detection", - "Tactic: Defense Evasion", - "Data Source: PowerShell Logs", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0005", - "name": "Defense Evasion", - "reference": "https://attack.mitre.org/tactics/TA0005/" - }, - "technique": [ - { - "id": "T1027", - "name": "Obfuscated Files or Information", - "reference": "https://attack.mitre.org/techniques/T1027/" - }, - { - "id": "T1140", - "name": "Deobfuscate/Decode Files or Information", - "reference": "https://attack.mitre.org/techniques/T1140/" - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0002", - "name": "Execution", - "reference": "https://attack.mitre.org/tactics/TA0002/" - }, - "technique": [ - { - "id": "T1059", - "name": "Command and Scripting Interpreter", - "reference": "https://attack.mitre.org/techniques/T1059/", - "subtechnique": [ - { - "id": "T1059.001", - "name": "PowerShell", - "reference": "https://attack.mitre.org/techniques/T1059/001/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 5 - }, - "id": "f38633f4-3b31-4c80-b13d-e77c70ce8254_5", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/f38633f4-3b31-4c80-b13d-e77c70ce8254_9.json b/packages/security_detection_engine/kibana/security_rule/f38633f4-3b31-4c80-b13d-e77c70ce8254_9.json new file mode 100644 index 00000000000..db25b1c6d4c --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/f38633f4-3b31-4c80-b13d-e77c70ce8254_9.json @@ -0,0 +1,202 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects PowerShell scripts containing reversed keyword strings associated with execution or network activity (for example, ekovni, noisserpxe, daolnwod, tcejbo-wen, tcejboimw, etc.). Attackers reverse keywords and reconstruct them at runtime to hide intent and evade static detection and AMSI.", + "from": "now-9m", + "investigation_fields": { + "field_names": [ + "@timestamp", + "user.name", + "user.id", + "user.domain", + "powershell.file.script_block_text", + "powershell.file.script_block_id", + "powershell.sequence", + "powershell.total", + "file.path", + "file.directory", + "file.name", + "process.pid", + "host.name", + "host.id", + "powershell.file.script_block_length" + ] + }, + "language": "esql", + "license": "Elastic License v2", + "name": "Potential PowerShell Obfuscation via Reverse Keywords", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This guide was created by humans with the assistance of generative AI. While its contents have been manually curated to include the most valuable information, always validate assumptions and adjust procedures to match your internal runbooks and incident triage and response policies.\n\n### Investigating Potential PowerShell Obfuscation via Reverse Keywords\n\nThis alert indicates PowerShell script block content contains multiple reversed keyword strings commonly associated with execution, string manipulation, environment discovery, or networking. Reversing strings is frequently paired with runtime reconstruction (for example, reversing character arrays or joining string fragments) to reduce readability and evade simple content inspection.\n\nDetermine whether the script is part of expected administrative automation, software tooling, or an unauthorized execution chain. Prioritize analysis that reconstructs the full script, deobfuscates the reversed tokens, and identifies any follow-on behaviors such as dynamic execution, network access, or system discovery.\n\n#### Key alert fields to review\n\n- `user.name`, `user.domain`, `user.id`: Account execution context for correlation, prioritization, and scoping.\n- `host.name`, `host.id`: Host execution context for correlation, prioritization, and scoping.\n- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file.\n- `powershell.file.script_block_text`: Script block content that matched the detection logic.\n- `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`: Script block metadata to pivot to other fragments or reconstruct full script content when split across multiple events.\n- `Esql.script_block_tmp`: Transformed script block where detection patterns replace original content with a marker to support scoring/counting and quickly spot match locations.\n- `Esql.script_block_pattern_count`: Count of matches for the detection pattern(s) observed in the script block content.\n- `powershell.file.script_block_entropy_bits`: Shannon entropy of the script block. Higher values may indicate obfuscation.\n- `powershell.file.script_block_surprisal_stdev`: Standard deviation of surprisal across the script block. Low values indicate uniform randomness. High values indicate mixed patterns and variability.\n- `powershell.file.script_block_unique_symbols`: Count of distinct characters present in the script block.\n- `powershell.file.script_block_length`: Script block length (size) context.\n\n#### Possible investigation steps\n\n- Identify the execution scope and ownership:\n - Review `host.name` / `host.id` to confirm the affected endpoint and its criticality.\n - Review `user.id` (and `user.name` / `user.domain` if available) to understand the account context and whether this user is expected to run PowerShell on this host.\n- Prioritize based on obfuscation signals:\n - Review `Esql.script_block_pattern_count`; higher counts suggest more extensive keyword hiding and can increase suspicion.\n - Use `powershell.file.script_block_length`, `powershell.file.script_block_entropy_bits`, `powershell.file.script_block_unique_symbols`, and `powershell.file.script_block_surprisal_stdev` to gauge how heavily obfuscated or machine-generated the content may be (treat these as supporting context, not proof of maliciousness).\n- Reconstruct the full script content when split:\n - If `powershell.total` is greater than 1, retrieve all events with the same `powershell.file.script_block_id` and order them by `powershell.sequence` to rebuild the complete script block content.\n - Preserve both the reconstructed script and the original per-event `powershell.file.script_block_text` to maintain context and ordering.\n- Deobfuscate and interpret intent:\n - Review `powershell.file.script_block_text` for reversed tokens and reverse them to identify the intended keywords and operations (for example, indicators of dynamic execution, downloads, socket/connection handling, WMI usage, or Win32 references).\n - Look for runtime string reconstruction patterns in the script content (for example, joins, character array operations, or replace operations) that turn reversed fragments into executable commands or parameters.\n - Use `Esql.script_block_tmp` to quickly locate the matched areas, then validate findings against `powershell.file.script_block_text`.\n- Evaluate file-origin context (when present):\n - Review `file.path` (and `file.directory` / `file.name` if available) to determine whether the script is associated with an on-disk file and whether that location aligns with your organization's expected script locations and deployment practices.\n - If an on-disk script is indicated, coordinate collection of the referenced file for offline analysis and determine whether it is present on other systems.\n- Extract and operationalize indicators:\n - From `powershell.file.script_block_text`, extract any embedded indicators such as hostnames, IP addresses, URLs, ports, file paths, or encoded blobs.\n - Use extracted indicators to scope for related activity on the same `host.id` and across other hosts where the same `user.id` is active, focusing on the alert timeframe and immediately adjacent activity.\n- Correlate with adjacent telemetry to identify the execution chain and impact (as available in your environment):\n - Process activity: identify the PowerShell host process and the initiating parent process to understand whether execution was interactive, scheduled, or launched by another program.\n - Network activity: look for outbound connections aligned with the alert timestamp, especially if deobfuscated content suggests downloads or socket connections.\n - File and registry activity: look for payload staging, new or modified files, or persistence-related changes that occur shortly after the script block execution.\n - Authentication activity: review for suspicious logons, remote session creation, or lateral movement attempts around the same time on the affected host.\n- Determine severity and next actions:\n - If the deobfuscated content indicates remote retrieval, execution of downloaded content, credential access, persistence, or lateral movement, treat the alert as potentially malicious and escalate for response.\n - If the script appears benign, document the validated purpose, expected owner, and any recurring identifiers (such as file location patterns) to support future triage.\n\n### False positive analysis\n\n- Internal scripts or tooling may use reversed strings as lightweight obfuscation to conceal configuration values or reduce casual readability. Validate the script's ownership, change history, and whether its presence and execution timing are expected for `host.id` and `user.id`.\n- Commercial software, endpoint management agents, or security tooling may generate or embed obfuscated PowerShell during installation, updates, or health checks. Validate whether the activity aligns with known maintenance windows, expected endpoints, and consistent script content and `file.path` patterns.\n- Authorized security testing may intentionally use string reversal. Confirm the scope, timing, and target hosts with the appropriate stakeholders before closing the alert.\n\n### Response and remediation\n\n- If activity is suspicious or unauthorized, contain the affected host to prevent further script execution and potential follow-on actions.\n- Preserve evidence:\n - Retain the full `powershell.file.script_block_text` (including all segments reconstructed via `powershell.file.script_block_id`, `powershell.sequence`, and `powershell.total`).\n - Retain `file.path` context and the alert metadata needed to pivot (such as `host.id` and `user.id`).\n- Identify and remediate the execution source:\n - Determine how PowerShell was launched (interactive, scheduled, or by another process) using correlated telemetry, and remove the triggering mechanism.\n - If an on-disk script is involved, remediate the file at `file.path` and any associated payloads or artifacts identified during analysis.\n- Scope and hunt:\n - Search for the same or similar obfuscated content and extracted indicators across other endpoints, prioritizing systems accessed by the same `user.id` and systems with similar `file.path` patterns.\n- Account actions:\n - If account misuse is suspected, follow organizational procedures to contain the account (for example, credential reset and session revocation) and review recent activity for additional suspicious behavior.\n- Recovery and hardening:\n - Verify PowerShell logging coverage and retention are sufficient for incident response, and monitor for recurrence of similar reversed-keyword patterns on affected hosts and users.\n", + "query": "from logs-windows.powershell_operational* metadata _id, _version, _index\n| where event.code == \"4104\"\n\n// Filter for scripts that contains these keywords using MATCH, boosts the query performance,\n// match will ignore the | and look for the individual words\n| where powershell.file.script_block_text : \"rahc|metsys|stekcos|tcejboimw|ecalper|ecnerferpe|noitcennoc|nioj|eman|vne|gnirts|tcejbo-wen|_23niw|noisserpxe|ekovni|daolnwod\"\n\n// replace the patterns we are looking for with the \ud83d\udd25 emoji to enable counting them\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| eval Esql.script_block_tmp = replace(\n powershell.file.script_block_text,\n \"\"\"(?i)(rahc|metsys|stekcos|tcejboimw|ecalper|ecnerferpe|noitcennoc|nioj|eman\\.|:vne$|gnirts|tcejbo-wen|_23niw|noisserpxe|ekovni|daolnwod)\"\"\",\n \"\ud83d\udd25\"\n)\n\n// count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| eval Esql.script_block_pattern_count = length(Esql.script_block_tmp) - length(replace(Esql.script_block_tmp, \"\ud83d\udd25\", \"\"))\n\n// keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| keep\n Esql.script_block_pattern_count,\n Esql.script_block_tmp,\n powershell.file.*,\n file.path,\n powershell.sequence,\n powershell.total,\n _id,\n _version,\n _index,\n host.name,\n host.id,\n agent.id,\n user.id\n\n// Filter for scripts that match the pattern at least twice\n| where Esql.script_block_pattern_count >= 2\n", + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.script_block_pattern_count", + "type": "integer" + }, + { + "ecs": false, + "name": "Esql.script_block_tmp", + "type": "keyword" + }, + { + "ecs": false, + "name": "_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "_index", + "type": "keyword" + }, + { + "ecs": false, + "name": "_version", + "type": "long" + }, + { + "ecs": true, + "name": "agent.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.path", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.name", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_entropy_bits", + "type": "double" + }, + { + "ecs": false, + "name": "powershell.file.script_block_entropy_normalized", + "type": "double" + }, + { + "ecs": false, + "name": "powershell.file.script_block_hash", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_length", + "type": "long" + }, + { + "ecs": false, + "name": "powershell.file.script_block_surprisal_stdev", + "type": "double" + }, + { + "ecs": false, + "name": "powershell.file.script_block_text", + "type": "text" + }, + { + "ecs": false, + "name": "powershell.file.script_block_unique_symbols", + "type": "long" + }, + { + "ecs": false, + "name": "powershell.sequence", + "type": "long" + }, + { + "ecs": false, + "name": "powershell.total", + "type": "long" + }, + { + "ecs": true, + "name": "user.id", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "f38633f4-3b31-4c80-b13d-e77c70ce8254", + "setup": "## Setup\n\nPowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104).\nSetup instructions: https://ela.st/powershell-logging-setup\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": 9 + }, + "id": "f38633f4-3b31-4c80-b13d-e77c70ce8254_9", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/f6d8c743-0916-4483-8333-3c6f107e0caa_5.json b/packages/security_detection_engine/kibana/security_rule/f6d8c743-0916-4483-8333-3c6f107e0caa_5.json deleted file mode 100644 index 7b22198fde7..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/f6d8c743-0916-4483-8333-3c6f107e0caa_5.json +++ /dev/null @@ -1,148 +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", - "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.\n\n### Investigating Potential PowerShell Obfuscation via String Concatenation\n\nPowerShell is a powerful scripting language used for task automation and configuration management. Adversaries exploit its flexibility to obfuscate malicious scripts, often using string concatenation to evade detection. The detection rule identifies scripts with excessive concatenation patterns, flagging potential obfuscation by analyzing script length and pattern frequency, thus aiding in uncovering hidden threats.\n\n### Possible investigation steps\n\n- Review the powershell.file.script_block_text field to understand the content and purpose of the script, focusing on the sections identified by the string concatenation patterns.\n- Examine the file.path field to determine the location of the script on the host system, which can provide context about its origin and potential legitimacy.\n- Check the host.name and agent.id fields to identify the affected system and correlate with other security events or alerts from the same host for broader context.\n- Investigate the user.id field to determine which user executed the script, assessing their role and whether they have a legitimate reason to run such scripts.\n- Analyze the powershell.file.script_block_id and powershell.sequence fields to trace the execution flow and sequence of the script blocks, which may reveal additional obfuscation or malicious behavior.\n- Cross-reference the _id and _index fields with other logs or alerts to identify any related incidents or patterns of activity that might indicate a larger threat campaign.\n\n### False positive analysis\n\n- Scripts with legitimate string concatenation for logging or configuration purposes may trigger the rule. Review the script context to determine if the concatenation is part of a benign operation.\n- Automated scripts generated by development tools might use string concatenation extensively. Identify these tools and consider excluding their output directories or specific script patterns from the rule.\n- PowerShell scripts used in complex data processing tasks may naturally contain high levels of string concatenation. Analyze the script's purpose and, if deemed safe, add exceptions for specific script block IDs or paths.\n- Frequent administrative scripts that concatenate strings for dynamic command execution could be flagged. Verify the script's source and function, then whitelist known safe scripts by user ID or host name.\n- Consider adjusting the threshold for pattern detection if legitimate scripts frequently exceed the current limit, ensuring that the rule remains effective without generating excessive false positives.\n\n### Response and remediation\n\n- Isolate the affected host immediately to prevent further spread of potentially malicious scripts across the network. Disconnect it from the network and any shared resources.\n- Terminate any suspicious PowerShell processes identified by the alert to halt the execution of potentially obfuscated scripts.\n- Conduct a thorough examination of the script block text and associated files to identify and remove any malicious code or artifacts. Use a secure, isolated environment for analysis.\n- Restore the affected system from a known good backup if malicious activity is confirmed and cannot be easily remediated.\n- Update and run a full antivirus and antimalware scan on the affected system to ensure no additional threats are present.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised.\n- Implement enhanced monitoring and logging for PowerShell activities across the network to detect similar obfuscation attempts in the future, ensuring that alerts are configured to notify the appropriate personnel promptly.\n", - "query": "from logs-windows.powershell_operational* metadata _id, _version, _index\n| where event.code == \"4104\"\n\n// Filter out smaller scripts that are unlikely to implement obfuscation using the patterns we are looking for\n| eval Esql.script_block_length = length(powershell.file.script_block_text)\n| where Esql.script_block_length > 500\n\n// replace the patterns we are looking for with the \ud83d\udd25 emoji to enable counting them\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| eval Esql.script_block_tmp = replace(\n powershell.file.script_block_text,\n \"\"\"['\"][A-Za-z0-9.]+['\"](\\s?\\+\\s?['\"][A-Za-z0-9.,\\-\\s]+['\"]){2,}\"\"\",\n \"\ud83d\udd25\"\n)\n\n// count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| eval Esql.script_block_pattern_count = length(Esql.script_block_tmp) - length(replace(Esql.script_block_tmp, \"\ud83d\udd25\", \"\"))\n\n// keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| keep\n Esql.script_block_pattern_count,\n Esql.script_block_length,\n Esql.script_block_tmp,\n powershell.file.script_block_text,\n powershell.file.script_block_id,\n file.path,\n powershell.sequence,\n powershell.total,\n _id,\n _index,\n host.name,\n agent.id,\n user.id\n\n// Filter for scripts that match the pattern at least twice\n| where Esql.script_block_pattern_count >= 2\n", - "related_integrations": [ - { - "package": "windows", - "version": "^3.0.0" - } - ], - "required_fields": [ - { - "ecs": false, - "name": "Esql.script_block_length", - "type": "integer" - }, - { - "ecs": false, - "name": "Esql.script_block_pattern_count", - "type": "integer" - }, - { - "ecs": false, - "name": "Esql.script_block_tmp", - "type": "keyword" - }, - { - "ecs": false, - "name": "_id", - "type": "keyword" - }, - { - "ecs": false, - "name": "_index", - "type": "keyword" - }, - { - "ecs": true, - "name": "agent.id", - "type": "keyword" - }, - { - "ecs": true, - "name": "file.path", - "type": "keyword" - }, - { - "ecs": true, - "name": "host.name", - "type": "keyword" - }, - { - "ecs": false, - "name": "powershell.file.script_block_id", - "type": "keyword" - }, - { - "ecs": false, - "name": "powershell.file.script_block_text", - "type": "text" - }, - { - "ecs": false, - "name": "powershell.sequence", - "type": "long" - }, - { - "ecs": false, - "name": "powershell.total", - "type": "long" - }, - { - "ecs": true, - "name": "user.id", - "type": "keyword" - } - ], - "risk_score": 47, - "rule_id": "f6d8c743-0916-4483-8333-3c6f107e0caa", - "setup": "## Setup\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nAdministrative Templates >\nWindows PowerShell >\nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n", - "severity": "medium", - "tags": [ - "Domain: Endpoint", - "OS: Windows", - "Use Case: Threat Detection", - "Tactic: Defense Evasion", - "Data Source: PowerShell Logs", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0005", - "name": "Defense Evasion", - "reference": "https://attack.mitre.org/tactics/TA0005/" - }, - "technique": [ - { - "id": "T1027", - "name": "Obfuscated Files or Information", - "reference": "https://attack.mitre.org/techniques/T1027/" - }, - { - "id": "T1140", - "name": "Deobfuscate/Decode Files or Information", - "reference": "https://attack.mitre.org/techniques/T1140/" - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0002", - "name": "Execution", - "reference": "https://attack.mitre.org/tactics/TA0002/" - }, - "technique": [ - { - "id": "T1059", - "name": "Command and Scripting Interpreter", - "reference": "https://attack.mitre.org/techniques/T1059/", - "subtechnique": [ - { - "id": "T1059.001", - "name": "PowerShell", - "reference": "https://attack.mitre.org/techniques/T1059/001/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 5 - }, - "id": "f6d8c743-0916-4483-8333-3c6f107e0caa_5", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/f6d8c743-0916-4483-8333-3c6f107e0caa_9.json b/packages/security_detection_engine/kibana/security_rule/f6d8c743-0916-4483-8333-3c6f107e0caa_9.json new file mode 100644 index 00000000000..1e4b05c83be --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/f6d8c743-0916-4483-8333-3c6f107e0caa_9.json @@ -0,0 +1,207 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects PowerShell scripts that repeatedly concatenates multiple quoted string literals with + to assemble commands or tokens at runtime. Attackers use string concatenation to fragment keywords or URLs and evade static analysis and AMSI.", + "from": "now-9m", + "investigation_fields": { + "field_names": [ + "@timestamp", + "user.name", + "user.id", + "user.domain", + "powershell.file.script_block_text", + "powershell.file.script_block_id", + "powershell.sequence", + "powershell.total", + "file.path", + "file.directory", + "file.name", + "process.pid", + "host.name", + "host.id", + "powershell.file.script_block_length" + ] + }, + "language": "esql", + "license": "Elastic License v2", + "name": "Potential PowerShell Obfuscation via String Concatenation", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This guide was created by humans with the assistance of generative AI. While its contents have been manually curated to include the most valuable information, always validate assumptions and adjust procedures to match your internal runbooks and incident triage and response policies.\n\n### Investigating Potential PowerShell Obfuscation via String Concatenation\n\nThis rule identifies PowerShell script block content that uses repeated concatenation of quoted string literals. This technique is commonly used to fragment keywords, URLs, and command text so they are assembled only at runtime. Focus the investigation on reconstructing the final strings, understanding how they are used within the script, and scoping related activity from the same host and user.\n\n#### Key alert fields to review\n\n- `user.name`, `user.domain`, `user.id`: Account execution context for correlation, prioritization, and scoping.\n- `host.name`, `host.id`: Host execution context for correlation, prioritization, and scoping.\n- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file.\n- `powershell.file.script_block_text`: Script block content that matched the detection logic.\n- `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`: Script block metadata to pivot to other fragments or reconstruct full script content when split across multiple events.\n- `Esql.script_block_tmp`: Transformed script block where detection patterns replace original content with a marker to support scoring/counting and quickly spot match locations.\n- `Esql.script_block_pattern_count`: Count of matches for the detection pattern(s) observed in the script block content.\n- `powershell.file.script_block_entropy_bits`: Shannon entropy of the script block. Higher values may indicate obfuscation.\n- `powershell.file.script_block_surprisal_stdev`: Standard deviation of surprisal across the script block. Low values indicate uniform randomness. High values indicate mixed patterns and variability.\n- `powershell.file.script_block_unique_symbols`: Count of distinct characters present in the script block.\n- `powershell.file.script_block_length`: Script block length (size) context.\n\n#### Possible investigation steps\n\n- Establish alert context and prioritize review:\n - Review `host.name` / `host.id` and `user.name` / `user.domain` / `user.id` to understand where and under which account the script executed.\n - Use `Esql.script_block_pattern_count` to gauge how heavily the script relies on concatenation. Higher counts can indicate more deliberate obfuscation.\n - Review `powershell.file.script_block_length` and the statistical fields (`powershell.file.script_block_entropy_bits`, `powershell.file.script_block_surprisal_stdev`, `powershell.file.script_block_unique_symbols`) to assess whether the script contains high-variance or high-randomness content that may indicate encoding, packing, or layered obfuscation.\n\n- Identify the most likely script origin:\n - Review `file.path`, `file.directory`, and `file.name` (when present) to determine whether the script block content was sourced from an on-disk script. Note whether the location is expected for administrative tooling or is user-writable/unusual for the host role.\n - If file origin fields are not populated, treat the activity as potentially inline/interactive execution and prioritize identifying what initiated it through correlation with surrounding telemetry.\n\n- Recover the assembled strings and intent:\n - Start with `Esql.script_block_tmp` to find where concatenation patterns occur, then inspect the surrounding text in `powershell.file.script_block_text` for the full logic.\n - Reconstruct concatenated literals by joining the quoted fragments (preserving ordering and separators) to reveal the final keywords, paths, URLs, arguments, or identifiers the script is attempting to hide.\n - Look for how reconstructed strings are used, especially:\n - Dynamic invocation of reconstructed commands or expressions.\n - Download or retrieval of remote content.\n - Decoding/decryption routines and second-stage content handling.\n - Construction of file paths, scheduled execution artifacts, or configuration changes.\n - Capture any reconstructed indicators (domains, URLs, file names, directories, command fragments) that can be used to scope other activity.\n\n- Reconstruct full script content when split across events:\n - Pivot on `powershell.file.script_block_id` to collect related script block events from the same execution context.\n - If `powershell.total` is greater than 1, gather all fragments and order them by `powershell.sequence` to rebuild the complete script content before making a final determination.\n - Review whether additional script blocks were executed in close succession by the same `user.id` on the same `host.id`, which may indicate staging or multi-step execution.\n\n- Scope the activity across hosts and accounts:\n - On the same `host.id`, look for other script blocks that share the same `file.path` or distinctive reconstructed strings to determine if this is a single run or repeated behavior.\n - Pivot on `user.id` to identify the same technique on other endpoints, which can indicate credential misuse or automated distribution.\n\n- Correlate with adjacent telemetry (as available in your environment):\n - Process execution: identify the PowerShell host process and its parent process near the alert time to determine whether execution was interactive or spawned by another program.\n - Network activity: if reconstructed strings include URLs/domains, check for outbound connections, downloads, or callbacks that align with the alert timeframe.\n - Host changes: review nearby file and registry activity for payload drops, persistence creation, or configuration changes that match reconstructed paths or names.\n - Authentication: review recent logon activity for `user.id` and `host.id` for anomalies that may explain the execution (new logon source, unusual logon type, or unexpected access patterns).\n\n### False positive analysis\n\n- Legitimate administrative or operational scripts may concatenate many string literals to generate dynamic content (for example, configuration files, templated output, or complex argument strings). Validate whether the reconstructed strings align with expected internal tooling and whether the execution context (`host.id`, `user.id`, and `file.path`) matches normal operations.\n\n### Response and remediation\n\n- If malicious or suspicious activity is confirmed:\n - Contain the affected host to prevent follow-on execution or lateral movement.\n - Preserve evidence from the alert, including `powershell.file.script_block_text`, `powershell.file.script_block_id`, `powershell.sequence` / `powershell.total`, and any `file.path` details that indicate script origin.\n - Use reconstructed strings to scope across the environment for related script blocks and any referenced artifacts (additional scripts, payload files, or remote destinations).\n - Identify and remediate the initial execution vector by tracing the execution chain (user context and initiating process) and removing any persistence mechanisms discovered during investigation.\n - If account compromise is suspected, reset credentials for the affected `user.id`, review recent access patterns, and apply least-privilege controls to limit further abuse.\n\n- If the activity is determined to be benign:\n - Document the script purpose, expected execution context, and the specific concatenated strings that explain the detection.\n - Monitor for deviations from the established baseline (new hosts, new accounts, unexpected file paths, or substantially different reconstructed content).\n", + "query": "from logs-windows.powershell_operational* metadata _id, _version, _index\n| where event.code == \"4104\"\n\n// Filter out smaller scripts that are unlikely to implement obfuscation using the patterns we are looking for\n| eval Esql.script_block_length = length(powershell.file.script_block_text)\n| where Esql.script_block_length > 500\n\n// replace the patterns we are looking for with the \ud83d\udd25 emoji to enable counting them\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| eval Esql.script_block_tmp = replace(\n powershell.file.script_block_text,\n \"\"\"['\"][A-Za-z0-9.]+['\"](\\s?\\+\\s?['\"][A-Za-z0-9.,\\-\\s]+['\"]){2,}\"\"\",\n \"\ud83d\udd25\"\n)\n\n// count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| eval Esql.script_block_pattern_count = length(Esql.script_block_tmp) - length(replace(Esql.script_block_tmp, \"\ud83d\udd25\", \"\"))\n\n// keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| keep\n Esql.script_block_pattern_count,\n Esql.script_block_length,\n Esql.script_block_tmp,\n powershell.file.*,\n file.path,\n powershell.sequence,\n powershell.total,\n _id,\n _version,\n _index,\n host.name,\n host.id,\n agent.id,\n user.id\n\n// Filter for scripts that match the pattern at least twice\n| where Esql.script_block_pattern_count >= 2\n", + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.script_block_length", + "type": "integer" + }, + { + "ecs": false, + "name": "Esql.script_block_pattern_count", + "type": "integer" + }, + { + "ecs": false, + "name": "Esql.script_block_tmp", + "type": "keyword" + }, + { + "ecs": false, + "name": "_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "_index", + "type": "keyword" + }, + { + "ecs": false, + "name": "_version", + "type": "long" + }, + { + "ecs": true, + "name": "agent.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.path", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.name", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_entropy_bits", + "type": "double" + }, + { + "ecs": false, + "name": "powershell.file.script_block_entropy_normalized", + "type": "double" + }, + { + "ecs": false, + "name": "powershell.file.script_block_hash", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_length", + "type": "long" + }, + { + "ecs": false, + "name": "powershell.file.script_block_surprisal_stdev", + "type": "double" + }, + { + "ecs": false, + "name": "powershell.file.script_block_text", + "type": "text" + }, + { + "ecs": false, + "name": "powershell.file.script_block_unique_symbols", + "type": "long" + }, + { + "ecs": false, + "name": "powershell.sequence", + "type": "long" + }, + { + "ecs": false, + "name": "powershell.total", + "type": "long" + }, + { + "ecs": true, + "name": "user.id", + "type": "keyword" + } + ], + "risk_score": 73, + "rule_id": "f6d8c743-0916-4483-8333-3c6f107e0caa", + "setup": "## Setup\n\nPowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104).\nSetup instructions: https://ela.st/powershell-logging-setup\n", + "severity": "high", + "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": 9 + }, + "id": "f6d8c743-0916-4483-8333-3c6f107e0caa_9", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/f770ce79-05fd-4d74-9866-1c5d66c9b34b_4.json b/packages/security_detection_engine/kibana/security_rule/f770ce79-05fd-4d74-9866-1c5d66c9b34b_4.json new file mode 100644 index 00000000000..59458781f8a --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/f770ce79-05fd-4d74-9866-1c5d66c9b34b_4.json @@ -0,0 +1,84 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies PowerShell script blocks linked to multiple distinct PowerShell detections via the same ScriptBlock ID, indicating compound suspicious behavior. Attackers often chain obfuscation, decoding, and execution within a single script block.", + "from": "now-9m", + "investigation_fields": { + "field_names": [ + "Esql.script_block_id", + "Esql._id_values", + "Esql.kibana_alert_rule_name_values", + "Esql.kibana_alert_rule_name_count_distinct" + ] + }, + "language": "esql", + "license": "Elastic License v2", + "name": "Potential Malicious PowerShell Based on Alert Correlation", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This guide was created by humans with the assistance of generative AI. While its contents have been manually curated to include the most valuable information, always validate assumptions and adjust procedures to match your internal runbooks and incident triage and response policies.\n\n### Investigating Potential Malicious PowerShell Based on Alert Correlation\n\nThis alert groups multiple PowerShell-related detections that reference the same ScriptBlock identifier. When several independent detections fire on a single script block, it often indicates a single execution chain combining multiple suspicious behaviors. Treat the contributing alerts as the primary evidence and use this correlation to prioritize investigation and scoping.\n\nInvestigation goals:\n- Identify affected endpoints and users by pivoting to the contributing alerts.\n- Recover the complete script content associated with the ScriptBlock identifier and understand its intent.\n- Identify follow-on behavior (process, network, persistence) and scope the activity across the environment.\n\n#### Key alert fields to review\n\n- `Esql.script_block_id`: The ScriptBlock identifier used to correlate multiple alerts.\n- `Esql.kibana_alert_rule_name_count_distinct`: The number of distinct PowerShell-related rule names that contributed to the correlation.\n- `Esql.kibana_alert_rule_name_values`: The contributing rule names; use this list to quickly understand what detection logic was triggered.\n- `Esql._id_values`: The contributing alert document IDs; pivot to these source alerts for full context and supporting evidence.\n\n#### Possible investigation steps\n\n- Understand what drove the correlation:\n - Review `Esql.kibana_alert_rule_name_count_distinct` to gauge overall confidence and urgency.\n - Review `Esql.kibana_alert_rule_name_values` and group the contributing detections by behavior (for example, obfuscation/encoding, suspicious execution, network retrieval, or persistence-related activity). Use this grouping to decide what evidence is most important to validate first.\n\n- Pivot to the contributing alerts and capture execution context:\n - Use `Esql._id_values` to open each contributing alert and collect the affected host and user context, along with the earliest and latest timestamps across the set.\n - Confirm the contributing alerts represent the same ScriptBlock ID and are not unrelated alerts that happen to share similar message content.\n - Identify whether the activity is limited to a single endpoint or appears on multiple endpoints. Multiple endpoints can indicate script reuse, distribution, or remote execution.\n\n- Reconstruct the full script block content:\n - Using `Esql.script_block_id`, locate all available records (alerts and/or underlying telemetry referenced by the contributing alerts) tied to the same identifier.\n - If the script content is split across multiple fragments, reconstruct it in the correct order before assessing intent.\n - Identify any decoded/deobfuscated output that the script generates during execution and capture it as evidence for scoping.\n\n- Assess intent and capability based on the recovered script:\n - Look for evidence of staged execution, such as multiple layers of decoding, dynamic code generation, or invocation of additional code.\n - Identify indicators that can be used for scoping (for example, external destinations, file locations, created services, or suspicious child process activity referenced by the contributing alerts).\n\n- Correlate with adjacent activity during the same timeframe:\n - Process activity: check for unusual parent-child relationships involving PowerShell and unexpected child processes following the script block execution.\n - Network activity: review outbound connections and DNS activity that align with the execution window, especially first-time or rare destinations.\n - File and registry activity: look for payload staging, configuration changes, or persistence artifacts created near the execution window.\n - Authentication activity: review for suspicious logons or account changes that coincide with the script execution, especially if activity spans multiple endpoints.\n\n- Scope and hunt for additional occurrences:\n - Search for other alerts containing the same `Esql.script_block_id` to determine if the script was reused or executed repeatedly.\n - Use indicators and behaviors observed in the contributing alerts to identify related activity in other alerts and telemetry sources, and establish first-seen/last-seen boundaries.\n\n### False positive analysis\n\n- Legitimate administrative automation can produce multiple detections if it uses dynamic script generation, embedded encoded content, or downloads content at runtime. Validate whether the affected hosts, users, and timing align with an approved maintenance activity.\n- If the same ScriptBlock content repeatedly maps to a known benign workflow, document the expected behavior and tune upstream detections to better distinguish that workflow, rather than suppressing this correlation rule.\n\n### Response and remediation\n\n- If the activity is confirmed or strongly suspected to be malicious:\n - Contain impacted endpoints to prevent additional execution and follow-on actions.\n - Restrict, reset, or rotate credentials for involved accounts as appropriate, especially for privileged or shared accounts.\n - Remove identified artifacts and persistence mechanisms (for example, suspicious services or dropped binaries) and remediate any affected systems.\n - Block or monitor indicators identified from the contributing alerts (external destinations, file locations, or other observable artifacts) to prevent reinfection and support hunting.\n\n- Validation and recovery:\n - Use `Esql.script_block_id` and the contributing alert set in `Esql._id_values` to verify that the activity has ceased and to identify any additional impacted endpoints.\n - Continue monitoring for recurrence of the same ScriptBlock ID or the contributing behaviors to confirm remediation effectiveness.\n\n- Post-incident:\n - Preserve the recovered script content and the full set of contributing alerts as evidence.\n - Identify and address the initial execution mechanism indicated by the contributing alerts and improve preventative controls and logging coverage to reduce recurrence.\n", + "query": "from .alerts-security.* metadata _id\n\n// Filter for PowerShell related alerts\n| where kibana.alert.rule.name like \"*PowerShell*\"\n\n// as alerts don't have non-ECS fields, parse the script block ID using grok\n| grok message \"ScriptBlock ID: (?.+)\"\n| where Esql.script_block_id is not null\n\n// keep relevant fields for further processing\n| keep kibana.alert.rule.name, Esql.script_block_id, _id\n\n// count distinct alerts and filter for matches above the threshold\n| stats\n Esql.kibana_alert_rule_name_count_distinct = count_distinct(kibana.alert.rule.name),\n Esql.kibana_alert_rule_name_values = values(kibana.alert.rule.name),\n Esql._id_values = values(_id)\n by Esql.script_block_id\n\n// Apply detection threshold\n| where Esql.kibana_alert_rule_name_count_distinct >= 5\n", + "required_fields": [ + { + "ecs": false, + "name": "Esql._id_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.kibana_alert_rule_name_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.kibana_alert_rule_name_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.script_block_id", + "type": "keyword" + } + ], + "risk_score": 73, + "rule_id": "f770ce79-05fd-4d74-9866-1c5d66c9b34b", + "severity": "high", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Execution", + "Rule Type: Higher-Order Rule", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.001", + "name": "PowerShell", + "reference": "https://attack.mitre.org/techniques/T1059/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 4 + }, + "id": "f770ce79-05fd-4d74-9866-1c5d66c9b34b_4", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/f960e8a4-31c1-4a6e-b172-8f5c8e5c8c2a_1.json b/packages/security_detection_engine/kibana/security_rule/f960e8a4-31c1-4a6e-b172-8f5c8e5c8c2a_1.json new file mode 100644 index 00000000000..7f5a2a5a456 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/f960e8a4-31c1-4a6e-b172-8f5c8e5c8c2a_1.json @@ -0,0 +1,101 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "building_block_type": "default", + "description": "Identifies failed login attempts to the Okta Admin Console. Adversaries may attempt to gain unauthorized access to administrator portals during reconnaissance or privilege escalation phases. Repeated failures may indicate brute force attacks, credential spraying, or attempts to use compromised credentials. Monitoring Admin Console access failures provides visibility into potential account takeover attempts targeting administrative accounts.", + "from": "now-9m", + "index": [ + "logs-okta.system-*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "Okta Admin Console Login Failure", + "note": "## Triage and analysis\n\n### Investigating Okta Admin Console Login Failure\n\nThis rule detects failed authentication attempts specifically targeting the Okta Admin Console. The Admin Console provides privileged access to manage Okta configurations, users, and policies, making it a high-value target for adversaries.\n\nThreat actors like ShinyHunters have been observed probing for valid admin credentials as part of their attack chain. Failed Admin Console access attempts often precede successful compromise through vishing (voice phishing) or credential harvesting.\n\n#### Possible investigation steps:\n- Identify the user involved by examining the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, and `okta.actor.display_name` fields.\n- Review the `okta.outcome.reason` field to understand why the authentication failed (e.g., invalid credentials, MFA failure, policy violation).\n- Determine the client used by the actor. Review the `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.zone`, `okta.client.device`, and `okta.client.id` fields.\n- Check if the source IP is associated with known malicious activity, VPN/proxy services, or unusual geolocations.\n- Examine the `okta.request.ip_chain` field to determine if the actor used a proxy or VPN.\n- Correlate with other failed login attempts from the same IP or user to identify patterns.\n- Review if the targeted user has administrative privileges that would make them a high-value target.\n- Check for any recent vishing or phishing reports targeting users in your organization.\n\n### False positive analysis:\n- Administrators may legitimately mistype passwords or have MFA issues.\n- Automated systems or scripts may fail authentication due to expired credentials.\n- Users may accidentally attempt to access the Admin Console without proper permissions.\n\n### Response and remediation:\n- If repeated failures are observed from the same IP, consider blocking the IP address at the network perimeter.\n- Alert the targeted administrator about the failed access attempts.\n- If the user reports not attempting to access the Admin Console, treat this as a potential account compromise attempt.\n- Review and strengthen MFA requirements for Admin Console access.\n- Consider implementing conditional access policies to restrict Admin Console access to trusted networks.\n- If vishing is suspected, remind users of social engineering awareness and verification procedures.\n", + "query": "event.dataset: \"okta.system\"\n and event.category: \"authentication\"\n and okta.target.alternate_id: \"Okta Admin Console\"\n and okta.outcome.result: \"FAILURE\"\n", + "references": [ + "https://cloud.google.com/blog/topics/threat-intelligence/expansion-shinyhunters-saas-data-theft", + "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security", + "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta" + ], + "related_integrations": [ + { + "package": "okta", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.category", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": false, + "name": "okta.outcome.result", + "type": "keyword" + }, + { + "ecs": false, + "name": "okta.target.alternate_id", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "f960e8a4-31c1-4a6e-b172-8f5c8e5c8c2a", + "severity": "low", + "tags": [ + "Domain: Identity", + "Use Case: Identity and Access Audit", + "Data Source: Okta", + "Data Source: Okta System Logs", + "Tactic: Initial Access", + "Tactic: Credential Access", + "Resources: Investigation Guide", + "Rule Type: BBR" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0001", + "name": "Initial Access", + "reference": "https://attack.mitre.org/tactics/TA0001/" + }, + "technique": [ + { + "id": "T1078", + "name": "Valid Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "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": "query", + "version": 1 + }, + "id": "f960e8a4-31c1-4a6e-b172-8f5c8e5c8c2a_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/f9753455-8d55-4ad8-b70a-e07b6f18deea_4.json b/packages/security_detection_engine/kibana/security_rule/f9753455-8d55-4ad8-b70a-e07b6f18deea_4.json deleted file mode 100644 index 51a5a5ac844..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/f9753455-8d55-4ad8-b70a-e07b6f18deea_4.json +++ /dev/null @@ -1,153 +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// Filter out smaller scripts that are unlikely to implement obfuscation using the patterns we are looking for\n| eval Esql.script_block_length = length(powershell.file.script_block_text)\n| where Esql.script_block_length > 1000\n\n// replace the patterns we are looking for with the \ud83d\udd25 emoji to enable counting them\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n// Excludes spaces, #, = and - as they are heavily used in scripts for formatting\n| eval Esql.script_block_tmp = replace(powershell.file.script_block_text, \"\"\"[^0-9A-Za-z\\s#=-]\"\"\", \"\ud83d\udd25\")\n\n// count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| eval Esql.script_block_pattern_count = Esql.script_block_length - length(replace(Esql.script_block_tmp, \"\ud83d\udd25\", \"\"))\n\n// Calculate the ratio of special characters to total length\n| eval Esql.script_block_ratio = Esql.script_block_pattern_count::double / Esql.script_block_length::double\n\n// keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| keep\n Esql.script_block_pattern_count,\n Esql.script_block_length,\n Esql.script_block_ratio,\n Esql.script_block_tmp,\n powershell.file.script_block_text,\n powershell.file.script_block_id,\n file.path,\n powershell.sequence,\n powershell.total,\n _id,\n _index,\n host.name,\n agent.id,\n user.id\n\n// Filter for scripts with high special character ratio\n| where Esql.script_block_ratio > 0.30\n", - "related_integrations": [ - { - "package": "windows", - "version": "^3.0.0" - } - ], - "required_fields": [ - { - "ecs": false, - "name": "Esql.script_block_length", - "type": "integer" - }, - { - "ecs": false, - "name": "Esql.script_block_pattern_count", - "type": "integer" - }, - { - "ecs": false, - "name": "Esql.script_block_ratio", - "type": "double" - }, - { - "ecs": false, - "name": "Esql.script_block_tmp", - "type": "keyword" - }, - { - "ecs": false, - "name": "_id", - "type": "keyword" - }, - { - "ecs": false, - "name": "_index", - "type": "keyword" - }, - { - "ecs": true, - "name": "agent.id", - "type": "keyword" - }, - { - "ecs": true, - "name": "file.path", - "type": "keyword" - }, - { - "ecs": true, - "name": "host.name", - "type": "keyword" - }, - { - "ecs": false, - "name": "powershell.file.script_block_id", - "type": "keyword" - }, - { - "ecs": false, - "name": "powershell.file.script_block_text", - "type": "text" - }, - { - "ecs": false, - "name": "powershell.sequence", - "type": "long" - }, - { - "ecs": false, - "name": "powershell.total", - "type": "long" - }, - { - "ecs": true, - "name": "user.id", - "type": "keyword" - } - ], - "risk_score": 21, - "rule_id": "f9753455-8d55-4ad8-b70a-e07b6f18deea", - "setup": "## Setup\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nAdministrative Templates >\nWindows PowerShell >\nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n", - "severity": "low", - "tags": [ - "Domain: Endpoint", - "OS: Windows", - "Use Case: Threat Detection", - "Tactic: Defense Evasion", - "Data Source: PowerShell Logs", - "Rule Type: BBR" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0005", - "name": "Defense Evasion", - "reference": "https://attack.mitre.org/tactics/TA0005/" - }, - "technique": [ - { - "id": "T1027", - "name": "Obfuscated Files or Information", - "reference": "https://attack.mitre.org/techniques/T1027/" - }, - { - "id": "T1140", - "name": "Deobfuscate/Decode Files or Information", - "reference": "https://attack.mitre.org/techniques/T1140/" - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0002", - "name": "Execution", - "reference": "https://attack.mitre.org/tactics/TA0002/" - }, - "technique": [ - { - "id": "T1059", - "name": "Command and Scripting Interpreter", - "reference": "https://attack.mitre.org/techniques/T1059/", - "subtechnique": [ - { - "id": "T1059.001", - "name": "PowerShell", - "reference": "https://attack.mitre.org/techniques/T1059/001/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 4 - }, - "id": "f9753455-8d55-4ad8-b70a-e07b6f18deea_4", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/f9753455-8d55-4ad8-b70a-e07b6f18deea_8.json b/packages/security_detection_engine/kibana/security_rule/f9753455-8d55-4ad8-b70a-e07b6f18deea_8.json new file mode 100644 index 00000000000..3c704a668db --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/f9753455-8d55-4ad8-b70a-e07b6f18deea_8.json @@ -0,0 +1,219 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "building_block_type": "default", + "description": "Identifies PowerShell script block content with an unusually high proportion of non-alphanumeric characters, often produced by encoding, string mangling, or dynamic code generation. Attackers use special-character heavy obfuscation to conceal payloads and hinder static analysis and AMSI.", + "from": "now-9m", + "investigation_fields": { + "field_names": [ + "@timestamp", + "user.name", + "user.id", + "user.domain", + "powershell.file.script_block_text", + "powershell.file.script_block_id", + "powershell.sequence", + "powershell.total", + "file.path", + "file.directory", + "file.name", + "process.pid", + "host.name", + "host.id", + "powershell.file.script_block_length" + ] + }, + "language": "esql", + "license": "Elastic License v2", + "name": "Potential PowerShell Obfuscation via High Special Character Proportion", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This guide was created by humans with the assistance of generative AI. While its contents have been manually curated to include the most valuable information, always validate assumptions and adjust procedures to match your internal runbooks and incident triage and response policies.\n\n### Investigating Potential PowerShell Obfuscation via High Special Character Proportion\n\nThis rule alerts on PowerShell Script Block Logging content where non-alphanumeric characters make up an unusually large share of the script text. This pattern is frequently produced by encoding, aggressive escaping, string mangling, or dynamic code generation intended to hinder inspection.\n\nThe alert includes scoring and script-shape fields that help distinguish benign embedded data from suspicious deobfuscation/execution logic. Treat the script block text as potentially untrusted content and focus on reconstructing the full script and identifying downstream behavior through correlation.\n\n#### Key alert fields to review\n\n- `user.name`, `user.domain`, `user.id`: Account execution context for correlation, prioritization, and scoping.\n- `host.name`, `host.id`: Host execution context for correlation, prioritization, and scoping.\n- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file.\n- `powershell.file.script_block_text`: Script block content that matched the detection logic.\n- `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`: Script block metadata to pivot to other fragments or reconstruct full script content when split across multiple events.\n- `Esql.script_block_tmp`: Transformed script block where detection patterns replace original content with a marker to support scoring/counting and quickly spot match locations.\n- `Esql.script_block_ratio`: Proportion of the script block's characters that match the alert's target character set, divided by total script length (0-1).\n- `Esql.script_block_pattern_count`: Count of matches for the detection pattern(s) observed in the script block content.\n- `powershell.file.script_block_entropy_bits`: Shannon entropy of the script block. Higher values may indicate obfuscation.\n- `powershell.file.script_block_surprisal_stdev`: Standard deviation of surprisal across the script block. Low values indicate uniform randomness. High values indicate mixed patterns and variability.\n- `powershell.file.script_block_unique_symbols`: Count of distinct characters present in the script block.\n- `powershell.file.script_block_length`: Script block length (size) context.\n\n#### Possible investigation steps\n\n- Establish scope and execution context:\n - Review `@timestamp` to set an investigation window and identify preceding/follow-on activity.\n - Identify the affected `host.id`/`host.name` and the executing `user.id`/`user.name`/`user.domain`.\n - Determine whether the user/host pairing is expected for PowerShell usage in your environment and whether the account is privileged or widely used.\n\n- Interpret the alert scoring and \"shape\" signals:\n - Review `Esql.script_block_ratio` and `Esql.script_block_pattern_count` alongside `powershell.file.script_block_length` to understand how extreme the special-character density is.\n - Use `Esql.script_block_tmp` to quickly assess whether the special characters cluster in a single region (for example, one embedded blob) or are distributed throughout the script (for example, pervasive mangling).\n - Use `powershell.file.script_block_entropy_bits`, `powershell.file.script_block_unique_symbols`, and `powershell.file.script_block_surprisal_stdev` to guide prioritization:\n - High entropy with many unique symbols commonly aligns with encoded/compressed/encrypted blobs embedded in the script.\n - High special-character ratio with lower entropy can align with heavy escaping, string concatenation, or code generation.\n - Low surprisal variability (low standard deviation) can indicate uniformly random-looking content typical of dense encoding.\n\n- Reconstruct the full script block before making a determination:\n - Pivot on `powershell.file.script_block_id` to collect all fragments for the script block.\n - Reassemble fragments in order using `powershell.sequence` and confirm completeness using `powershell.total`.\n - If fragments are missing, treat the visible content as incomplete and continue collection/scoping before concluding intent.\n\n- Analyze `powershell.file.script_block_text` for intent and technique:\n - Identify whether the content is primarily data (for example, long opaque strings) or executable logic (functions, control flow, and invocation).\n - Look for common deobfuscation and dynamic execution patterns, such as:\n - Decoding/decompression routines (for example, Base64 decoding, byte/char transformations, compression streams).\n - Dynamic invocation or staged execution (for example, `Invoke-Expression`/`IEX`, reflection, `.Invoke()`, `Add-Type`).\n - Retrieval of remote content or secondary payloads (for example, web request/client usage, download-and-execute flow).\n - If the script includes clear indicators (domains, URLs, IP addresses, file paths, file names), capture them from the script text for pivoting and scoping.\n\n- Determine provenance and expectedness using available file context:\n - If `file.path`/`file.directory`/`file.name` are present, assess whether the location and naming align with known administrative scripts or approved automation.\n - If file fields are absent, treat the activity as potentially interactive or in-memory and prioritize identifying what initiated PowerShell through adjacent host telemetry.\n\n- Correlate with adjacent telemetry (as available in your environment) to confirm impact:\n - Process activity on the same host and time window to determine the initiating process and whether PowerShell was launched indirectly.\n - Network activity to identify outbound connections consistent with download, staging, or command-and-control behavior.\n - File and registry activity to identify dropped artifacts or persistence-related changes.\n - Authentication activity for the same `user.id` to identify suspicious logons or lateral movement preceding the script execution.\n\n- Expand scope across the environment:\n - Search for additional script block events on the same `host.id` and `user.id` near the alert time to identify staged execution (for example, decoding in one block, execution in another).\n - Hunt for similar script content using stable substrings from `powershell.file.script_block_text`, and group by `file.name` or `file.path` when present to identify reuse.\n\n### False positive analysis\n\n- False positives are most likely when scripts embed or manipulate large non-code payloads (for example, serialized objects, structured data, certificates, or compressed content) or when tooling auto-generates scripts with heavy escaping and templating.\n- Validate benign hypotheses by confirming a consistent execution pattern over time (recurring `host.id` and `user.id`), expected provenance (`file.path`/`file.name` when present), and script content that performs known administrative functions rather than decoding and executing newly generated code.\n- Treat unexpected execution context (new user/host pairing) combined with high entropy and opaque content as higher risk, even if the script text does not immediately reveal its final payload.\n\n### Response and remediation\n\n- If malicious or suspicious activity is confirmed:\n - Contain the affected host to prevent additional execution and lateral movement.\n - Preserve evidence from the alert, including `powershell.file.script_block_text`, reconstructed fragments (if applicable), `powershell.file.script_block_id`, and the scoring fields (`Esql.script_block_ratio`, `Esql.script_block_pattern_count`, `powershell.file.script_block_entropy_bits`).\n - Identify and remediate follow-on behavior discovered during correlation (downloaded payloads, dropped files, persistence changes, or suspicious network destinations).\n - Scope the intrusion by searching for similar script content across the environment using stable substrings from `powershell.file.script_block_text`, and by pivoting on `user.id`, `host.id`, `file.path`, and `file.name`.\n - If account compromise is suspected, reset credentials for the affected user and review other recent activity for that `user.id`.\n\n- If the activity is determined benign:\n - Document the responsible script or workflow, expected execution context, and typical frequency.\n - Monitor for deviations such as new hosts, new users, or materially different script content that may indicate abuse of a legitimate mechanism.\n", + "query": "from logs-windows.powershell_operational* metadata _id, _version, _index\n| where event.code == \"4104\"\n\n// Filter out smaller scripts that are unlikely to implement obfuscation using the patterns we are looking for\n| eval Esql.script_block_length = length(powershell.file.script_block_text)\n| where Esql.script_block_length > 1000\n\n// replace the patterns we are looking for with the \ud83d\udd25 emoji to enable counting them\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n// Excludes spaces, #, = and - as they are heavily used in scripts for formatting\n| eval Esql.script_block_tmp = replace(powershell.file.script_block_text, \"\"\"[^0-9A-Za-z\\s#=-]\"\"\", \"\ud83d\udd25\")\n\n// count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| eval Esql.script_block_pattern_count = Esql.script_block_length - length(replace(Esql.script_block_tmp, \"\ud83d\udd25\", \"\"))\n\n// Calculate the ratio of special characters to total length\n| eval Esql.script_block_ratio = Esql.script_block_pattern_count::double / Esql.script_block_length::double\n\n// keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| keep\n Esql.script_block_pattern_count,\n Esql.script_block_length,\n Esql.script_block_ratio,\n Esql.script_block_tmp,\n powershell.file.*,\n file.path,\n file.directory,\n powershell.sequence,\n powershell.total,\n _id,\n _version,\n _index,\n host.name,\n host.id,\n agent.id,\n user.id\n\n// Filter for scripts with high special character ratio\n| where Esql.script_block_ratio > 0.35\n\n// Exclude Noisy Patterns\n| where not file.directory like \"C:\\\\\\\\ProgramData\\\\\\\\Microsoft\\\\\\\\Windows Defender Advanced Threat Protection\\\\\\\\DataCollection\\\\\\\\*\"\n // ESQL requires this condition, otherwise it only returns matches where file.directory exists.\n or file.directory IS NULL\n", + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.script_block_length", + "type": "integer" + }, + { + "ecs": false, + "name": "Esql.script_block_pattern_count", + "type": "integer" + }, + { + "ecs": false, + "name": "Esql.script_block_ratio", + "type": "double" + }, + { + "ecs": false, + "name": "Esql.script_block_tmp", + "type": "keyword" + }, + { + "ecs": false, + "name": "_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "_index", + "type": "keyword" + }, + { + "ecs": false, + "name": "_version", + "type": "long" + }, + { + "ecs": true, + "name": "agent.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.directory", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.path", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.name", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_entropy_bits", + "type": "double" + }, + { + "ecs": false, + "name": "powershell.file.script_block_entropy_normalized", + "type": "double" + }, + { + "ecs": false, + "name": "powershell.file.script_block_hash", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_length", + "type": "long" + }, + { + "ecs": false, + "name": "powershell.file.script_block_surprisal_stdev", + "type": "double" + }, + { + "ecs": false, + "name": "powershell.file.script_block_text", + "type": "text" + }, + { + "ecs": false, + "name": "powershell.file.script_block_unique_symbols", + "type": "long" + }, + { + "ecs": false, + "name": "powershell.sequence", + "type": "long" + }, + { + "ecs": false, + "name": "powershell.total", + "type": "long" + }, + { + "ecs": true, + "name": "user.id", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "f9753455-8d55-4ad8-b70a-e07b6f18deea", + "setup": "## Setup\n\nPowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104).\nSetup instructions: https://ela.st/powershell-logging-setup\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: PowerShell Logs", + "Rule Type: BBR", + "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": 8 + }, + "id": "f9753455-8d55-4ad8-b70a-e07b6f18deea_8", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/f9abcddc-a05d-4345-a81d-000b79aa5525_10.json b/packages/security_detection_engine/kibana/security_rule/f9abcddc-a05d-4345-a81d-000b79aa5525_10.json new file mode 100644 index 00000000000..a0ea86c393d --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/f9abcddc-a05d-4345-a81d-000b79aa5525_10.json @@ -0,0 +1,217 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects long PowerShell script block content with unusually high numeric character density (high digit-to-length ratio), often produced by byte arrays, character-code reconstruction, or embedded encoded blobs. Attackers use numeric-heavy obfuscation to conceal payloads and rebuild them at runtime to avoid static inspection.", + "from": "now-9m", + "investigation_fields": { + "field_names": [ + "@timestamp", + "user.name", + "user.id", + "user.domain", + "powershell.file.script_block_text", + "powershell.file.script_block_id", + "powershell.sequence", + "powershell.total", + "file.path", + "file.directory", + "file.name", + "process.pid", + "host.name", + "host.id", + "powershell.file.script_block_length" + ] + }, + "language": "esql", + "license": "Elastic License v2", + "name": "Potential PowerShell Obfuscation via High Numeric Character Proportion", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This guide was created by humans with the assistance of generative AI. While its contents have been manually curated to include the most valuable information, always validate assumptions and adjust procedures to match your internal runbooks and incident triage and response policies.\n\n### Investigating Potential PowerShell Obfuscation via High Numeric Character Proportion\n\nThis rule flags long PowerShell script blocks with unusually digit-dense content. Numeric-heavy script blocks are often used to conceal payloads as byte arrays or character codes that are decoded at runtime. Triage should focus on reconstructing the full script content, determining how it was initiated, and identifying any decoded or executed secondary content.\n\n#### Key alert fields to review\n\n- `user.name`, `user.domain`, `user.id`: Account execution context for correlation, prioritization, and scoping.\n- `host.name`, `host.id`: Host execution context for correlation, prioritization, and scoping.\n- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file.\n- `powershell.file.script_block_text`: Script block content that matched the detection logic.\n- `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`: Script block metadata to pivot to other fragments or reconstruct full script content when split across multiple events.\n- `Esql.script_block_tmp`: Transformed script block where detection patterns replace original content with a marker to support scoring/counting and quickly spot match locations.\n- `Esql.script_block_ratio`: Proportion of the script block's characters that match the alert's target character set, divided by total script length (0-1).\n- `Esql.script_block_pattern_count`: Count of matches for the detection pattern(s) observed in the script block content.\n- `powershell.file.script_block_entropy_bits`: Shannon entropy of the script block. Higher values may indicate obfuscation.\n- `powershell.file.script_block_surprisal_stdev`: Standard deviation of surprisal across the script block. Low values indicate uniform randomness. High values indicate mixed patterns and variability.\n- `powershell.file.script_block_unique_symbols`: Count of distinct characters present in the script block.\n- `powershell.file.script_block_length`: Script block length (size) context.\n\n#### Possible investigation steps\n\n- Review `powershell.file.script_block_text` to characterize the numeric content:\n - Look for long comma-separated numbers, repeated digit sequences, or `0x`-prefixed values that may represent reconstructed bytes.\n - Identify string reconstruction patterns (for example, casting numeric values to characters) and any subsequent decoding or decompression logic.\n - Note any execution primitives that would run derived content (for example, invoking dynamically built commands or loading content into memory).\n- If the script is fragmented, use `powershell.sequence` and `powershell.total` to collect the related script block events on the same `host.name` and `user.id` and reconstruct the complete content in the correct order before drawing conclusions.\n- Establish execution context and scope using `host.name`, `host.id`, `agent.id`, and `user.id`:\n - Determine whether the user context is expected to run PowerShell and whether similar script blocks have occurred recently on the same host or by the same user.\n - Look for other alerts on the same host or user that could indicate staging, persistence, or lateral movement.\n- Assess script origin using `file.path` and `file.directory` when present:\n - Determine whether the script is sourced from a location consistent with approved administration or automation workflows.\n - If the script is file-backed, check for other security telemetry referencing the same path to identify file creation, modification, or repeated execution patterns.\n- Correlate with adjacent telemetry (as available in your environment) using the host and user pivots above:\n - Process execution telemetry near the alert time to identify the PowerShell host process and its parent, and to understand how PowerShell was launched.\n - Network telemetry for outbound connections or downloads that could support payload retrieval or command and control.\n - File activity for dropped payloads or staging artifacts related to the script content or its on-disk source.\n\n### False positive analysis\n\n- Legitimate scripts that embed binary content as numeric arrays (for example, packaging resources into scripts or deploying configuration blobs) can appear digit-dense.\n- Administrative tooling that generates large reports, inventories, or exports may include extensive numeric identifiers and constants.\n- Some legitimate security or management products may produce numeric-heavy PowerShell content as part of automation; validate against known software, expected execution accounts, and change windows.\n\n### Response and remediation\n\n- If malicious behavior is suspected, contain the affected host to prevent further execution and reduce the risk of follow-on activity.\n- Preserve the script content from `powershell.file.script_block_text` (and any reconstructed multi-part content) for deeper analysis and to support incident response and retrospective hunting.\n- If `file.path` is present and the source is not authorized, remove or quarantine the script and investigate related host artifacts and execution mechanisms.\n- Investigate potential account compromise for the associated `user.id` by reviewing recent authentication and endpoint activity; take credential and session remediation actions in line with your procedures.\n- Hunt for related activity using `host.id`, `agent.id`, `user.id`, and distinctive script patterns identified during triage to find additional impacted systems.\n- Apply preventive controls based on findings, such as tightening PowerShell usage for affected accounts, improving script provenance controls, and enhancing monitoring for similar obfuscation patterns.\n", + "query": "from logs-windows.powershell_operational* metadata _id, _version, _index\n| where event.code == \"4104\"\n\n// Filter out smaller scripts that are unlikely to implement obfuscation using the patterns we are looking for\n| eval Esql.script_block_length = length(powershell.file.script_block_text)\n| where Esql.script_block_length > 1000\n\n// replace the patterns we are looking for with the \ud83d\udd25 emoji to enable counting them\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| eval Esql.script_block_tmp = replace(powershell.file.script_block_text, \"\"\"[0-9]\"\"\", \"\ud83d\udd25\")\n\n// count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| eval Esql.script_block_pattern_count = Esql.script_block_length - length(replace(Esql.script_block_tmp, \"\ud83d\udd25\", \"\"))\n\n// Calculate the ratio of special characters to total length\n| eval Esql.script_block_ratio = Esql.script_block_pattern_count::double / Esql.script_block_length::double\n\n// keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| keep\n Esql.script_block_pattern_count,\n Esql.script_block_ratio,\n Esql.script_block_length,\n Esql.script_block_tmp,\n powershell.file.*,\n file.directory,\n file.path,\n powershell.sequence,\n powershell.total,\n _id,\n _version,\n _index,\n host.name,\n host.id,\n agent.id,\n user.id\n\n// Filter for scripts with high numeric character ratio\n| where Esql.script_block_ratio > 0.5\n\n// Exclude Windows Defender Noisy Patterns\n| where not (\n file.directory == \"C:\\\\ProgramData\\\\Microsoft\\\\Windows Defender Advanced Threat Protection\\\\Downloads\" or\n file.directory like (\n \"C:\\\\\\\\ProgramData\\\\\\\\Microsoft\\\\\\\\Windows Defender Advanced Threat Protection\\\\\\\\DataCollection*\",\n \"C:\\\\\\\\Program Files\\\\\\\\SentinelOne\\\\\\\\Sentinel Agent*\"\n )\n )\n // ESQL requires this condition, otherwise it only returns matches where file.directory exists.\n or file.directory is null\n| where not powershell.file.script_block_text like \"*[System.IO.File]::Open('C:\\\\\\\\ProgramData\\\\\\\\Microsoft\\\\\\\\Windows Defender Advanced Threat Protection\\\\\\\\DataCollection*\"\n| where not powershell.file.script_block_text : \"26a24ae4-039d-4ca4-87b4-2f64180311f0\"\n", + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.script_block_length", + "type": "integer" + }, + { + "ecs": false, + "name": "Esql.script_block_pattern_count", + "type": "integer" + }, + { + "ecs": false, + "name": "Esql.script_block_ratio", + "type": "double" + }, + { + "ecs": false, + "name": "Esql.script_block_tmp", + "type": "keyword" + }, + { + "ecs": false, + "name": "_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "_index", + "type": "keyword" + }, + { + "ecs": false, + "name": "_version", + "type": "long" + }, + { + "ecs": true, + "name": "agent.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.directory", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.path", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.name", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_entropy_bits", + "type": "double" + }, + { + "ecs": false, + "name": "powershell.file.script_block_entropy_normalized", + "type": "double" + }, + { + "ecs": false, + "name": "powershell.file.script_block_hash", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_length", + "type": "long" + }, + { + "ecs": false, + "name": "powershell.file.script_block_surprisal_stdev", + "type": "double" + }, + { + "ecs": false, + "name": "powershell.file.script_block_text", + "type": "text" + }, + { + "ecs": false, + "name": "powershell.file.script_block_unique_symbols", + "type": "long" + }, + { + "ecs": false, + "name": "powershell.sequence", + "type": "long" + }, + { + "ecs": false, + "name": "powershell.total", + "type": "long" + }, + { + "ecs": true, + "name": "user.id", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "f9abcddc-a05d-4345-a81d-000b79aa5525", + "setup": "## Setup\n\nPowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104).\nSetup instructions: https://ela.st/powershell-logging-setup\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": 10 + }, + "id": "f9abcddc-a05d-4345-a81d-000b79aa5525_10", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/f9abcddc-a05d-4345-a81d-000b79aa5525_6.json b/packages/security_detection_engine/kibana/security_rule/f9abcddc-a05d-4345-a81d-000b79aa5525_6.json deleted file mode 100644 index aedcca977b7..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/f9abcddc-a05d-4345-a81d-000b79aa5525_6.json +++ /dev/null @@ -1,158 +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// Filter out smaller scripts that are unlikely to implement obfuscation using the patterns we are looking for\n| eval Esql.script_block_length = length(powershell.file.script_block_text)\n| where Esql.script_block_length > 1000\n\n// replace the patterns we are looking for with the \ud83d\udd25 emoji to enable counting them\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| eval Esql.script_block_tmp = replace(powershell.file.script_block_text, \"\"\"[0-9]\"\"\", \"\ud83d\udd25\")\n\n// count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| eval Esql.script_block_pattern_count = Esql.script_block_length - length(replace(Esql.script_block_tmp, \"\ud83d\udd25\", \"\"))\n\n// Calculate the ratio of special characters to total length\n| eval Esql.script_block_ratio = Esql.script_block_pattern_count::double / Esql.script_block_length::double\n\n// keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| keep\n Esql.script_block_pattern_count,\n Esql.script_block_ratio,\n Esql.script_block_length,\n Esql.script_block_tmp,\n powershell.file.script_block_text,\n powershell.file.script_block_id,\n file.directory,\n file.path,\n powershell.sequence,\n powershell.total,\n _id,\n _index,\n host.name,\n agent.id,\n user.id\n\n// Filter for scripts with high numeric character ratio\n| where Esql.script_block_ratio > 0.30\n\n// Exclude Windows Defender Noisy Patterns\n| where not (\n file.directory == \"C:\\\\ProgramData\\\\Microsoft\\\\Windows Defender Advanced Threat Protection\\\\Downloads\" or\n file.directory like \"C:\\\\\\\\ProgramData\\\\\\\\Microsoft\\\\\\\\Windows Defender Advanced Threat Protection\\\\\\\\DataCollection*\"\n )\n // ESQL requires this condition, otherwise it only returns matches where file.directory exists.\n or file.directory is null\n| where not powershell.file.script_block_text like \"*[System.IO.File]::Open('C:\\\\\\\\ProgramData\\\\\\\\Microsoft\\\\\\\\Windows Defender Advanced Threat Protection\\\\\\\\DataCollection*\"\n| where not powershell.file.script_block_text : \"26a24ae4-039d-4ca4-87b4-2f64180311f0\"\n", - "related_integrations": [ - { - "package": "windows", - "version": "^3.0.0" - } - ], - "required_fields": [ - { - "ecs": false, - "name": "Esql.script_block_length", - "type": "integer" - }, - { - "ecs": false, - "name": "Esql.script_block_pattern_count", - "type": "integer" - }, - { - "ecs": false, - "name": "Esql.script_block_ratio", - "type": "double" - }, - { - "ecs": false, - "name": "Esql.script_block_tmp", - "type": "keyword" - }, - { - "ecs": false, - "name": "_id", - "type": "keyword" - }, - { - "ecs": false, - "name": "_index", - "type": "keyword" - }, - { - "ecs": true, - "name": "agent.id", - "type": "keyword" - }, - { - "ecs": true, - "name": "file.directory", - "type": "keyword" - }, - { - "ecs": true, - "name": "file.path", - "type": "keyword" - }, - { - "ecs": true, - "name": "host.name", - "type": "keyword" - }, - { - "ecs": false, - "name": "powershell.file.script_block_id", - "type": "keyword" - }, - { - "ecs": false, - "name": "powershell.file.script_block_text", - "type": "text" - }, - { - "ecs": false, - "name": "powershell.sequence", - "type": "long" - }, - { - "ecs": false, - "name": "powershell.total", - "type": "long" - }, - { - "ecs": true, - "name": "user.id", - "type": "keyword" - } - ], - "risk_score": 21, - "rule_id": "f9abcddc-a05d-4345-a81d-000b79aa5525", - "setup": "## Setup\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nAdministrative Templates >\nWindows PowerShell >\nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n", - "severity": "low", - "tags": [ - "Domain: Endpoint", - "OS: Windows", - "Use Case: Threat Detection", - "Tactic: Defense Evasion", - "Data Source: PowerShell Logs", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0005", - "name": "Defense Evasion", - "reference": "https://attack.mitre.org/tactics/TA0005/" - }, - "technique": [ - { - "id": "T1027", - "name": "Obfuscated Files or Information", - "reference": "https://attack.mitre.org/techniques/T1027/" - }, - { - "id": "T1140", - "name": "Deobfuscate/Decode Files or Information", - "reference": "https://attack.mitre.org/techniques/T1140/" - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0002", - "name": "Execution", - "reference": "https://attack.mitre.org/tactics/TA0002/" - }, - "technique": [ - { - "id": "T1059", - "name": "Command and Scripting Interpreter", - "reference": "https://attack.mitre.org/techniques/T1059/", - "subtechnique": [ - { - "id": "T1059.001", - "name": "PowerShell", - "reference": "https://attack.mitre.org/techniques/T1059/001/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 6 - }, - "id": "f9abcddc-a05d-4345-a81d-000b79aa5525_6", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/fb542346-1624-4cf2-bcc7-c68abaab261b_1.json b/packages/security_detection_engine/kibana/security_rule/fb542346-1624-4cf2-bcc7-c68abaab261b_1.json new file mode 100644 index 00000000000..2c06d24c5a4 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/fb542346-1624-4cf2-bcc7-c68abaab261b_1.json @@ -0,0 +1,120 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects common utilities accessing kprobes and tracing-related paths in debugfs/tracefs, which may indicate discovery of kernel instrumentation hooks. Adversaries can enumerate these locations to understand or prepare for eBPF, kprobe, or tracepoint-based activity. This behavior can also be benign during troubleshooting, performance analysis, or observability tooling validation.", + "from": "now-9m", + "index": [ + "auditbeat-*", + "endgame-*", + "logs-auditd_manager.auditd-*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", + "logs-crowdstrike.fdr*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Kernel Instrumentation Discovery via kprobes and tracefs", + "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 Kernel Instrumentation Discovery via kprobes and tracefs\n\nThis rule detects common Linux utilities and shells reading kprobes and tracing locations under debugfs/tracefs, signaling discovery of kernel instrumentation hooks. Attackers use this to understand which kprobe/tracepoint interfaces are available or already in use before deploying eBPF-based collection or stealthy monitoring. A typical pattern is a script that iterates tracing directories and reads kprobe and tracepoint listings to map callable probes and active tracing state.\n\n### Possible investigation steps\n\n- Review the full command line and the specific tracefs/debugfs paths accessed to determine whether this was benign directory enumeration or targeted inspection of sensitive files like `available_filter_functions`, `kprobe_events`, `set_ftrace_filter`, or `trace_pipe`. \n- Identify the initiating user and process tree, then search nearby activity for follow-on steps such as writing to `kprobe_events`/`uprobe_events`, enabling tracing events, or sustained reads from `trace_pipe`. \n- Validate whether `debugfs`/`tracefs` are mounted and assess the host\u2019s role and installed observability/performance tooling to quickly separate routine diagnostics from unexpected tracing access. \n- Hunt for adjacent signals of kernel instrumentation setup or abuse, including use of eBPF tooling (`bpftool`, `bpftrace`, BCC), `perf`, suspicious `bpf()` syscall activity, or module loading around the same time window. \n- Compare current tracing configuration and recent file modification activity under `/sys/kernel/debug/tracing` and `/sys/kernel/tracing` against baseline expectations to detect tampering or persistence.\n\n### False positive analysis\n\n- A system administrator or automated diagnostic script may use basic utilities like `cat`, `grep`, or `find` to enumerate `/sys/kernel/debug/tracing` or `/sys/kernel/tracing` during kernel troubleshooting or performance triage to confirm tracefs/debugfs is mounted and to review available functions/events.\n- Routine validation of tracing configuration after kernel upgrades or configuration changes can involve shells running `ls`, `stat`, or `readlink` over kprobe and tracing paths to verify current settings and permissions, even when no malicious instrumentation is intended.\n\n### Response and remediation\n\n- Contain suspected abuse by isolating the host and immediately stopping the offending script/process tree that is enumerating `/sys/kernel/debug/kprobes/*` or `/sys/kernel/*tracing/*`, then preserve the shell history and the script/binary on disk for analysis. \n- Eradicate kernel instrumentation changes by checking for and removing any attacker-added entries in `kprobe_events`/`uprobe_events`, disabling any enabled tracing knobs, and remounting or unmounting `debugfs`/`tracefs` if they are not required for operations. \n- Recover to a known-good state by rebooting to clear transient tracing state, validating that `trace_pipe` is not being read continuously, and confirming that expected observability tooling (if any) still functions after tracing is reset. \n- Escalate to incident response immediately if you observe writes to `kprobe_events`/`uprobe_events`, sustained reads from `trace_pipe`, or nearby execution of eBPF/performance tooling (e.g., `bpftool`, `bpftrace`, `perf`) by an unexpected user or from an unusual parent process. \n- Harden to prevent recurrence by restricting access to `debugfs`/`tracefs` to administrators only, disabling unprivileged BPF where feasible, and enforcing MAC policies (SELinux/AppArmor) to deny non-approved processes from reading or writing tracing interfaces.", + "query": "process where host.os.type == \"linux\" and event.type == \"start\" and\nevent.action in (\"exec\", \"exec_event\", \"start\", \"ProcessRollup2\", \"executed\", \"process_started\") and\nprocess.name in (\n \"cat\", \"grep\", \"head\", \"tail\", \"ls\",\n \"less\", \"more\",\n \"awk\", \"sed\", \"cut\", \"tr\", \"xargs\", \"tee\",\n \"find\", \"stat\", \"readlink\",\n \"bash\", \"dash\", \"sh\", \"tcsh\", \"csh\", \"zsh\", \"ksh\", \"fish\", \"busybox\"\n) and\nprocess.args like (\"/sys/kernel/debug/kprobes/*\", \"/sys/kernel/debug/tracing/*\", \"/sys/kernel/tracing/*\")\n", + "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": "^3.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": "fb542346-1624-4cf2-bcc7-c68abaab261b", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Discovery", + "Tactic: Defense Evasion", + "Data Source: Elastic Endgame", + "Data Source: Elastic Defend", + "Data Source: Auditd Manager", + "Data Source: SentinelOne", + "Data Source: Crowdstrike", + "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/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1014", + "name": "Rootkit", + "reference": "https://attack.mitre.org/techniques/T1014/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 1 + }, + "id": "fb542346-1624-4cf2-bcc7-c68abaab261b_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/fc552f49-8f1c-409b-90f8-6f5b9869b6c4_1.json b/packages/security_detection_engine/kibana/security_rule/fc552f49-8f1c-409b-90f8-6f5b9869b6c4_1.json new file mode 100644 index 00000000000..1326a297c28 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/fc552f49-8f1c-409b-90f8-6f5b9869b6c4_1.json @@ -0,0 +1,109 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects when an Elastic Defend endpoint alert is generated on a host and is not followed by any subsequent endpoint telemetry (process, network, registry, library, or DNS events) within a short time window. This behavior may indicate endpoint security evasion, agent tampering, sensor disablement, service termination, system crash, or malicious interference with telemetry collection following detection.", + "false_positives": [ + "Misconfiguration, system reboot, network issues or expected uninstall of the Elastic Defend agent." + ], + "from": "now-9m", + "index": [ + "logs-endpoint.*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Elastic Defend Alert Followed by Telemetry Loss", + "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 Defend Alert Followed by Telemetry Loss\n\nThis rule identifies situations where an Elastic Defend alert is generated on a host and is not followed by\nany normal endpoint activity events within a short time window. This may indicate agent tampering, sensor\ndisablement, host shutdown, system crash, or defense evasion behavior.\n\n### Possible investigation steps\n\n- Review the original `endpoint.alert` event and identify the detection that triggered the alert.\n- Check the host\u2019s online status, uptime, and reboot history.\n- Verify the health and status of the Elastic Defend agent and related services.\n- Look for evidence of agent tampering, service stops, or security control modifications.\n- Correlate with activity immediately preceding the alert for signs of exploitation or evasion.\n- Determine if similar alert \u2192 silence patterns are occurring on other hosts.\n\n### False positive analysis\n\n- Legitimate system reboots or shutdowns\n- Network connectivity loss\n- Elastic Agent upgrades or restarts\n- Endpoint service crashes\n- Maintenance or IT operations\n\n### Response and remediation\n\n- Validate host and agent availability.\n- Reconnect or re-enroll the agent if telemetry is missing.\n- Isolate the host if malicious activity is suspected.\n- Investigate for security control tampering.\n- Perform broader environment hunting for similar patterns.\n", + "query": "sequence by host.id with maxspan=5m\n [any where event.dataset == \"endpoint.alerts\"]\n ![any where event.category in (\"process\", \"library\", \"registry\", \"network\", \"dns\")]\n", + "references": [ + "https://attack.mitre.org/techniques/T1562/001/" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.category", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.id", + "type": "keyword" + } + ], + "risk_score": 73, + "rule_id": "fc552f49-8f1c-409b-90f8-6f5b9869b6c4", + "severity": "high", + "tags": [ + "Domain: Endpoint", + "Data Source: Elastic Defend", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Tactic: Execution", + "Rule Type: Higher-Order Rule", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1562", + "name": "Impair Defenses", + "reference": "https://attack.mitre.org/techniques/T1562/", + "subtechnique": [ + { + "id": "T1562.001", + "name": "Disable or Modify Tools", + "reference": "https://attack.mitre.org/techniques/T1562/001/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "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": "eql", + "version": 1 + }, + "id": "fc552f49-8f1c-409b-90f8-6f5b9869b6c4_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/fd7a6052-58fa-4397-93c3-4795249ccfa2_422.json b/packages/security_detection_engine/kibana/security_rule/fd7a6052-58fa-4397-93c3-4795249ccfa2_422.json deleted file mode 100644 index 7922e01e750..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/fd7a6052-58fa-4397-93c3-4795249ccfa2_422.json +++ /dev/null @@ -1,181 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies a suspicious parent child process relationship with cmd.exe descending from svchost.exe", - "filters": [ - { - "meta": { - "negate": true - }, - "query": { - "wildcard": { - "process.args": { - "case_insensitive": true, - "value": "?:\\\\Windows\\\\system32\\\\silcollector.cmd" - } - } - } - }, - { - "meta": { - "negate": true - }, - "query": { - "wildcard": { - "process.command_line": { - "case_insensitive": true, - "value": "*?:\\\\Program Files\\\\Npcap\\\\CheckStatus.bat*" - } - } - } - }, - { - "meta": { - "negate": true - }, - "query": { - "wildcard": { - "process.command_line": { - "case_insensitive": true, - "value": "*?:\\\\Program Files*\\\\Pulseway\\\\watchdog.bat*" - } - } - } - }, - { - "meta": { - "negate": true - }, - "query": { - "wildcard": { - "process.command_line": { - "case_insensitive": true, - "value": "cmd /C \".\\inetsrv\\iissetup.exe /keygen \"\n" - } - } - } - } - ], - "from": "now-9m", - "history_window_start": "now-14d", - "index": [ - "logs-endpoint.events.process-*", - "winlogbeat-*", - "logs-windows.forwarded*", - "logs-windows.sysmon_operational-*", - "endgame-*", - "logs-system.security*", - "logs-m365_defender.event-*", - "logs-sentinel_one_cloud_funnel.*" - ], - "language": "kuery", - "license": "Elastic License v2", - "name": "Svchost spawning Cmd", - "new_terms_fields": [ - "host.id", - "process.command_line", - "user.id" - ], - "note": "## Triage and analysis\n\n### Investigating Svchost spawning Cmd\n\nThe Service Host process (SvcHost) is a system process that can host one, or multiple, Windows services in the Windows NT family of operating systems. Note that `Svchost.exe` is reserved for use by the operating system and should not be used by non-Windows services.\n\nThis rule looks for the creation of the `cmd.exe` process with `svchost.exe` as its parent process. This is an unusual behavior that can indicate the masquerading of a malicious process as `svchost.exe` or exploitation for privilege escalation.\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 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 any abnormal behavior by the subject process such as network connections, registry or file modifications, and any spawned child processes.\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 - Examine the DNS cache for suspicious or anomalous entries.\n - !{osquery{\"label\":\"Osquery - Retrieve DNS Cache\",\"query\":\"SELECT * FROM dns_cache\"}}\n - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree.\n - Examine the host services for suspicious or anomalous entries.\n - !{osquery{\"label\":\"Osquery - Retrieve All Services\",\"query\":\"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services\"}}\n - !{osquery{\"label\":\"Osquery - Retrieve Services Running on User Accounts\",\"query\":\"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\\nuser_account == null)\\n\"}}\n - !{osquery{\"label\":\"Osquery - Retrieve Service Unsigned Executables with Virustotal Link\",\"query\":\"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\\n\"}}\n - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.\n- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the target host after the registry modification.\n\n\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 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": "host.os.type:windows and event.category:process and event.type:start and process.parent.name:\"svchost.exe\" and\nprocess.name:(\"cmd.exe\" or \"Cmd.exe\" or \"CMD.EXE\") and\nnot process.command_line : \"\\\"cmd.exe\\\" /C sc control hptpsmarthealthservice 211\"\n", - "references": [ - "https://nasbench.medium.com/demystifying-the-svchost-exe-process-and-its-command-line-options-508e9114e747" - ], - "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" - } - ], - "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.command_line", - "type": "wildcard" - }, - { - "ecs": true, - "name": "process.name", - "type": "keyword" - }, - { - "ecs": true, - "name": "process.parent.name", - "type": "keyword" - } - ], - "risk_score": 21, - "rule_id": "fd7a6052-58fa-4397-93c3-4795249ccfa2", - "severity": "low", - "tags": [ - "Domain: Endpoint", - "OS: Windows", - "Use Case: Threat Detection", - "Tactic: Execution", - "Resources: Investigation Guide", - "Data Source: Elastic Endgame", - "Data Source: Elastic Defend", - "Data Source: Windows Security Event Logs", - "Data Source: Microsoft Defender for Endpoint", - "Data Source: Sysmon", - "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/" - } - ] - } - ], - "timeline_id": "e70679c2-6cde-4510-9764-4823df18f7db", - "timeline_title": "Comprehensive Process Timeline", - "timestamp_override": "event.ingested", - "type": "new_terms", - "version": 422 - }, - "id": "fd7a6052-58fa-4397-93c3-4795249ccfa2_422", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/fe25d5bc-01fa-494a-95ff-535c29cc4c96_111.json b/packages/security_detection_engine/kibana/security_rule/fe25d5bc-01fa-494a-95ff-535c29cc4c96_111.json new file mode 100644 index 00000000000..bffab575635 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/fe25d5bc-01fa-494a-95ff-535c29cc4c96_111.json @@ -0,0 +1,130 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "building_block_type": "default", + "description": "Identifies PowerShell script block content that queries Active Directory password policy settings using AD cmdlets, GPP password helpers, or directory searcher attributes. Attackers collect password policy details to tune credential attacks and target weak configurations.", + "from": "now-119m", + "index": [ + "winlogbeat-*", + "logs-windows.powershell*" + ], + "interval": "60m", + "investigation_fields": { + "field_names": [ + "@timestamp", + "user.name", + "user.id", + "user.domain", + "powershell.file.script_block_text", + "powershell.file.script_block_id", + "powershell.sequence", + "powershell.total", + "file.path", + "file.directory", + "file.name", + "process.pid", + "host.name", + "host.id", + "powershell.file.script_block_length" + ] + }, + "language": "kuery", + "license": "Elastic License v2", + "name": "PowerShell Script with Password Policy Discovery Capabilities", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This guide was created by humans with the assistance of generative AI. While its contents have been manually curated to include the most valuable information, always validate assumptions and adjust procedures to match your internal runbooks and incident triage and response policies.\n\n### Investigating PowerShell Script with Password Policy Discovery Capabilities\n\nThis alert identifies PowerShell script block content consistent with querying Active Directory password policy settings, including default domain policy requirements, fine-grained password policies, or related directory attributes. Adversaries may use these details to tune password guessing attempts and prioritize targets; administrators may also collect this information for auditing and troubleshooting.\n\n#### Key alert fields to review\n\n- `user.name`, `user.domain`, `user.id`: Account execution context for correlation, prioritization, and scoping.\n- `host.name`, `host.id`: Host execution context for correlation, prioritization, and scoping.\n- `powershell.file.script_block_text`: Script block content that matched the detection logic.\n- `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`: Script block metadata to pivot to other fragments or reconstruct full script content when split across multiple events.\n- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file.\n- `powershell.file.script_block_length`: Script block length (size) context.\n\n#### Possible investigation steps\n- Review `powershell.file.script_block_text` and identify the discovery method:\n - AD password policy cmdlets/functions such as `Get-ADDefaultDomainPasswordPolicy`, `Get-ADFineGrainedPasswordPolicy`, `Get-ADUserResultantPasswordPolicy`, `Get-DomainPolicy`, or `Get-PassPol`.\n - Directory searcher patterns such as `defaultNamingContext`, `ActiveDirectory.DirectoryContext`, or `ActiveDirectory.DirectorySearcher`, and referenced properties/attributes like `.MinLengthPassword`, `.MinPasswordAge`, `.MaxPasswordAge`, `minPwdLength`, `minPwdAge`, `maxPwdAge`, or `msDS-PasswordSettings`.\n - Helper function use that may attempt to access Group Policy Preference password data (for example, `Get-GPPPassword`).\n- Determine scope and intent from the script content:\n - Domain-wide enumeration vs querying a specific user/resultant policy.\n - Enumeration of fine-grained policy objects (`msDS-PasswordSettings`), which can indicate targeted reconnaissance for weaker settings.\n - Evidence of output collection (formatting, exporting, or writing results) that may support later use.\n- Validate the execution context using `host.name`, `host.id`, `user.name`, `user.domain`, and `user.id`:\n - Confirm the host is an expected location for administrative or audit activity (for example, an admin workstation or management server).\n - Assess whether the account context aligns with expected job function and normal host access patterns.\n- Determine script origin and how it was introduced when `file.path`, `file.directory`, or `file.name` are present:\n - Validate that the script path and name align with approved tooling and standard locations for that host.\n - Treat execution from user-writable or temporary locations, or from unfamiliar script names, as higher risk and scope for additional suspicious activity.\n- Reconstruct the full script content when it is split across multiple events:\n - Pivot on `powershell.file.script_block_id` and order by `powershell.sequence` to rebuild the full script (use `powershell.total` to confirm all fragments are present).\n - Preserve the reconstructed content for case notes and scoping.\n- Correlate with other activity from the same host and account near `@timestamp` (if available in your telemetry):\n - Review additional PowerShell script block logs for related discovery, credential access attempts, or follow-on execution.\n - Review process activity to determine how PowerShell was launched (parent process, service/automation context, or interactive use) and whether the launch source is expected for the user/host.\n - Review network activity consistent with directory queries or access to domain infrastructure that may indicate broader reconnaissance.\n - Review file activity for evidence of staged scripts/modules or stored output containing policy details.\n - Review authentication activity for spikes in failed logons, account lockouts, or access to multiple hosts following the discovery.\n- Scope and prevalence:\n - Look for similar `powershell.file.script_block_text` content executed by the same `user.id` on other hosts to determine whether this is isolated or part of a wider discovery phase.\n - Look for similar content on the same `host.id` from other users to identify shared tooling, automation, or a compromised host used to launch reconnaissance.\n\n### False positive analysis\n- Authorized identity and directory administration activities (for example, validating password policy requirements during audits, troubleshooting, or policy change reviews).\n- Scheduled reporting or compliance workflows that periodically inventory default and fine-grained password policy settings.\n- Support investigations that query resultant password policy for a specific user as part of account lifecycle management or lockout investigations.\n\n### Response and remediation\n- If the activity is unexpected or cannot be tied to an approved administrative task:\n - Isolate the affected host to prevent further reconnaissance.\n - Restrict or disable the involved account (`user.id`) and reset credentials according to incident response procedures.\n - Preserve evidence, including the reconstructed `powershell.file.script_block_text`, associated `powershell.file.script_block_id` fragments, and any referenced scripts (`file.path`, `file.name`).\n - Hunt for follow-on activity associated with password policy discovery, such as password guessing attempts, credential collection, and additional directory enumeration, using the same `user.id`, `host.id`, and timeframe.\n - If the script content suggests access to Group Policy Preference password data, treat this as potential credential exposure and rotate any identified credentials and remediate insecure configurations.\n- If the activity is confirmed benign:\n - Document the approved use case (expected accounts, hosts, and script locations) to speed future triage.\n - Apply least-privilege controls to limit where and by whom directory policy discovery can be performed while maintaining audit visibility.\n", + "query": "event.category: \"process\" and host.os.type:windows and\n(\n powershell.file.script_block_text: (\n \"Get-ADDefaultDomainPasswordPolicy\" or\n \"Get-ADFineGrainedPasswordPolicy\" or\n \"Get-ADUserResultantPasswordPolicy\" or\n \"Get-DomainPolicy\" or\n \"Get-GPPPassword\" or\n \"Get-PassPol\"\n )\n or\n powershell.file.script_block_text: (\n (\"defaultNamingContext\" or \"ActiveDirectory.DirectoryContext\" or \"ActiveDirectory.DirectorySearcher\") and\n (\n (\n \".MinLengthPassword\" or\n \".MinPasswordAge\" or\n \".MaxPasswordAge\"\n ) or\n (\n \"minPwdAge\" or\n \"maxPwdAge\" or\n \"minPwdLength\"\n ) or\n (\n \"msDS-PasswordSettings\"\n )\n )\n )\n) and\n\nnot powershell.file.script_block_text : (\"sentinelbreakpoints\" and \"Set-PSBreakpoint\" and \"PowerSploitIndicators\") and\nnot powershell.file.script_block_text : (\"43c15630-959c-49e4-a977-758c5cc93408\" and \"CmdletsToExport\" and \"ActiveDirectory.Types.ps1xml\") and\nnot file.directory: \"C:\\Program Files\\LogicMonitor\\Agent\\tmp\" and\nnot user.id : \"S-1-5-18\"\n", + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.category", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.directory", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_text", + "type": "unknown" + }, + { + "ecs": true, + "name": "user.id", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "fe25d5bc-01fa-494a-95ff-535c29cc4c96", + "setup": "## Setup\n\nPowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104).\nSetup instructions: https://ela.st/powershell-logging-setup\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Discovery", + "Tactic: Execution", + "Data Source: PowerShell Logs", + "Rule Type: BBR", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0007", + "name": "Discovery", + "reference": "https://attack.mitre.org/tactics/TA0007/" + }, + "technique": [ + { + "id": "T1201", + "name": "Password Policy Discovery", + "reference": "https://attack.mitre.org/techniques/T1201/" + } + ] + }, + { + "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": "query", + "version": 111 + }, + "id": "fe25d5bc-01fa-494a-95ff-535c29cc4c96_111", + "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 06b44984d5a..dc002b971b0 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.15 +version: 8.19.16-beta.1