elastic / detection-rules

https://www.elastic.co/guide/en/security/current/detection-engine-overview.html
Other
1.95k stars 496 forks source link

[FR] Standardize structure of triage information within `note` field #569

Closed brokensound77 closed 2 years ago

brokensound77 commented 3 years ago

The field note (which is investigation guide within Kibana) is a free-form markdown field which is not required to be populated, that is meant to hold information on how to triage, analyze, or respond (or any other relevant info) to an alert. It is intentionally meant to be free-form markdown to allow users to form the information in whatever format best conveys the information in a quickly discernible way (concise, detailed, or both).

This issue is to propose a standardized format to all pre-built rules

The most immediate and obvious advantage is that a familiar structure will allow users to get used to it and so be able to quickly react and understand them (which is especially important during triage and analysis of an alert).

I don't think it is necessary to over formalize it by enforcing strict verbiage guidelines, so much as to maintain consistent markdown, fields, and ordering.

An example would be:

EXAMPLE --


Triage and analysis

...

Related rules

...

Threat intel

...

CVE's and vulnerabilities

...

Response and remediation

...

END EXAMPLE --

The above example is just an example - I am open to whatever format and categories we feel are most useful.

Currently, note is also used to hold rule config dependencies as well. I have opened an issue to propose creating a dedicated new field for this in order to split that out in a more purposeful place.

Enforcement and testing

We would likely be able to enforce unit tests on this as well to ensure we are consistent as we want to be.

cc: @elastic/security-intelligence-analytics


Current rule notes

Expand to see all rules which currently populate the "note" field
``` python -m detection_rules rule-search "note:*" -c name,note Loaded config file: /Users/jibarra/PycharmProjects/detection-rules-fork/.detection-rules-cfg.json █▀▀▄ ▄▄▄ ▄▄▄ ▄▄▄ ▄▄▄ ▄▄▄ ▄▄▄ ▄▄▄ ▄ ▄ █▀▀▄ ▄ ▄ ▄ ▄▄▄ ▄▄▄ █ █ █▄▄ █ █▄▄ █ █ █ █ █ █▀▄ █ █▄▄▀ █ █ █ █▄▄ █▄▄ █▄▄▀ █▄▄ █ █▄▄ █▄▄ █ ▄█▄ █▄█ █ ▀▄█ █ ▀▄ █▄▄█ █▄▄ █▄▄ ▄▄█ DEBUG MODE ENABLED Loading rules from /Users/jibarra/PycharmProjects/detection-rules-fork/rules Loaded 335 rules ======================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================= name note ======================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================= AWS Access Secret in Secrets Manager The AWS Filebeat module must be enabled to use this rule. AWS CloudTrail Log Created The AWS Filebeat module must be enabled to use this rule. AWS CloudTrail Log Deleted The AWS Filebeat module must be enabled to use this rule. AWS CloudTrail Log Suspended The AWS Filebeat module must be enabled to use this rule. AWS CloudTrail Log Updated The AWS Filebeat module must be enabled to use this rule. AWS CloudWatch Alarm Deletion The AWS Filebeat module must be enabled to use this rule. AWS CloudWatch Log Group Deletion The AWS Filebeat module must be enabled to use this rule. AWS CloudWatch Log Stream Deletion The AWS Filebeat module must be enabled to use this rule. AWS Config Service Tampering The AWS Filebeat module must be enabled to use this rule. AWS Configuration Recorder Stopped The AWS Filebeat module must be enabled to use this rule. AWS EC2 Encryption Disabled The AWS Filebeat module must be enabled to use this rule. AWS EC2 Flow Log Deletion The AWS Filebeat module must be enabled to use this rule. AWS EC2 Network Access Control List Creation The AWS Filebeat module must be enabled to use this rule. AWS EC2 Network Access Control List Deletion The AWS Filebeat module must be enabled to use this rule. AWS EC2 Snapshot Activity The AWS Filebeat module must be enabled to use this rule. AWS Execution via System Manager The AWS Filebeat module must be enabled to use this rule. AWS GuardDuty Detector Deletion The AWS Filebeat module must be enabled to use this rule. AWS IAM Assume Role Policy Update The AWS Filebeat module must be enabled to use this rule. AWS IAM Brute Force of Assume Role Policy The AWS Filebeat module must be enabled to use this rule. AWS IAM Deactivation of MFA Device The AWS Filebeat module must be enabled to use this rule. AWS IAM Group Creation The AWS Filebeat module must be enabled to use this rule. AWS IAM Group Deletion The AWS Filebeat module must be enabled to use this rule. AWS IAM Password Recovery Requested The AWS Filebeat module must be enabled to use this rule. AWS IAM User Addition to Group The AWS Filebeat module must be enabled to use this rule. AWS Management Console Brute Force of Root User Identity The AWS Filebeat module must be enabled to use this rule. AWS Management Console Root Login The AWS Filebeat module must be enabled to use this rule. AWS RDS Cluster Creation The AWS Filebeat module must be enabled to use this rule. AWS RDS Cluster Deletion The AWS Filebeat module must be enabled to use this rule. AWS RDS Instance/Cluster Stoppage The AWS Filebeat module must be enabled to use this rule. AWS Root Login Without MFA The AWS Filebeat module must be enabled to use this rule. AWS S3 Bucket Configuration Deletion The AWS Filebeat module must be enabled to use this rule. AWS WAF Access Control List Deletion The AWS Filebeat module must be enabled to use this rule. AWS WAF Rule or Rule Group Deletion The AWS Filebeat module must be enabled to use this rule. Abnormally Large DNS Response ### Investigating Large DNS Responses Detection alerts from this rule indicate an attempt was made to exploit CVE-2020-1350 (SigRed) through the use of large DNS responses on a Windows DNS server. Here are some possible avenues of investigation: - Investigate any corresponding Intrusion Detection Signatures (IDS) alerts that can validate this detection alert. - Examine the `dns.question_type` network fieldset with a protocol analyzer, such as Zeek, Packetbeat, or Suricata, for `SIG` or `RRSIG` data. - Validate the patch level and OS of the targeted DNS server to validate the observed activity was not large-scale Internet vulnerability scanning. - Validate that the source of the network activity was not from an authorized vulnerability scan or compromise assessment. Adding Hidden File Attribute via Attrib Administrator Privileges Assigned to Okta Group The Okta Filebeat module must be enabled to use this rule. Adobe Hijack Persistence Adversary Behavior - Detected - Endpoint Security Anomalous Kernel Module Activity Anomalous Linux Compiler Activity Anomalous Process For a Linux Population ### Investigating an Unusual Linux Process ### Detection alerts from this rule indicate the presence of a Linux process that is rare and unusual for all of the monitored Linux hosts for which Auditbeat data is available. Here are some possible avenues of investigation: - Consider the user as identified by the username field. Is this program part of an expected workflow for the user who ran this program on this host? - Examine the history of execution. If this process manifested only very recently, it might be part of a new software package. If it has a consistent cadence - for example if it runs monthly or quarterly - it might be part of a monthly or quarterly business process. - Examine the process arguments, title and working directory. These may provide indications as to the source of the program or the nature of the tasks it is performing. Anomalous Process For a Windows Population ### Investigating an Unusual Windows Process ### Detection alerts from this rule indicate the presence of a Windows process that is rare and unusual for all of the Windows hosts for which Winlogbeat data is available. Here are some possible avenues of investigation: - Consider the user as identified by the username field. Is this program part of an expected workflow for the user who ran this program on this host? - Examine the history of execution. If this process manifested only very recently, it might be part of a new software package. If it has a consistent cadence - for example if it runs monthly or quarterly - it might be part of a monthly or quarterly business process. - Examine the process metadata like the values of the Company, Description and Product fields which may indicate whether the program is associated with an expected software vendor or package. - Examine arguments and working directory. These may provide indications as to the source of the program or the nature of the tasks it is performing. - Consider the same for the parent process. If the parent process is a legitimate system utility or service, this could be related to software updates or system management. If the parent process is something user-facing like an Office application, this process could be more suspicious. - If you have file hash values in the event data, and you suspect malware, you can optionally run a search for the file hash to see if the file is identified as malware by anti-malware tools. Anomalous Windows Process Creation Attempt to Create Okta API Token The Okta Filebeat module must be enabled to use this rule. Attempt to Deactivate MFA for Okta User Account The Okta Filebeat module must be enabled to use this rule. Attempt to Deactivate Okta MFA Rule The Okta Filebeat module must be enabled to use this rule. Attempt to Deactivate Okta Policy The Okta Filebeat module must be enabled to use this rule. Attempt to Deactivate an Okta Application The Okta Fleet integration or Filebeat module must be enabled to use this rule. Attempt to Delete Okta Policy The Okta Filebeat module must be enabled to use this rule. Attempt to Delete an Okta Application The Okta Fleet integration or Filebeat module must be enabled to use this rule. Attempt to Disable IPTables or Firewall Attempt to Disable Syslog Service Attempt to Modify Okta MFA Rule The Okta Filebeat module must be enabled to use this rule. Attempt to Modify Okta Network Zone The Okta Filebeat module must be enabled to use this rule. Attempt to Modify Okta Policy The Okta Filebeat module must be enabled to use this rule. Attempt to Modify an Okta Application The Okta Fleet integration or Filebeat module must be enabled to use this rule. Attempt to Reset MFA Factors for Okta User Account The Okta Filebeat module must be enabled to use this rule. Attempt to Revoke Okta API Token The Okta Filebeat module must be enabled to use this rule. Attempted Bypass of Okta MFA The Okta Filebeat module must be enabled to use this rule. Attempts to Brute Force an Okta User Account The Okta Filebeat module must be enabled to use this rule. Azure Automation Account Created The Azure Filebeat module must be enabled to use this rule. Azure Automation Runbook Created or Modified The Azure Filebeat module must be enabled to use this rule. Azure Automation Runbook Deleted The Azure Filebeat module must be enabled to use this rule. Azure Automation Webhook Created The Azure Filebeat module must be enabled to use this rule. Azure Blob Container Access Level Modification The Azure Filebeat module must be enabled to use this rule. Azure Command Execution on Virtual Machine The Azure Filebeat module must be enabled to use this rule. Azure Conditional Access Policy Modified The Azure Filebeat module must be enabled to use this rule. Azure Diagnostic Settings Deletion The Azure Filebeat module must be enabled to use this rule. Azure Event Hub Authorization Rule Created or Updated The Azure Filebeat module must be enabled to use this rule. Azure Event Hub Deletion The Azure Filebeat module must be enabled to use this rule. Azure External Guest User Invitation The Azure Filebeat module must be enabled to use this rule. Azure Firewall Policy Deletion The Azure Filebeat module must be enabled to use this rule. Azure Global Administrator Role Addition to PIM User The Azure Filebeat module must be enabled to use this rule. Azure Key Vault Modified The Azure Filebeat module must be enabled to use this rule. Azure Network Watcher Deletion The Azure Filebeat module must be enabled to use this rule. Azure Privilege Identity Management Role Modified The Azure Filebeat module must be enabled to use this rule. Azure Resource Group Deletion The Azure Filebeat module must be enabled to use this rule. Azure Storage Account Key Regenerated The Azure Filebeat module must be enabled to use this rule. Base16 or Base32 Encoding/Decoding Activity Base64 Encoding/Decoding Activity Bypass UAC via Event Viewer Bypass UAC via Sdclt Clearing Windows Event Logs Cobalt Strike Command and Control Beacon This activity has been observed in FIN7 campaigns. Command Prompt Network Connection Compression of Keychain Credentials Directories Conhost Spawned By Suspicious Parent Process Connection to External Network via Telnet Connection to Internal Network via Telnet Creation of Hidden Files and Directories Creation or Modification of Domain Backup DPAPI private key ### Domain DPAPI Backup keys are stored on domain controllers and can be dumped remotely with tools such as Mimikatz. The resulting .pvk private key can be used to decrypt ANY domain user masterkeys, which then can be used to decrypt any secrets protected by those keys. Creation or Modification of a new GPO Scheduled Task or Service Credential Dumping - Detected - Endpoint Security Credential Dumping - Prevented - Endpoint Security Credential Manipulation - Detected - Endpoint Security Credential Manipulation - Prevented - Endpoint Security DNS Activity to the Internet DNS Tunneling Delete Volume USN Journal with Fsutil Deleting Backup Catalogs with Wbadmin Deletion of Bash Command Line History Direct Outbound SMB Connection Disable Windows Firewall Rules via Netsh Downloaded Shortcut Files Downloaded URL Files Encoding or Decoding Files via CertUtil Endpoint Security Enumeration of Kernel Modules Execution of File Written or Modified by Microsoft Office Execution of File Written or Modified by PDF Reader Execution via MSSQL xp_cmdshell Stored Procedure Execution via Regsvcs/Regasm Exploit - Detected - Endpoint Security Exploit - Prevented - Endpoint Security External Alerts FTP (File Transfer Protocol) Activity to the Internet File Deletion via Shred File Permission Modification in Writable Directory GCP Firewall Rule Creation The GCP Filebeat module must be enabled to use this rule. GCP Firewall Rule Deletion The GCP Filebeat module must be enabled to use this rule. GCP Firewall Rule Modification The GCP Filebeat module must be enabled to use this rule. GCP IAM Custom Role Creation The GCP Filebeat module must be enabled to use this rule. GCP IAM Role Deletion The GCP Filebeat module must be enabled to use this rule. GCP IAM Service Account Key Deletion The GCP Filebeat module must be enabled to use this rule. GCP Logging Bucket Deletion The GCP Filebeat module must be enabled to use this rule. GCP Logging Sink Deletion The GCP Filebeat module must be enabled to use this rule. GCP Logging Sink Modification The GCP Filebeat module must be enabled to use this rule. GCP Pub/Sub Subscription Creation The GCP Filebeat module must be enabled to use this rule. GCP Pub/Sub Subscription Deletion The GCP Filebeat module must be enabled to use this rule. GCP Pub/Sub Topic Creation The GCP Filebeat module must be enabled to use this rule. GCP Pub/Sub Topic Deletion The GCP Filebeat module must be enabled to use this rule. GCP Service Account Creation The GCP Filebeat module must be enabled to use this rule. GCP Service Account Deletion The GCP Filebeat module must be enabled to use this rule. GCP Service Account Disabled The GCP Filebeat module must be enabled to use this rule. GCP Service Account Key Creation The GCP Filebeat module must be enabled to use this rule. GCP Storage Bucket Configuration Modification The GCP Filebeat module must be enabled to use this rule. GCP Storage Bucket Deletion The GCP Filebeat module must be enabled to use this rule. GCP Storage Bucket Permissions Modification The GCP Filebeat module must be enabled to use this rule. GCP Virtual Private Cloud Network Deletion The GCP Filebeat module must be enabled to use this rule. GCP Virtual Private Cloud Route Creation The GCP Filebeat module must be enabled to use this rule. GCP Virtual Private Cloud Route Deletion The GCP Filebeat module must be enabled to use this rule. Google Workspace API Access Granted via Domain-Wide Delegation of Authority ### Important Information Regarding Google Workspace Event Lag Times - As per Google's documentation, Google Workspace administrators may observe lag times ranging from minutes up to 3 days between the time of an event's occurrence and the event being visible in the Google Workspace admin/audit logs. - This rule is configured to run every 10 minutes with a lookback time of 130 minutes. - To reduce the risk of false negatives, consider reducing the interval that the Google Workspace (formerly G Suite) Filebeat module polls Google's reporting API for new events. - By default, `var.interval` is set to 2 hours (2h). Consider changing this interval to a lower value, such as 10 minutes (10m). - See the following references for further information. - https://support.google.com/a/answer/7061566 - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-gsuite.html Halfbaked Command and Control Beacon This activity has been observed in FIN7 campaigns. Hex Encoding/Decoding Activity High Number of Okta User Password Reset or Unlock Attempts The Okta Filebeat module must be enabled to use this rule. Hosts File Modified For 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. Hping Process Activity IIS HTTP Logging Disabled IPSEC NAT Traversal Port Activity IRC (Internet Relay Chat) Protocol Activity to the Internet Inbound Connection to an Unsecure Elasticsearch Node This rule requires the addition of port `9200` and `send_all_headers` to the `HTTP` protocol configuration in `packetbeat.yml`. See the References section for additional configuration documentation. InstallUtil Process Making Network Connections Installation of Custom Shim Databases Interactive Terminal Spawned via Perl Interactive Terminal Spawned via Python Kerberos Cached Credentials Dumping Kernel Module Removal Local Scheduled Task Commands Local Service Commands Malware - Detected - Endpoint Security Malware - Prevented - Endpoint Security Microsoft Build Engine Loading Windows Credential Libraries Microsoft Build Engine Started an Unusual Process Microsoft Build Engine Started by a Script Process Microsoft Build Engine Started by a System Process Microsoft Build Engine Started by an Office Application Microsoft Build Engine Using an Alternate Name Microsoft IIS Connection Strings Decryption Microsoft IIS Service Account Password Dumped Mimikatz Memssp Log File Detected Mknod Process Activity Modification of Boot Configuration Modification or Removal of an Okta Application Sign-On Policy The Okta Filebeat module must be enabled to use this rule. MsBuild Making Network Connections MsBuild Network Connection Sequence MsXsl Making Network Connections Mshta Making Network Connections Multi-Factor Authentication Disabled for an Azure User The Azure Filebeat module must be enabled to use this rule. Net command via SYSTEM account Netcat Network Activity Network Connection via Certutil Network Connection via Compiled HTML File Network Connection via MsXsl Network Connection via Mshta Network Connection via Registration Utility Network Connection via Signed Binary Network Sniffing via Tcpdump Nmap Process Activity Nping Process Activity Okta Brute Force or Password Spraying Attack The Okta Filebeat module must be enabled to use this rule. PPTP (Point to Point Tunneling Protocol) Activity Permission Theft - Detected - Endpoint Security Permission Theft - Prevented - Endpoint Security Persistence via Kernel Module Modification Persistence via TelemetryController Scheduled Task Hijack Persistence via Update Orchestrator Service Hijack Possible Consent Grant Attack via Azure-Registered Application - The Azure Filebeat module must be enabled to use this rule. - In a consent grant attack, an attacker tricks an end user into granting a malicious application consent to access their data, usually via a phishing attack. After the malicious application has been granted consent, it has account-level access to data without the need for an organizational account. - Normal remediation steps, like resetting passwords for breached accounts or requiring Multi-Factor Authentication (MFA) on accounts, are not effective against this type of attack, since these are third-party applications and are external to the organization. - Security analysts should review the list of trusted applications for any suspicious items. Possible FIN7 DGA Command and Control Behavior In the event this rule identifies benign domains in your environment, the `destination.domain` field in the rule can be modified to include those domains. Example: `...AND NOT destination.domain:(zoom.us OR benign.domain1 OR benign.domain2)`. Possible Okta DoS Attack The Okta Filebeat module must be enabled to use this rule. Potential Application Shimming via Sdbinst Potential DLL SideLoading via Trusted Microsoft Programs Potential DNS Tunneling via Iodine Potential Disabling of SELinux Potential Evasion via Filter Manager Potential Modification of Accessibility Binaries Potential Remote Desktop Tunneling Detected Potential Secure File Deletion via SDelete Utility Verify process details such as command line and hash to confirm this activity legitimacy. Potential Shell via Web Server PowerShell spawning Cmd Process Activity via Compiled HTML File Process Discovery via Tasklist Process Injection - Detected - Endpoint Security Process Injection - Prevented - Endpoint Security Process Injection by the Microsoft Build Engine Process Potentially Masquerading as WerFault Prompt for Credentials with OSASCRIPT Proxy Port Activity to the Internet PsExec Network Connection Public IP Reconnaissance Activity This rule takes HTTP redirects and HTTP referrer's into account, however neither HTTP redirect status codes nor HTTP referrer's are visible with TLS traffic which can lead to multiple events per alert. RDP (Remote Desktop Protocol) from the Internet RDP (Remote Desktop Protocol) to the Internet RPC (Remote Procedure Call) from the Internet RPC (Remote Procedure Call) to the Internet Ransomware - Detected - Endpoint Security Ransomware - Prevented - Endpoint Security Rare AWS Error Code ### Investigating Unusual CloudTrail Error Activity ### Detection alerts from this rule indicate a rare and unusual error code that was associated with the response to an AWS API command or method call. Here are some possible avenues of investigation: - Examine the history of the error. Has it manifested before? If the error, which is visible in the `aws.cloudtrail.error_code field`, manifested only very recently, it might be related to recent changes in an automation module or script. - Examine the request parameters. These may provide indications as to the nature of the task being performed when the error occurred. Is the error related to unsuccessful attempts to enumerate or access objects, data, or secrets? If so, this can sometimes be a byproduct of discovery, privilege escalation, or lateral movement attempts. - Consider the user as identified by the `user.name` field. Is this activity part of an expected workflow for the user context? Examine the user identity in the `aws.cloudtrail.user_identity.arn` field and the access key id in the `aws.cloudtrail.user_identity.access_key_id` field which can help identify the precise user context. The user agent details in the `user_agent.original` field may also indicate what kind of a client made the request. - Consider the source IP address and geolocation for the calling user who issued the command. Do they look normal for the calling user? If the source is an EC2 IP address, is it associated with an EC2 instance in one of your accounts or could it be sourcing from an EC2 instance not under your control? If it is an authorized EC2 instance, is the activity associated with normal behavior for the instance role or roles? Are there any other alerts or signs of suspicious activity involving this instance? Registration Tool Making Network Connections Remote File Copy via TeamViewer Remote File Download via Desktopimgdownldr Utility Remote File Download via MpCmdRun ### Investigating Remote File Download via MpCmdRun Verify details such as the parent process, URL reputation, and downloaded file details. Additionally, `MpCmdRun` logs this information in the Appdata Temp folder in `MpCmdRun.log`. Remote SSH Login Enabled via systemsetup Command Renamed AutoIt Scripts Interpreter Roshal Archive (RAR) or PowerShell File Downloaded from the Internet This activity has been observed in FIN7 campaigns. SMB (Windows File Sharing) Activity to the Internet SMTP on Port 26/TCP SMTP to the Internet SQL Traffic to the Internet SSH (Secure Shell) from the Internet SSH (Secure Shell) to the Internet Security Software Discovery using WMIC Service Command Lateral Movement Setgid Bit Set via chmod Setuid Bit Set via chmod Socat Process Activity Spike in AWS Error Messages ### Investigating Spikes in CloudTrail Errors ### Detection alerts from this rule indicate a large spike in the number of CloudTrail log messages that contain a particular error message. The error message in question was associated with the response to an AWS API command or method call. Here are some possible avenues of investigation: - Examine the history of the error. Has it manifested before? If the error, which is visible in the `aws.cloudtrail.error_message` field, manifested only very recently, it might be related to recent changes in an automation module or script. - Examine the request parameters. These may provide indications as to the nature of the task being performed when the error occurred. Is the error related to unsuccessful attempts to enumerate or access objects, data or secrets? If so, this can sometimes be a byproduct of discovery, privilege escalation or lateral movement attempts. - Consider the user as identified by the user.name field. Is this activity part of an expected workflow for the user context? Examine the user identity in the `aws.cloudtrail.user_identity.arn` field and the access key id in the `aws.cloudtrail.user_identity.access_key_id` field which can help identify the precise user context. The user agent details in the `user_agent.original` field may also indicate what kind of a client made the request. - Consider the source IP address and geolocation for the calling user who issued the command. Do they look normal for the calling user? If the source is an EC2 IP address, is it associated with an EC2 instance in one of your accounts or could it be sourcing from an EC2 instance not under your control? If it is an authorized EC2 instance, is the activity associated with normal behavior for the instance role or roles? Are there any other alerts or signs of suspicious activity involving this instance? Strace Process Activity Sudoers File Modification Suspicious .NET Code Compilation Suspicious Activity Reported by Okta User The Okta Filebeat module must be enabled to use this rule. Suspicious Cmd Execution via WMI Suspicious Endpoint Security Parent Process Suspicious Execution - Short Program Name Suspicious MS Office Child Process Suspicious MS Outlook Child Process Suspicious Managed Code Hosting Process Suspicious PDF Reader Child Process Suspicious Powershell Script Suspicious PrintSpooler SPL File Created Refer to CVEs, CVE-2020-1048 and CVE-2020-1337 for further information on the vulnerability and exploit. Verify that the relevant system is patched. Suspicious PrintSpooler Service Executable File Creation Suspicious Process Execution via Renamed PsExec Executable Suspicious Process from Conhost Suspicious WMIC XSL Script Execution Suspicious WerFault Child Process Suspicious Zoom Child Process Svchost spawning Cmd System Shells via Services TCP Port 8000 Activity to the Internet Telnet Port Activity Threat Detected by Okta ThreatInsight The Okta Filebeat module must be enabled to use this rule. Tor Activity to the Internet Trusted Developer Application Usage UAC Bypass Attempt via Elevated COM Internet Explorer Add-On Installer UAC Bypass via DiskCleanup Scheduled Task Hijack Unusual AWS Command for a User ### Investigating an Unusual CloudTrail Event ### Detection alerts from this rule indicate an AWS API command or method call that is rare and unusual for the calling IAM user. Here are some possible avenues of investigation: - Consider the user as identified by the `user.name` field. Is this command part of an expected workflow for the user context? Examine the user identity in the `aws.cloudtrail.user_identity.arn` field and the access key id in the `aws.cloudtrail.user_identity.access_key_id` field which can help identify the precise user context. The user agent details in the `user_agent.original` field may also indicate what kind of a client made the request. - Consider the source IP address and geolocation for the calling user who issued the command. Do they look normal for the calling user? If the source is an EC2 IP address, is it associated with an EC2 instance in one of your accounts or could it be sourcing from an EC2 instance not under your control? If it is an authorized EC2 instance, is the activity associated with normal behavior for the instance role or roles? Are there any other alerts or signs of suspicious activity involving this instance? - Consider the time of day. If the user is a human, not a program or script, did the activity take place during a normal time of day? - Examine the history of the command. If the command, which is visible in the `event.action field`, manifested only very recently, it might be part of a new automation module or script. If it has a consistent cadence - for example, if it appears in small numbers on a weekly or monthly cadence it might be part of a housekeeping or maintenance process. - Examine the request parameters. These may provide indications as to the source of the program or the nature of the tasks it is performing. Unusual Child Process from a System Virtual Process Unusual Child Process of dns.exe ### Investigating Unusual Child Process Detection alerts from this rule indicate potential suspicious child processes spawned after exploitation from CVE-2020-1350 (SigRed) has occurred. Here are some possible avenues of investigation: - Any suspicious or abnormal child process spawned from dns.exe should be reviewed and investigated with care. It's impossible to predict what an adversary may deploy as the follow-on process after the exploit, but built-in discovery/enumeration utilities should be top of mind (whoami.exe, netstat.exe, systeminfo.exe, tasklist.exe). - Built-in Windows programs that contain capabilities used to download and execute additional payloads should also be considered. This is not an exhaustive list, but ideal candidates to start out would be: mshta.exe, powershell.exe, regsvr32.exe, rundll32.exe, wscript.exe, wmic.exe. - If the DoS exploit is successful and DNS Server service crashes, be mindful of potential child processes related to werfault.exe occurring. - Any subsequent activity following the child process spawned related to execution/network activity should be thoroughly reviewed from the endpoint. Unusual Child Processes of RunDLL32 Unusual City For an AWS Command ### Investigating an Unusual CloudTrail Event ### Detection alerts from this rule indicate an AWS API command or method call that is rare and unusual for the geolocation of the source IP address. Here are some possible avenues of investigation: - Consider the source IP address and geolocation for the calling user who issued the command. Do they look normal for the calling user? If the source is an EC2 IP address, is it associated with an EC2 instance in one of your accounts or could it be sourcing from an EC2 instance not under your control? If it is an authorized EC2 instance, is the activity associated with normal behavior for the instance role or roles? Are there any other alerts or signs of suspicious activity involving this instance? - Consider the user as identified by the `user.name` field. Is this command part of an expected workflow for the user context? Examine the user identity in the `aws.cloudtrail.user_identity.arn` field and the access key id in the `aws.cloudtrail.user_identity.access_key_id` field which can help identify the precise user context. The user agent details in the `user_agent.original` field may also indicate what kind of a client made the request. - Consider the time of day. If the user is a human, not a program or script, did the activity take place during a normal time of day? - Examine the history of the command. If the command, which is visible in the `event.action field`, manifested only very recently, it might be part of a new automation module or script. If it has a consistent cadence - for example, if it appears in small numbers on a weekly or monthly cadence it might be part of a housekeeping or maintenance process. - Examine the request parameters. These may provide indications as to the source of the program or the nature of the tasks it is performing. Unusual Country For an AWS Command ### Investigating an Unusual CloudTrail Event ### Detection alerts from this rule indicate an AWS API command or method call that is rare and unusual for the geolocation of the source IP address. Here are some possible avenues of investigation: - Consider the source IP address and geolocation for the calling user who issued the command. Do they look normal for the calling user? If the source is an EC2 IP address, is it associated with an EC2 instance in one of your accounts or could it be sourcing from an EC2 instance not under your control? If it is an authorized EC2 instance, is the activity associated with normal behavior for the instance role or roles? Are there any other alerts or signs of suspicious activity involving this instance? - Consider the user as identified by the `user.name` field. Is this command part of an expected workflow for the user context? Examine the user identity in the `aws.cloudtrail.user_identity.arn` field and the access key id in the `aws.cloudtrail.user_identity.access_key_id` field which can help identify the precise user context. The user agent details in the `user_agent.original` field may also indicate what kind of a client made the request. - Consider the time of day. If the user is a human, not a program or script, did the activity take place during a normal time of day? - Examine the history of the command. If the command, which is visible in the `event.action field`, manifested only very recently, it might be part of a new automation module or script. If it has a consistent cadence - for example, if it appears in small numbers on a weekly or monthly cadence it might be part of a housekeeping or maintenance process. - Examine the request parameters. These may provide indications as to the source of the program or the nature of the tasks it is performing. Unusual DNS Activity Unusual Executable File Creation by a System Critical Process Unusual File Modification by dns.exe ### Investigating Unusual File Write Detection alerts from this rule indicate potential unusual/abnormal file writes from the DNS Server service process (`dns.exe`) after exploitation from CVE-2020-1350 (SigRed) has occurred. Here are some possible avenues of investigation: - Post-exploitation, adversaries may write additional files or payloads to the system as additional discovery/exploitation/persistence mechanisms. - Any suspicious or abnormal files written from `dns.exe` should be reviewed and investigated with care. Unusual Linux Network Activity ### Investigating Unusual Network Activity ### Detection alerts from this rule indicate the presence of network activity from a Linux process for which network activity is rare and unusual. Here are some possible avenues of investigation: - Consider the IP addresses and ports. Are these used by normal but infrequent network workflows? Are they expected or unexpected? - If the destination IP address is remote or external, does it associate with an expected domain, organization or geography? Note: avoid interacting directly with suspected malicious IP addresses. - Consider the user as identified by the username field. Is this network activity part of an expected workflow for the user who ran the program? - Examine the history of execution. If this process manifested only very recently, it might be part of a new software package. If it has a consistent cadence - for example if it runs monthly or quarterly - it might be part of a monthly or quarterly business or maintenance process. - Examine the process arguments, title and working directory. These may provide indications as to the source of the program or the nature of the tasks it is performing. Unusual Linux Network Connection Discovery Unusual Linux Network Port Activity Unusual Linux Network Service Unusual Linux Process Calling the Metadata Service Unusual Linux Process Discovery Activity Unusual Linux System Information Discovery Activity Unusual Linux System Network Configuration Discovery Unusual Linux System Owner or User Discovery Activity Unusual Linux User Calling the Metadata Service Unusual Linux Username ### Investigating an Unusual Linux User ### Detection alerts from this rule indicate activity for a Linux user name that is rare and unusual. Here are some possible avenues of investigation: - Consider the user as identified by the username field. Is this program part of an expected workflow for the user who ran this program on this host? Could this be related to troubleshooting or debugging activity by a developer or site reliability engineer? - Examine the history of user activity. If this user manifested only very recently, it might be a service account for a new software package. If it has a consistent cadence - for example if it runs monthly or quarterly - it might be part of a monthly or quarterly business process. - Examine the process arguments, title and working directory. These may provide indications as to the source of the program or the nature of the tasks that the user is performing. Unusual Linux Web Activity Unusual Login Activity Unusual Network Activity from a Windows System Binary Unusual Network Connection Sequence via RunDLL32 Unusual Network Connection via RunDLL32 Unusual Network Destination Domain Name Unusual Parent Process for cmd.exe Unusual Parent-Child Relationship Unusual Process Execution - Temp Unusual Process For a Linux Host ### Investigating an Unusual Linux Process ### Detection alerts from this rule indicate the presence of a Linux process that is rare and unusual for the host it ran on. Here are some possible avenues of investigation: - Consider the user as identified by the username field. Is this program part of an expected workflow for the user who ran this program on this host? - Examine the history of execution. If this process manifested only very recently, it might be part of a new software package. If it has a consistent cadence - for example if it runs monthly or quarterly - it might be part of a monthly or quarterly business process. - Examine the process arguments, title and working directory. These may provide indications as to the source of the program or the nature of the tasks it is performing. Unusual Process For a Windows Host ### Investigating an Unusual Windows Process ### Detection alerts from this rule indicate the presence of a Windows process that is rare and unusual for the host it ran on. Here are some possible avenues of investigation: - Consider the user as identified by the username field. Is this program part of an expected workflow for the user who ran this program on this host? - Examine the history of execution. If this process manifested only very recently, it might be part of a new software package. If it has a consistent cadence - for example if it runs monthly or quarterly - it might be part of a monthly or quarterly business process. - Examine the process metadata like the values of the Company, Description and Product fields which may indicate whether the program is associated with an expected software vendor or package. - Examine arguments and working directory. These may provide indications as to the source of the program or the nature of the tasks it is performing. - Consider the same for the parent process. If the parent process is a legitimate system utility or service, this could be related to software updates or system management. If the parent process is something user-facing like an Office application, this process could be more suspicious. - If you have file hash values in the event data, and you suspect malware, you can optionally run a search for the file hash to see if the file is identified as malware by anti-malware tools. Unusual Process Network Connection Unusual Sudo Activity Unusual Web Request Unusual Web User Agent Unusual Windows Network Activity ### Investigating Unusual Network Activity ### Detection alerts from this rule indicate the presence of network activity from a Windows process for which network activity is very unusual. Here are some possible avenues of investigation: - Consider the IP addresses, protocol and ports. Are these used by normal but infrequent network workflows? Are they expected or unexpected? - If the destination IP address is remote or external, does it associate with an expected domain, organization or geography? Note: avoid interacting directly with suspected malicious IP addresses. - Consider the user as identified by the username field. Is this network activity part of an expected workflow for the user who ran the program? - Examine the history of execution. If this process manifested only very recently, it might be part of a new software package. If it has a consistent cadence - for example if it runs monthly or quarterly - it might be part of a monthly or quarterly business process. - Examine the process arguments, title and working directory. These may provide indications as to the source of the program or the nature of the tasks it is performing. - Consider the same for the parent process. If the parent process is a legitimate system utility or service, this could be related to software updates or system management. If the parent process is something user-facing like an Office application, this process could be more suspicious. - If you have file hash values in the event data, and you suspect malware, you can optionally run a search for the file hash to see if the file is identified as malware by anti-malware tools. Unusual Windows Path Activity Unusual Windows Process Calling the Metadata Service Unusual Windows Remote User ### Investigating an Unusual Windows User ### Detection alerts from this rule indicate activity for a rare and unusual Windows RDP (remote desktop) user. Here are some possible avenues of investigation: - Consider the user as identified by the username field. Is the user part of a group who normally logs into Windows hosts using RDP (remote desktop protocol)? Is this logon activity part of an expected workflow for the user? - Consider the source of the login. If the source is remote, could this be related to occasional troubleshooting or support activity by a vendor or an employee working remotely? Unusual Windows Service Unusual Windows User Calling the Metadata Service Unusual Windows User Privilege Elevation Activity Unusual Windows Username ### Investigating an Unusual Windows User ### Detection alerts from this rule indicate activity for a Windows user name that is rare and unusual. Here are some possible avenues of investigation: - Consider the user as identified by the username field. Is this program part of an expected workflow for the user who ran this program on this host? Could this be related to occasional troubleshooting or support activity? - Examine the history of user activity. If this user manifested only very recently, it might be a service account for a new software package. If it has a consistent cadence - for example if it runs monthly or quarterly - it might be part of a monthly or quarterly business process. - Examine the process arguments, title and working directory. These may provide indications as to the source of the program or the nature of the tasks that the user is performing. - Consider the same for the parent process. If the parent process is a legitimate system utility or service, this could be related to software updates or system management. If the parent process is something user-facing like an Office application, this process could be more suspicious. User Account Creation User Added as Owner for Azure Application The Azure Filebeat module must be enabled to use this rule. User Added as Owner for Azure Service Principal The Azure Filebeat module must be enabled to use this rule. User Discovery via Whoami VNC (Virtual Network Computing) from the Internet VNC (Virtual Network Computing) to the Internet Virtual Machine Fingerprinting Volume Shadow Copy Deletion via VssAdmin Volume Shadow Copy Deletion via WMIC WPAD Service Exploit Web Application Suspicious Activity: No User Agent Web Application Suspicious Activity: POST Request Declined Web Application Suspicious Activity: Unauthorized Method Web Application Suspicious Activity: sqlmap User Agent Whoami Process Activity Windows CryptoAPI Spoofing Vulnerability (CVE-2020-0601 - CurveBall) Windows Script Executing PowerShell Windows Suspicious Script Object Execution Zoom Meeting with no Passcode This rule requires the Zoom Filebeat module. ======================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================= (venv37) jibarra@jibarra-mbp detection-rules-fork % ```
randomuserid commented 3 years ago

So the field was meant to contain an investigation playbook that is generic enough to be useful, at least as a starting point, across the user base. Moving information like required events or data types into another field, or the description, is a good idea. I would not enforce a static set of sections across the rule base for the sake of consistent appearance. There will not be a universally relevant set of fields, across rules and playbooks, so this would not necessarily improve UX. In the examples above, CVEs are not relevant to several types of rules. Threat Intel is not relevant to other types. I think writing a "response and remediation" section at the alert level would be problematic because appropriate response depends greatly of the size and scope of the intrusion set, which often requires consideration of incidents in toto which often includes many related alerts or detects and their context. Appropriate response also depends in part of the affected asset value and the risk appetite of the organization. I'd stop short of prescribing remediation and leave that to the analyst, and their constituents.

rw-access commented 3 years ago

I don't think it is necessary to over formalize it by enforcing strict verbiage guidelines, so much as to maintain consistent markdown, fields, and ordering.

There will not be a universally relevant set of fields, across rules and playbooks, so this would not necessarily improve UX.

I think in general we tend to do a good job with not forcing something when it no longer works. I think the issue isn't meant to make us restrictive, but to make us consistent whenever possible. Consistency is one aspect of a good UX.

threat-punter commented 3 years ago

Thanks for starting this conversation, @brokensound77. My recommendation would be to start with a Triage section in the notes field and build upon this to include Analysis/Investigation and Respond sections later.

When I built a SOC at a previous company, I helped create and document some of our own processes, but much of what we did was aligned to NIST's Cybersecurity Framework (Identify ➡ Protect ➡ Detect ➡ Respond ➡ Recover) and their Computer Security Incident Handling Guide. This provided the team with a shared nomenclature to communicate effectively and helped us document our processes for triage, investigation, and response.

A repeatable triage process helps analysts categorize, correlate, and prioritize events and assign them to someone for further investigation and response as needed.

If we start out by providing a generic triage process (or better yet, a customizable one) linked to our rules, I think this will help analysts (especially those with less experience) pick up an alert and find the answer to questions like when the file/network activity was first observed or how many assets on the network are affected.

Once we have established a generic triage process or a process per platform type, we could move on to create a section for suggested Analysis/Investigation steps and then a recommended Response actions section, although these steps will be different for every organization. Giving users the ability to customize these sections would be great. I can visualize a SOC storing their response playbooks in Elastic Security using checklists and storing artifacts in the case management section.

randomuserid commented 3 years ago

I think triage necessarily includes some amount of analysis and often some live response in order to consider an alert in its context, in conjunction with other informative data points, and sometimes with other alerts, in order to make a determination as to the criticality, severity, risk level, and priority of an alert or set of like alerts. At the same time, the field is meant to be a jump-start to investigation in addition to triage. It is intended especially for users who may not have triage or investigation processes at their fingertips, especially with new alert classes like the anomalies. I wrote the guides in the notes field to be as generic as possible with a variety of steps an analyst could take depending on their local TTPs. Let's continue writing these kinds of generic, widely relevant triage & investigation guides I'd really like to avoid adopting a specific framework for these because no one framework is something that everyone can or will use.

threat-punter commented 3 years ago

Let's continue writing these kinds of generic, widely relevant triage & investigation guides I'd really like to avoid adopting a specific framework for these because no one framework is something that everyone can or will use

I think it's still an open discussion at this point. My suggestion is not to follow any framework to a T.

austinsonger commented 3 years ago

Let's continue writing these kinds of generic, widely relevant triage & investigation guides I'd really like to avoid adopting a specific framework for these because no one framework is something that everyone can or will use

I think it's still an open discussion at this point. My suggestion is not to follow any framework to a T.

Or Elastic could develop their own "Framework" 😀 But starting with NIST would be the best place to start with.

brokensound77 commented 3 years ago

After some internal discussion, it was decided to implement some structure to the field in phases. For now, starting with a triage and analysis and threat intel section. Rules which do not have these populated, will not add empty section headers.

Also as an interim solution, until there is a dedicated config field in kibana, that information will reside under a header of the same name

botelastic[bot] commented 3 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

brokensound77 commented 3 years ago

This has been applied to some rules. Discussions continue around what should be of value from a static perspective within the note field vs other options

botelastic[bot] commented 2 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

botelastic[bot] commented 2 years ago

This has been closed due to inactivity. If you feel this is an error, please re-open and include a justifying comment.

brokensound77 commented 2 years ago

The discussions around this field continue to evolve around internal discussions. I will leave this close and open any new issues as needed