Update v8.19.14
editUpdate v8.19.14
editThis section lists all updates associated with version 8.19.14 of the Fleet integration Prebuilt Security Detection Rules.
| Rule | Description | Status | Version |
|---|---|---|---|
Identifies suspicious Java file creation in the IRJ directory of the SAP NetWeaver application. This may indicate an attempt to deploy a webshell. |
new |
1 |
|
Identifies suspicious processes spawned from the SAP NetWeaver application. This may indicate an attempt to execute commands via webshell. |
new |
1 |
|
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. |
new |
2 |
|
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. |
new |
2 |
|
Lateral Movement Alerts from a Newly Observed Source Address |
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. |
new |
2 |
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. |
new |
2 |
|
This alert identifies assets with an elevated number of vulnerabilities reported by Wiz, potentially indicating weak security posture, missed patching, or active exposure. The rule highlights assets with a high volume of distinct vulnerabilities, the presence of exploitable vulnerabilities, or a combination of multiple severities, helping prioritize assets that pose increased risk. |
new |
2 |
|
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. |
new |
2 |
|
This rule detects Palo Alto Network 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. |
new |
2 |
|
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. |
new |
2 |
|
Identifies potential exploitation of a Telnet remote authentication bypass vulnerability (CVE-2026-24061) in GNU Inetutils telnetd. The vulnerability allows unauthenticated access by supplying a crafted |
new |
1 |
|
Identifies potential exploitation of a Telnet remote authentication bypass vulnerability (CVE-2026-24061) in GNU Inetutils telnetd. The vulnerability allows unauthenticated access by supplying a crafted |
new |
1 |
|
This detection correlates Suricata alerts with Elastic Defend network events to identify the source process performing the network activity. |
update |
2 |
|
This rule detects authenticated sessions accessing secret stores across multiple cloud providers from the same source address within a short period of time. Adversaries with access to compromised credentials or session tokens may attempt to retrieve secrets from services such as AWS Secrets Manager, Google Secret Manager, or Azure Key Vault in rapid succession to expand their access or exfiltrate sensitive information. |
update |
4 |
|
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. |
update |
3 |
|
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. |
update |
5 |
|
This rule detects Elastic Defend behavior alerts that are observed for the first time today when compared against 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. |
update |
3 |
|
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. |
update |
3 |
|
Detects creation of a new AWS CloudTrail trail via CreateTrail API. While legitimate during onboarding or auditing improvements, adversaries can create trails that write to attacker-controlled destinations, limit regions, or otherwise subvert monitoring objectives. New trails should be validated for destination ownership, encryption, multi-region coverage, and organizational scope. |
update |
212 |
|
Identifies AWS CloudTrail events where an unauthenticated source is attempting to access an S3 bucket. This activity may indicate a misconfigured S3 bucket policy that allows public access to the bucket, potentially exposing sensitive data to unauthorized users. Adversaries can specify --no-sign-request in the AWS CLI to retrieve objects from an S3 bucket without authentication. This is a New Terms rule, which means it will trigger for each unique combination of the source.address and targeted bucket name that has not been seen making this API request. |
update |
7 |
|
Identifies the addition of a user to a specified group in AWS Identity and Access Management (IAM). Any user added to a group automatically gains the permissions that are assigned to the group. If the target group carries elevated or admin privileges, this action can instantly grant high-risk permissions useful for credential misuse, lateral movement, or privilege escalation. |
update |
213 |
|
First Time Seen AWS Secret Value Accessed in Secrets Manager |
An adversary with access to a compromised AWS service such as an EC2 instance, Lambda function, or other service may attempt to leverage the compromised service to access secrets in AWS Secrets Manager. This rule looks for the first time a specific user identity has programmatically retrieved a secret value from Secrets Manager using the GetSecretValue action. This rule assumes that AWS services such as Lambda functions and EC2 instances are setup with IAM role’s assigned that have the necessary permissions to access the secrets in Secrets Manager. An adversary with access to a compromised AWS service would rely on its' attached role to access the secrets in Secrets Manager. |
update |
318 |
AWS Systems Manager SecureString Parameter Request with Decryption Flag |
Detects the first occurrence of a user identity accessing AWS Systems Manager (SSM) SecureString parameters using the GetParameter or GetParameters API actions with credentials in the request parameters. This could indicate that the user is accessing sensitive information. This rule detects when a user accesses a SecureString parameter with the withDecryption parameter set to true. This is a New Terms rule that detects the first occurrence of an AWS identity accessing SecureString parameters with decryption. |
update |
8 |
Identifies a high number of failed authentication attempts to the AWS management console for the Root user identity. An adversary may attempt to brute force the password for the Root user identity, as it has complete access to all services and resources for the AWS account. |
update |
212 |
|
Detects deletion of an AWS CloudTrail trail via DeleteTrail API. Removing trails is a high-risk action that destroys an audit control plane and is frequently paired with other destructive or stealthy operations. Validate immediately and restore compliant logging. |
update |
214 |
|
Identifies the evasion of cloudtrail logging for IAM actions involving policy creation, modification or attachment. When making certain policy-related API calls, an adversary may pad the associated policy document with whitespaces to trigger CloudTrail’s logging size constraints, resulting in incomplete logging where critical details about the policy are omitted. By exploiting this gap, threat actors can bypass monitoring performed through CloudTrail and can effectively obscure unauthorized changes. This rule looks for IAM API calls with the requestParameters property containing reason:”requestParameters too large” and omitted:true. |
update |
2 |
|
Detects Cloudtrail logging suspension via StopLogging API. Stopping CloudTrail eliminates forward audit visibility and is a classic defense evasion step before sensitive changes or data theft. Investigate immediately and determine what occurred during the logging gap. |
update |
213 |
|
Detects the deletion of one or more Amazon CloudWatch alarms using the "DeleteAlarms" API. CloudWatch alarms are critical for monitoring metrics and triggering alerts when thresholds are exceeded. An adversary may delete alarms to impair visibility, silence alerts, and evade detection following malicious activity. This behavior may occur during post-exploitation or cleanup phases to remove traces of compromise or disable automated responses. |
update |
213 |
|
Identifies attempts to delete AWS Config resources. AWS Config provides continuous visibility into resource configuration changes and compliance posture across an account. Deleting Config components can significantly reduce security visibility and auditability. Adversaries may delete or disable Config resources to evade detection, hide prior activity, or weaken governance controls before or after other malicious actions. |
update |
213 |
|
Identifies when an AWS Config configuration recorder is stopped. AWS Config recorders continuously track and record configuration changes across supported AWS resources. Stopping the recorder immediately reduces visibility into infrastructure changes and can be abused by adversaries to evade detection, obscure follow-on activity, or weaken compliance and security monitoring controls. |
update |
211 |
|
Identifies the deletion of an Amazon Elastic Compute Cloud (EC2) network access control list (ACL) or one of its ingress/egress entries. |
update |
211 |
|
Detects the deletion of an Amazon GuardDuty detector. GuardDuty provides continuous monitoring for malicious or unauthorized activity across AWS accounts. Deleting the detector disables this visibility, stopping all threat detection and removing existing findings. Adversaries may delete GuardDuty detectors to impair security monitoring and evade detection during or after an intrusion. This rule identifies successful "DeleteDetector" API calls and can indicate a deliberate defense evasion attempt. |
update |
211 |
|
Identifies the restoration of an AWS RDS database instance from a snapshot or S3 backup. Adversaries with access to valid credentials may restore copies of existing databases to bypass logging and monitoring controls or to exfiltrate sensitive data from a duplicated environment. This rule detects successful restoration operations using "RestoreDBInstanceFromDBSnapshot" or "RestoreDBInstanceFromS3", which may indicate unauthorized data access or post-compromise defense evasion. |
update |
212 |
|
Identifies the deletion of an Amazon Route 53 Resolver Query Log Configuration. Resolver query logs provide critical visibility into DNS activity across VPCs, including lookups made by EC2 instances, containers, Lambda functions, and other AWS resources. Deleting a query log configuration immediately stops DNS query and response logging for the associated VPC. Adversaries may delete these configurations to evade detection, suppress forensic evidence, or degrade security monitoring capabilities. |
update |
7 |
|
Identifies the deletion of critical Amazon S3 bucket configurations such as bucket policies, lifecycle configurations or encryption settings. These actions are typically administrative but may also represent adversarial attempts to remove security controls, disable data retention mechanisms, or conceal evidence of malicious activity. Adversaries who gain access to AWS credentials may delete logging, lifecycle, or policy configurations to disrupt forensic visibility and inhibit recovery. For example, deleting a bucket policy can open a bucket to public access or remove protective access restrictions, while deleting lifecycle rules can prevent object archival or automatic backups. Such actions often precede data exfiltration or destructive operations and should be reviewed in context with related S3 or IAM events. |
update |
212 |
|
Identifies the addition of an expiration lifecycle configuration to an Amazon S3 bucket. S3 lifecycle rules can automatically delete or transition objects after a defined period. Adversaries can abuse them by configuring auto-deletion of logs, forensic evidence, or sensitive objects to cover their tracks. This rule detects the use of the PutBucketLifecycle or PutBucketLifecycleConfiguration APIs with Expiration parameters, which may indicate an attempt to automate the removal of data to hinder investigation or maintain operational secrecy after malicious activity. |
update |
7 |
|
Identifies when server access logging is disabled for an Amazon S3 bucket. Server access logs provide a detailed record of requests made to an S3 bucket. When server access logging is disabled for a bucket, it could indicate an adversary’s attempt to impair defenses by disabling logs that contain evidence of malicious activity. |
update |
6 |
|
Identifies when an AWS Simple Queue Service (SQS) queue is purged. Purging an SQS queue permanently deletes all messages currently in the queue. Adversaries may use this action to disrupt application workflows, destroy operational data, or impair monitoring and alerting by removing messages that contain evidence of malicious activity. |
update |
6 |
|
AWS First Occurrence of STS GetFederationToken Request by User |
Identifies the first occurrence of an AWS Security Token Service (STS) GetFederationToken request made by a user. The GetFederationToken API call allows users to request temporary security credentials to access AWS resources. The maximum expiration period for these tokens is 36 hours and they can be used to create a console signin token even for identities that don’t already have one. Adversaries may use this API to obtain temporary credentials for persistence and to bypass IAM API call limitations by gaining console access. |
update |
6 |
Identifies the deletion of an AWS Web Application Firewall (WAF) Web ACL. Web ACLs are the core enforcement objects in AWS WAF, defining which traffic is inspected, allowed, or blocked for protected applications. Deleting a Web ACL removes all associated rules, protections, and logging configurations. Adversaries who obtain sufficient privileges may delete a Web ACL to disable critical security controls, evade detection, or prepare for downstream attacks such as web-application compromise, data theft, or resource abuse. Because Web ACLs are rarely deleted outside of controlled maintenance or infrastructure updates, unexpected deletions may indicate potential defense evasion. |
update |
211 |
|
Identifies the deletion of an AWS Web Application Firewall (WAF) rule or rule group. WAF rules and rule groups enforce critical protections for web applications by filtering malicious HTTP requests, blocking known attack patterns, and enforcing access controls. Deleting these rules—even briefly—can expose applications to SQL injection, cross-site scripting, credential-stuffing bots, or targeted exploitation. Adversaries who have gained sufficient permissions may remove WAF protections as part of a broader defense evasion or impact strategy, often preceding data theft or direct application compromise. |
update |
211 |
|
Identifies when a user has queried for deprecated Amazon Machine Images (AMIs) in AWS. This may indicate an adversary looking for outdated AMIs that may be vulnerable to exploitation. While deprecated AMIs are not inherently malicious or indicative of a breach, they may be more susceptible to vulnerabilities and should be investigated for potential security risks. |
update |
7 |
|
Detects repeated failed attempts to update an IAM role’s trust policy in an AWS account, consistent with role and user enumeration techniques. In this technique, an attacker who controls credentials in the current account repeatedly calls UpdateAssumeRolePolicy on a single role, cycling through guessed cross-account role or user ARNs as the principal. When those principals are invalid, IAM returns MalformedPolicyDocumentException, producing a burst of failed UpdateAssumeRolePolicy events. This rule alerts on that brute-force pattern originating from this account, which may indicate that the account is being used as attack infrastructure or that offensive tooling (such as Pacu) is running here. Note: this rule does not detect other accounts enumerating roles, because those API calls are logged in the caller’s account, not the target account. |
update |
214 |
|
Detects when a single AWS resource is running multiple read-only, discovery API calls in a 10-second window. This behavior could indicate an actor attempting to discover the AWS infrastructure using compromised credentials or a compromised instance. Adversaries may use this information to identify potential targets for further exploitation or to gain a better understanding of the target’s infrastructure. |
update |
7 |
|
Identifies when a single AWS principal makes GetServiceQuota API calls for the EC2 service quota L-1216C47A, across more than 10 AWS regions within a 30-second window. This quota represents the vCPU limit for on-demand EC2 instances. Adversaries commonly enumerate this quota across regions to assess capacity for large-scale instance deployment, including cryptocurrency mining, malware hosting, or command-and-control infrastructure. This behavior may indicate cloud infrastructure discovery using compromised credentials or a compromised workload. |
update |
8 |
|
Identifies when a Lambda layer is added to an existing AWS Lambda function. Lambda layers allow shared code, dependencies, or runtime modifications to be injected into a function’s execution environment. Adversaries with the ability to update function configurations may add a malicious layer to establish persistence, run unauthorized code, or intercept data handled by the function. This activity should be reviewed to ensure the modification is expected and authorized. |
update |
7 |
|
This rule detects the first time a principal calls AWS CloudFormation CreateStack, CreateStackSet or CreateStackInstances API. CloudFormation is used to create a collection of cloud resources called a stack, via a defined template file. An attacker with the appropriate privileges could leverage CloudFormation to create specific resources needed to further exploit the environment. This is a new terms rule that looks for the first instance of this behavior for a role or IAM user within a particular account. |
update |
6 |
|
Detects when an Amazon Elastic Block Store (EBS) snapshot is shared with another AWS account or made public. EBS snapshots contain copies of data volumes that may include sensitive or regulated information. Adversaries may exploit ModifySnapshotAttribute to share snapshots with external accounts or the public, allowing them to copy and access data in an environment they control. This activity often precedes data exfiltration or persistence operations, where the attacker transfers stolen data out of the victim account or prepares a staging area for further exploitation. |
update |
9 |
|
Identifies successful export tasks of EC2 instances via the APIs CreateInstanceExportTask, ExportImage, or CreateStoreImageTask. These exports can be used by administrators for legitimate VM migration or backup workflows however, an attacker with access to an EC2 instance or AWS credentials can export a VM or its image and then transfer it off-account for exfiltration of data. |
update |
2 |
|
Detects successful creation of an Amazon EC2 Traffic Mirroring session. A session copies full packets from a source Elastic Network Interface (ENI) to a mirror target (e.g., an ENI or NLB) using a mirror filter (ingress/egress rules). While used for diagnostics and NDR/IDS tooling, adversaries can abuse sessions to covertly capture and exfiltrate sensitive, potentially unencrypted, traffic from instances or subnets. |
update |
211 |
|
Identifies the export of a DB snapshot or DB cluster data to Amazon S3. Snapshot exports can be used for analytics or migration workflows, but adversaries may abuse them to exfiltrate sensitive data outside of RDS-managed storage. Exporting a snapshot creates a portable copy of the database contents, which, if performed without authorization, can indicate data theft, staging for exfiltration, or operator misconfiguration that exposes regulated information. |
update |
211 |
|
Identifies when an AWS RDS DB snapshot is shared with another AWS account or made public. DB snapshots contain complete backups of database instances, including schemas, table data, and sensitive application content. When shared externally, snapshots can be restored in another AWS environment, enabling unauthorized access, offline analysis, or data exfiltration. Adversaries who obtain valid credentials or exploit misconfigurations may modify snapshot attributes to grant access to accounts they control, bypassing network, IAM, and monitoring controls. |
update |
7 |
|
Detects when an Amazon S3 bucket policy is modified to share access with an external AWS account. This rule analyzes PutBucketPolicy events and compares the S3 bucket’s account ID to any account IDs referenced in the policy’s Effect=Allow statements. If the policy includes principals from accounts other than the bucket owner’s, the rule triggers an alert. This behavior may indicate an adversary backdooring a bucket for data exfiltration or cross-account persistence. For example, an attacker who compromises credentials could attach a policy allowing access from an external AWS account they control, enabling continued access even after credentials are rotated. Note: This rule will not alert if the account ID is part of the bucket’s name or appears in the resource ARN. Such cases are common in standardized naming conventions (e.g., “mybucket-123456789012”). To ensure full coverage, use complementary rules to monitor for suspicious PutBucketPolicy API requests targeting buckets with account IDs embedded in their names or resources. |
update |
8 |
|
Detects when an Amazon S3 bucket policy is modified to grant public access using a wildcard (Principal:"") statement. This rule analyzes PutBucketPolicy events that include both Effect=Allow and Principal:"" in the request parameters, indicating that permissions were extended to all identities, potentially making the bucket or its contents publicly accessible. Publicly exposing an S3 bucket is one of the most common causes of sensitive data leaks in AWS environments. Adversaries or misconfigurations can leverage this exposure to exfiltrate data, host malicious content, or collect credentials and logs left in open storage. |
update |
2 |
|
Identifies the creation or modification of an S3 bucket replication configuration that sends data to a bucket in a different AWS account. Cross-account replication can be used legitimately for backup, disaster recovery, and multi-account architectures, but adversaries with write access to an S3 bucket may abuse replication rules to silently exfiltrate large volumes of data to attacker-controlled accounts. This rule detects "PutBucketReplication" events where the configured destination account differs from the source bucket’s account, indicating potential unauthorized cross-account data movement. |
update |
6 |
|
Identifies when a use subscribes to an SNS topic using a new protocol type (ie. email, http, lambda, etc.). SNS allows users to subscribe to recieve topic messages across a broad range of protocols like email, sms, lambda functions, http endpoints, and applications. Adversaries may subscribe to an SNS topic to collect sensitive information or exfiltrate data via an external email address, cross-account AWS service or other means. This rule identifies a new protocol subscription method for a particular user. |
update |
8 |
|
Identifies when an Amazon EventBridge rule is disabled or deleted. EventBridge rules are commonly used to automate operational workflows and security-relevant routing (for example, forwarding events to Lambda, SNS/SQS, or security tooling). Disabling or deleting a rule can break critical integrations, suppress detections, and reduce visibility. Adversaries may intentionally impair EventBridge rules to disrupt monitoring, delay response, or hide follow-on actions. |
update |
211 |
|
Identifies a high number of failed S3 operations against a single bucket from a single source address within a short timeframe. This activity can indicate attempts to collect bucket objects or cause an increase in billing to an account via internal "AccessDenied" errors. |
update |
7 |
|
Detects updates to an existing CloudTrail trail via UpdateTrail API which may reduce visibility, change destinations, or weaken integrity (e.g., removing global events, moving the S3 destination, or disabling validation). Adversaries can modify trails to evade detection while maintaining a semblance of logging. Validate any configuration change against approved baselines. |
update |
213 |
|
Detects the deletion of an Amazon CloudWatch Log Group using the "DeleteLogGroup" API. CloudWatch log groups store operational and security logs for AWS services and custom applications. Deleting a log group permanently removes all associated log streams and historical log data, which can eliminate forensic evidence and disrupt security monitoring pipelines. Adversaries may delete log groups to conceal malicious activity, disable log forwarding, or impede incident response. |
update |
213 |
|
Detects the deletion of an Amazon CloudWatch log stream using the "DeleteLogStream" API. Deleting a log stream permanently removes its associated log events and may disrupt security visibility, break audit trails, or suppress forensic evidence. Adversaries may delete log streams to conceal malicious actions, impair monitoring pipelines, or remove artifacts generated during post-exploitation activity. |
update |
213 |
|
Detects when Amazon Elastic Block Store (EBS) encryption by default is disabled in an AWS region. EBS encryption ensures that newly created volumes and snapshots are automatically protected with AWS Key Management Service (KMS) keys. Disabling this setting introduces significant risk as all future volumes created in that region will be unencrypted by default, potentially exposing sensitive data at rest. Adversaries may disable encryption to weaken data protection before exfiltrating or tampering with EBS volumes or snapshots. This may be a step in preparation for data theft or ransomware-style attacks that depend on unencrypted volumes. |
update |
211 |
|
Identifies the removal of access permissions from a shared AWS EC2 EBS snapshot. EBS snapshots are essential for data retention and disaster recovery. Adversaries may revoke or modify snapshot permissions to prevent legitimate users from accessing backups, thereby obstructing recovery efforts after data loss or destructive actions. This tactic can also be used to evade detection or maintain exclusive access to critical backups, ultimately increasing the impact of an attack and complicating incident response. |
update |
5 |
|
Identifies the deletion of an Amazon EFS file system using the "DeleteFileSystem" API operation. Deleting an EFS file system permanently removes all stored data and cannot be reversed. This action is rare in most environments and typically limited to controlled teardown workflows. Adversaries with sufficient permissions may delete a file system to destroy evidence, disrupt workloads, or impede recovery efforts. |
update |
211 |
|
Detects the deactivation of a Multi-Factor Authentication (MFA) device in AWS Identity and Access Management (IAM). MFA provides critical protection against unauthorized access by requiring a second factor for authentication. Adversaries or compromised administrators may deactivate MFA devices to weaken account protections, disable strong authentication, or prepare for privilege escalation or persistence. This rule monitors successful DeactivateMFADevice API calls, which represent the point at which MFA protection is actually removed. |
update |
214 |
|
Detects when an IAM group is deleted using the DeleteGroup API call. Deletion of an IAM group may represent a malicious attempt to remove audit trails, disrupt operations, or hide adversary activity (for example after using the group briefly for privileged access). This can be an indicator of impact or cleanup in an attack lifecycle. |
update |
211 |
|
AWS KMS Customer Managed Key Disabled or Scheduled for Deletion |
Identifies attempts to disable or schedule the deletion of an AWS customer managed KMS Key. Disabling or scheduling a KMS key for deletion removes the ability to decrypt data encrypted under that key and can permanently destroy access to critical resources. Adversaries may use these operations to cause irreversible data loss, disrupt business operations, impede incident response, or hide evidence of prior activity. Because KMS keys often protect sensitive or regulated data, any modification to their lifecycle should be considered highly sensitive and investigated promptly. |
update |
111 |
Identifies the deletion of an Amazon RDS DB instance, Aurora cluster, or global database cluster. Deleting these resources permanently destroys stored data and can cause major service disruption. Adversaries with sufficient permissions may delete RDS resources to impede recovery, destroy evidence, or inflict operational impact on the environment. |
update |
211 |
|
Identifies the modification of an AWS RDS DB instance or cluster to disable the deletionProtection feature. Deletion protection prevents accidental or unauthorized deletion of RDS resources. Adversaries with sufficient permissions may disable this protection as a precursor to destructive actions, including the deletion of databases containing sensitive or business-critical data. This rule alerts when deletionProtection is explicitly set to false on an RDS DB instance or cluster. |
update |
7 |
|
Identifies the deletion of an AWS RDS DB snapshot or configuration changes that effectively remove backup coverage for a DB instance. RDS snapshots contain full backups of database instances, and disabling automated backups by setting "backupRetentionPeriod=0" has a similar impact by preventing future restore points. Adversaries with the appropriate permissions may delete snapshots or disable backups to inhibit recovery, destroy forensic evidence, or prepare for follow-on destructive actions such as instance or cluster deletion. |
update |
7 |
|
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 name or 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. |
update |
8 |
|
Identifies a high-volume of AWS S3 objects stored in a bucket using using Server-Side Encryption with Customer-Provided Keys (SSE-C). Adversaries with compromised AWS credentials can encrypt objects in an S3 bucket using their own encryption keys, rendering the objects unreadable or recoverable without the key. This can be used as a form of ransomware to extort the bucket owner for the decryption key. This is a Threshold rule that triggers when this behavior is observed multiple times for a specific bucket in a short time-window. |
update |
5 |
|
Identifies use of the S3 CopyObject API where the destination object is encrypted using an AWS KMS key from an external AWS account. This behavior may indicate ransomware-style impact activity where an adversary with access to a misconfigured S3 bucket encrypts objects using a KMS key they control, preventing the bucket owner from decrypting their own data. This technique is a critical early signal of destructive intent or cross-account misuse. |
update |
11 |
|
Identifies when object versioning is suspended for an Amazon S3 bucket. Object versioning allows for multiple versions of an object to exist in the same bucket. This allows for easy recovery of deleted or overwritten objects. When object versioning is suspended for a bucket, it could indicate an adversary’s attempt to inhibit system recovery following malicious activity. Additionally, when versioning is suspended, buckets can then be deleted. |
update |
7 |
|
Identifies when AWS S3 objects stored in a bucket are encrypted using Server-Side Encryption with Customer-Provided Keys (SSE-C). Adversaries with compromised AWS credentials can encrypt objects in an S3 bucket using their own encryption keys, rendering the objects unreadable or recoverable without the key. This can be used as a form of ransomware to extort the bucket owner for the decryption key. This is a New Terms rule that flags when this behavior is observed for the first time user and target bucket name. |
update |
6 |
|
Identifies a successful login to the AWS Management Console by the Root user. |
update |
213 |
|
Identifies a password recovery request for the AWS account root user. In AWS, the PasswordRecoveryRequested event from signin.amazonaws.com applies to the root user’s “Forgot your password?” flow. Other identity types, like IAM and federated users, do not generate this event. This alert indicates that someone initiated the root password reset workflow for this account. Verify whether this was an expected action and review identity provider notifications/email to confirm legitimacy. |
update |
211 |
|
Identifies when a federated user logs into the AWS Management Console. Federated users are typically given temporary credentials to access AWS services. If a federated user logs into the AWS Management Console without using MFA, it may indicate a security risk, as MFA adds an additional layer of security to the authentication process. However, CloudTrail does not record whether a Federated User utilized MFA as part of authentication — that MFA decision often occurs at a third-party IdP (e.g., Okta, Azure AD, Google). As a result, CloudTrail fields such as MFAUsed / mfaAuthenticated appear as “No/false” for federated console logins even if IdP MFA was required. This alert should be correlated with IdP authentication logs to verify whether MFA was enforced for the session. Increase priority if you find a related "GetSigninToken" event whose source IP / ASN / geo or user-agent differs from the subsequent "ConsoleLogin" (possible token relay/abuse). Same-IP/UA pairs within a short window are more consistent with expected operator behavior and can be triaged with lower severity. |
update |
6 |
|
Identifies when a new SSH public key is uploaded to an AWS EC2 instance using the EC2 Instance Connect service. This action could indicate an adversary attempting to maintain access to the instance. The rule detects the SendSerialConsoleSSHPublicKey or SendSSHPublicKey API actions, which are logged when manually uploading an SSH key to an EC2 instance or serial connection. It is important to know that this API call happens automatically by the EC2 Instance Connect service when a user connects to an EC2 instance using the EC2 Instance Connect service via the CLI or AWS Management Console. |
update |
7 |
|
Detects successful AWS Management Console or federation login activity performed using an EC2 instance’s assumed role credentials. EC2 instances typically use temporary credentials to make API calls, not to authenticate interactively via the console. A successful "ConsoleLogin" or "GetSigninToken" event using a session pattern that includes "i-" (the EC2 instance ID) is highly anomalous and may indicate that an adversary obtained the instance’s temporary credentials from the instance metadata service (IMDS) and used them to access the console. Such activity can enable lateral movement, privilege escalation, or persistence within the AWS account. |
update |
6 |
|
AWS IAM Virtual MFA Device Registration Attempt with Session Token |
Detects attempts to create or enable a Virtual MFA device (CreateVirtualMFADevice, EnableMFADevice) using temporary AWS credentials (access keys beginning with ASIA). Session credentials are short-lived and tied to existing authenticated sessions, so using them to register or enable MFA devices is unusual. Adversaries who compromise temporary credentials may abuse this behavior to establish persistence by attaching new MFA devices to maintain access to high-privilege accounts despite key rotation or password resets. |
update |
4 |
Identifies the creation of an AWS EC2 network access control list (ACL) or an entry in a network ACL with a specified rule number. Adversaries may exploit ACLs to establish persistence or exfiltrate data by creating permissive rules. |
update |
211 |
|
Identifies a change to an AWS Security Group Configuration. A security group is like a virtual firewall, and modifying configurations may allow unauthorized access. Threat actors may abuse this to establish persistence, exfiltrate data, or pivot in an AWS environment. |
update |
212 |
|
Detects sensitive AWS IAM API operations executed using temporary session credentials (access key IDs beginning with "ASIA"). Temporary credentials are commonly issued through sts:GetSessionToken, sts:AssumeRole, or AWS SSO logins and are meant for short-term use. It is unusual for legitimate users or automated processes to perform privileged IAM actions (e.g., creating users, updating policies, or enabling/disabling MFA) with session tokens. This behavior may indicate credential theft, session hijacking, or the abuse of a privileged role’s temporary credentials. |
update |
6 |
|
Identifies creation of a console login profile for the AWS account root user. While CreateLoginProfile normally applies to IAM users, when performed from a temporary root session (e.g., via AssumeRoot) and the userName parameter is omitted, the profile is created for the root principal (self-assigned). Adversaries with temporary root access may add or reset the root login profile to establish persistent console access even if original access keys are rotated or disabled. Correlate with recent AssumeRoot/STS activity and validate intent with the account owner. |
update |
5 |
|
Identifies the creation of a group in AWS Identity and Access Management (IAM). Groups specify permissions for multiple users. Any user in a group automatically has the permissions that are assigned to the group. Adversaries who obtain credentials with IAM write privileges may create a new group as a foothold for persistence: they can later attach admin-level policies to the group and quietly add users or roles to inherit those privileges. |
update |
211 |
|
Detects the creation of a new AWS IAM Roles Anywhere profile. Roles Anywhere allows workloads or external systems to assume IAM roles from outside AWS by authenticating via trusted certificate authorities (trust anchors). Adversaries who have established persistence through a rogue trust anchor may create or modify profiles to link them with highly privileged roles, enabling long-term external access to the AWS environment. This rule identifies successful "CreateProfile" API calls and helps detect potentially unauthorized or risky external access configurations. |
update |
7 |
|
AWS IAM Roles Anywhere Trust Anchor Created with External CA |
Detects the creation of an AWS IAM Roles Anywhere Trust Anchor that uses an external certificate authority (CA) rather than an AWS-managed Certificate Manager Private CA (ACM PCA). While Roles Anywhere enables secure, short-term credential issuance for workloads outside AWS, adversaries can exploit this feature by registering their own external CA as a trusted root. This allows them to generate valid client certificates that persistently authenticate to AWS roles from any location, even after key rotation or credential revocation events. This rule helps detect persistence or unauthorized federation attempts by flagging trust anchors configured with non-AWS CAs. |
update |
7 |
An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by creating a new set of credentials for an existing user. This rule looks for use of the IAM |
update |
12 |
|
AWS Lambda Function Policy Updated to Allow Public Invocation |
Identifies when an AWS Lambda function policy is updated to allow public invocation. This rule detects use of the AddPermission API where the Principal is set to "*", enabling any AWS account to invoke the function. Adversaries may abuse this configuration to establish persistence, create a covert execution path, or operate a function as an unauthenticated backdoor. Public invocation is rarely required outside very specific workloads and should be considered high-risk when performed unexpectedly. |
update |
6 |
Identifies the modification of the master password for an AWS RDS DB instance or cluster. Changing the master password is a legitimate recovery action when access is lost, but adversaries with sufficient permissions may modify it to regain access, establish persistence, bypass existing controls, or escalate privileges within a compromised environment. Because RDS does not expose the password in API responses, this operation can meaningfully alter access pathways to sensitive data stores. |
update |
7 |
|
Identifies the creation or modification of an Amazon RDS DB instance or cluster where the "publiclyAccessible" attribute is set to "true". Publicly accessible RDS instances expose a network endpoint on the public internet, which may allow unauthorized access if combined with overly permissive security groups, weak authentication, or misconfigured IAM policies. Adversaries may enable public access on an existing instance, or create a new publicly accessible instance, to establish persistence, move data outside of controlled network boundaries, or bypass internal access controls. |
update |
7 |
|
Identifies when the transfer lock on an AWS Route 53 domain is disabled. The transfer lock protects domains from being moved to another registrar or AWS account without authorization. Disabling this lock removes an important safeguard against domain hijacking. Adversaries who gain access to domain-management permissions may disable the lock as a precursor to unauthorized domain transfer, takeover, or service disruption. |
update |
211 |
|
Identifies when an AWS Route 53 domain is transferred to another AWS account. Transferring a domain changes administrative control of the DNS namespace, enabling the receiving account to modify DNS records, route traffic, request certificates, and potentially hijack operational workloads. Adversaries who gain access to privileged IAM users or long-lived credentials may leverage domain transfers to establish persistence, redirect traffic, conduct phishing, or stage infrastructure for broader attacks. This rule detects successful domain transfer requests. |
update |
211 |
|
Identifies when an AWS Route 53 private hosted zone is associated with a new Virtual Private Cloud (VPC). Private hosted zones restrict DNS resolution to specific VPCs, and associating additional VPCs expands the scope of what networks can resolve internal DNS records. Adversaries with sufficient permissions may associate unauthorized VPCs to intercept, observe, or reroute internal traffic, establish persistence, or expand their visibility within an AWS environment. |
update |
211 |
|
Identifies when an EC2 Route Table has been created. Route tables can be used by attackers to disrupt network traffic, reroute communications, or maintain persistence in a compromised environment. This is a New Terms rule that detects the first instance of this behavior by a user or role. |
update |
212 |
|
Identifies when a user has assumed a role using a new MFA device. Users can assume a role to obtain temporary credentials and access AWS resources using the AssumeRole API of AWS Security Token Service (STS). While a new MFA device is not always indicative of malicious behavior it should be verified as adversaries can use this technique for persistence and privilege escalation. |
update |
6 |
|
An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by attaching additional permissions to user groups the compromised user account belongs to. This rule looks for use of the IAM AttachGroupPolicy API operation to attach the highly permissive AdministratorAccess AWS managed policy to an existing IAM user group. |
update |
8 |
|
An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by attaching additional permissions to compromised IAM roles. This rule looks for use of the IAM AttachRolePolicy API operation to attach the highly permissive AdministratorAccess AWS managed policy to an existing IAM role. |
update |
8 |
|
An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by attaching additional permissions to compromised user accounts. This rule looks for use of the IAM AttachUserPolicy API operation to attach the highly permissive AdministratorAccess AWS managed policy to an existing IAM user. |
update |
9 |
|
Detects when an AWS IAM SAML provider is updated, which manages federated authentication between AWS and external identity providers (IdPs). Adversaries with administrative access may modify a SAML provider’s metadata or certificate to redirect authentication flows, enable unauthorized federation, or escalate privileges through identity trust manipulation. Because SAML providers underpin single sign-on (SSO) access for users and applications, unauthorized modifications may allow persistent or covert access even after credentials are revoked. Monitoring "UpdateSAMLProvider" API activity is critical to detect potential compromise of federated trust relationships. |
update |
212 |
|
Identifies when the STS AssumeRoot action is performed by a rare user in AWS. The AssumeRoot action allows users to assume the root member account role, granting elevated but specific permissions based on the task policy specified. Adversaries who have compromised user credentials can use this technique to escalate privileges and gain unauthorized access to AWS resources. This is a New Terms rule that identifies when the STS AssumeRoot action is performed by a user that rarely assumes this role against a specific member account. |
update |
6 |
|
Identifies role chaining activity. Role chaining is when you use one assumed role to assume a second role through the AWS CLI or API. While this a recognized functionality in AWS, role chaining can be abused for privilege escalation if the subsequent assumed role provides additional privileges. Role chaining can also be used as a persistence mechanism as each AssumeRole action results in a refreshed session token with a 1 hour maximum duration. This is a new terms rule that looks for the first occurance of one role (aws.cloudtrail.user_identity.session_context.session_issuer.arn) assuming another (aws.cloudtrail.resources.arn). |
update |
4 |
|
Identifies when an SNS topic is created by a user who does not typically perform this action. Adversaries may create SNS topics to stage capabilities for data exfiltration or other malicious activities. This is a New Terms rule that only flags when this behavior is observed for the first time by a user or role. |
update |
5 |
|
Identifies Entra ID device code authentication flows where multiple user agents are observed within the same session. This pattern is indicative of device code phishing, where an attacker’s polling client (e.g., Python script) and the victim’s browser both appear in the same authentication session. In legitimate device code flows, the user authenticates via browser while the requesting application polls for tokens - when these have distinctly different user agents (e.g., Python Requests vs Chrome), it may indicate the code was phished and redeemed by an attacker. |
update |
4 |
|
Entra ID OAuth Authorization Code Grant for Unusual User, App, and Resource |
Identifies the first occurrence of an OAuth 2.0 authorization code grant flow for a specific combination of client application, target resource, and user principal in Microsoft Entra ID. Developer tools like Azure CLI, Visual Studio Code, and Azure PowerShell accessing Microsoft Graph or legacy Azure AD are flagged for infrequent or first time usage by a user. Additionally, any FOCI (Family of Client IDs) application accessing the deprecated Windows Azure Active Directory for the first time is flagged since this resource is rarely accessed legitimately. This pattern is indicative of OAuth phishing attacks like ConsentFix, where attackers steal authorization codes and exchange them for tokens from attacker controlled infrastructure. |
update |
2 |
Entra ID OAuth Phishing via First-Party Microsoft Application |
Detects potentially suspicious OAuth authorization activity in Microsoft Entra ID where first-party Microsoft applications from the FOCI (Family of Client IDs) group request access to Microsoft Graph or legacy Azure AD resources. Developer tools like Azure CLI, Visual Studio Code, and Azure PowerShell accessing these resources are flagged, as they are commonly abused in phishing campaigns like ConsentFix. Additionally, any FOCI family application accessing the deprecated Windows Azure Active Directory resource is flagged since this API is rarely used legitimately and attackers target it for stealth. First-party apps are trusted by default in all tenants and cannot be blocked, making them ideal for OAuth phishing attacks. |
update |
6 |
This rule detects the deletion of Kubernetes events, which can indicate an attempt to cover up malicious activity or misconfigurations. Adversaries may delete events to remove traces of their actions, making it harder for defenders to investigate and respond to incidents. |
update |
2 |
|
This rule detects attempts to create resources in Kubernetes clusters that are forbidden by the authorization policy. It specifically looks for creation requests that are denied with a "forbid" decision, indicating that the user or service account does not have the necessary permissions to perform the action. This activity is commonly associated with adversaries attempting to create resources in a Kubernetes environment without proper authorization, which can lead to unauthorized access, manipulation of cluster resources, lateral movement and/or privilege escalation. |
update |
2 |
|
This rule detects when a forbidden request is made from an unusual user agent in a Kubernetes environment. Adversary tooling may use non-standard or unexpected user agents to interact with the Kubernetes API, which can indicate an attempt to evade detection or blend in with legitimate traffic. In combination with a forbidden request, this behavior can suggest an adversary is attempting to exploit vulnerabilities or misconfigurations in the Kubernetes cluster. |
update |
2 |
|
This rule detects unusual request responses in Kubernetes audit logs through the use of the "new_terms" rule type. In production environments, default API requests are typically made by system components or trusted users, who are expected to have a consistent user agent and allowed response annotations. By monitoring for anomalies in the username and response annotations, this rule helps identify potential unauthorized access or misconfigurations in the Kubernetes environment. |
update |
2 |
|
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. |
update |
209 |
|
High Number of Egress Network Connections from Unusual Executable |
This rule detects a high number of egress network connections from an unusual executable on a Linux system. This could indicate a command and control (C2) communication attempt, a brute force attack via a malware infection, or other malicious activity. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert. |
update |
10 |
This rule leverages ESQL to detect unusual base64 encoding/decoding activity on Linux systems. Attackers may use base64 encoding/decoding to obfuscate data, such as command and control traffic or payloads, to evade detection by host- or network-based security controls. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert. |
update |
9 |
|
This rule monitors for potential attempts to disable AppArmor. AppArmor is a Linux security module that enforces fine-grained access control policies to restrict the actions and resources that specific applications and processes can access. Adversaries may disable security tools to avoid possible detection of their tools and activities. |
update |
113 |
|
This rule detects potential port scanning activity from a compromised host. Port scanning is a common reconnaissance technique used by attackers to identify open ports and services on a target system. A compromised host may exhibit port scanning behavior when an attacker is attempting to map out the network topology, identify vulnerable services, or prepare for further exploitation. This rule identifies potential port scanning activity by monitoring network connection attempts from a single host to a large number of ports within a short time frame. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert. |
update |
11 |
|
This rule detects potential subnet scanning activity from a compromised host. Subnet scanning is a common reconnaissance technique used by attackers to identify live hosts within a network range. A compromised host may exhibit subnet scanning behavior when an attacker is attempting to map out the network topology, identify vulnerable hosts, or prepare for further exploitation. This rule identifies potential subnet scanning activity by monitoring network connection attempts from a single host to a large number of hosts within a short time frame. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert. |
update |
10 |
|
This rule leverages ESQL to detect the execution of unusual file transfer utilities on Linux systems. Attackers may use these utilities to exfiltrate data from a compromised system. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert. |
update |
10 |
|
This detection identifies a Linux host that has potentially been infected with malware and is being used to conduct brute-force attacks against external systems over SSH (port 22 and common alternative SSH ports). The detection looks for a high volume of outbound connection attempts to non-private IP addresses from a single process. A compromised host may be part of a botnet or controlled by an attacker, attempting to gain unauthorized access to remote systems. This behavior is commonly observed in SSH brute-force campaigns where malware hijacks vulnerable machines to expand its attack surface. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert. |
update |
10 |
|
This rule detects the creation of a NetworkManager dispatcher script on a Linux system. NetworkManager dispatcher scripts are shell scripts that NetworkManager executes when network interfaces change state. Attackers can abuse NetworkManager dispatcher scripts to maintain persistence on a system by executing malicious code whenever a network event occurs. |
update |
6 |
|
Detects suspicious network events executed by systemd, potentially indicating persistence through a systemd backdoor. Systemd is a system and service manager for Linux operating systems, used to initialize and manage system processes. Attackers can backdoor systemd for persistence by creating or modifying systemd unit files to execute malicious scripts or commands, or by replacing legitimate systemd binaries with compromised ones, ensuring that their malicious code is automatically executed at system startup or during certain system events. |
update |
9 |
|
Monitors for the creation of rule files that are used by systemd-udevd to manage device nodes and handle kernel device events in the Linux operating system. Systemd-udevd can be exploited for persistence by adversaries by creating malicious udev rules that trigger on specific events, executing arbitrary commands or payloads whenever a certain device is plugged in or recognized by the system. |
update |
12 |
|
This rule detects unusual processes spawned from a web server parent process by identifying low frequency counts of process spawning activity. Unusual process spawning activity may indicate an attacker attempting to establish persistence, execute malicious commands, or establish command and control channels on the host system. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert. |
update |
10 |
|
This rule detects potential command execution from a web server parent process on a Linux host. Adversaries may attempt to execute commands from a web server parent process to blend in with normal web server activity and evade detection. This behavior is commonly observed in web shell attacks where adversaries exploit web server vulnerabilities to execute arbitrary commands on the host. The detection rule identifies unusual command execution from web server parent processes, which may indicate a compromised host or an ongoing attack. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert. |
update |
10 |
|
Detects file creation events in the plugin directories for the Yum package manager. In Linux, Yum (Yellowdog Updater, Modified) is a command-line utility used for handling packages on (by default) Fedora-based systems, providing functions for installing, updating, upgrading, and removing software along with managing package repositories. Attackers can backdoor Yum to gain persistence by injecting malicious code into plugins that Yum runs, thereby ensuring continued unauthorized access or control each time Yum is used for package management. |
update |
9 |
|
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. |
update |
110 |
|
This rule identifies a potential port scan from an internal IP address. A port scan is a method utilized by attackers to systematically scan a target system for open ports, allowing them to identify available services and potential vulnerabilities. By mapping out the open ports, attackers can gather critical information to plan and execute targeted attacks, gaining unauthorized access, compromising security, and potentially leading to data breaches, unauthorized control, or further exploitation of the targeted system. This rule defines a threshold-based approach to detect connection attempts from a single internal source to a wide range of destination ports on a single destination. |
update |
15 |
|
Generates a detection alert for each external alert written to the configured indices. Enabling this rule allows you to immediately begin investigating external alerts in the app. |
update |
107 |
|
Detects PowerShell script block content that creates Exchange mailbox export requests via New-MailboxExportRequest, commonly writing PST files. Adversaries can abuse export requests to collect and stage email content for exfiltration. |
update |
214 |
|
PowerShell Suspicious Script with Audio Capture Capabilities |
Detects PowerShell script block content that invokes microphone capture routines or WinMM audio APIs. Adversaries may use audio recording to surveil users or capture sensitive conversations for theft or extortion. |
update |
216 |
PowerShell Suspicious Script with Clipboard Retrieval Capabilities |
Detects PowerShell script block content that retrieves clipboard data using Get-Clipboard or Windows clipboard APIs. Adversaries can collect copied credentials, tokens, or other sensitive data from the clipboard. |
update |
214 |
Detects PowerShell script block content that references Win32 keylogging primitives such as key state polling or low-level input hooks. Adversaries use keylogging to capture credentials and other sensitive user input. |
update |
218 |
|
Detects PowerShell script block content that indicates programmatic mailbox access using Outlook Interop/MAPI or EWS APIs. Adversaries can use mailbox access to collect email content and attachments for exfiltration. |
update |
113 |
|
Detects PowerShell script block content that uses CopyFromScreen with .NET bitmap classes to capture screenshots. Attackers use screen capture to collect on-screen information and credentials. |
update |
213 |
|
Detects PowerShell script block content that references webcam capture APIs or video capture device objects. Attackers use webcam recording to surveil victims or collect sensitive footage for extortion. |
update |
110 |
|
Identifies the use of WinRAR or 7-Zip to create encrypted archives. Adversaries often compress and encrypt data in preparation for exfiltration. |
update |
218 |
|
Identifies access attempts to the LSASS handle, which may indicate an attempt to dump credentials from LSASS memory. |
update |
16 |
|
Mimikatz is a credential dumper capable of obtaining plaintext Windows account logins and passwords, along with many other features that make it useful for testing the security of networks. This rule detects PowerShell script content associated with Invoke-Mimikatz or Mimikatz. |
update |
214 |
|
Detects PowerShell script block content containing Invoke-NinjaCopy or related Stealth* functions used for direct volume file access. Attackers use NinjaCopy to read locked system files such as NTDS.dit or registry hives for credential dumping. |
update |
111 |
|
Detects PowerShell script block content that references LSA Kerberos ticket retrieval APIs and Kerb* message types. Attackers dump Kerberos tickets from memory to reuse credentials and move laterally. |
update |
111 |
|
Detects PowerShell scripts referencing MiniDumpWriteDump or full-memory minidump types, which can capture process memory. Attackers often use this technique to dump credential-bearing processes like LSASS for credential theft. |
update |
213 |
|
Detects PowerShell scripts associated with NTLM relay or pass-the-hash tooling and SMB/NTLM negotiation artifacts. Attackers use relay and PtH techniques to authenticate without passwords and pivot to other systems. |
update |
108 |
|
Detects PowerShell scripts that requests Kerberos service tickets via KerberosRequestorSecurityToken. Attackers request service tickets to perform Kerberoasting against service accounts. |
update |
217 |
|
Identifies PowerShell script block content that queries Veeam credential tables or uses ProtectedStorage to decrypt stored secrets. Attackers abuse Veeam credentials to access backup infrastructure and enable ransomware operations. |
update |
107 |
|
Identifies rare connection attempts to a Web Distributed Authoring and Versioning (WebDAV) resource. Attackers may inject WebDAV paths in files or features opened by a victim user to leak their NTLM credentials via forced authentication. |
update |
6 |
|
Detects unusual access to the web.config file, which contains sensitive credential information such as database connection strings, machineKey validation/decryption keys, and SAML/OAuth token settings. Attackers can use the information extracted to forge malicious __VIEWSTATE requests for persistent RCE on the web server or pivot to the SQL server using exposed connection strings. |
update |
2 |
|
Detects PowerShell scripts that references Antimalware Scan Interface (AMSI) bypass classes, methods, or known bypass strings. Attackers attempt AMSI bypass to disable scanning and run malicious PowerShell content undetected. |
update |
116 |
|
An instance of MSBuild, the Microsoft Build Engine, was started by a script or the Windows command interpreter. This behavior is unusual and is sometimes used by malicious payloads. |
update |
316 |
|
An instance of MSBuild, the Microsoft Build Engine, started a PowerShell script or the Visual C# Command Line Compiler. This technique is sometimes used to deploy a malicious payload using the Build Engine. |
update |
319 |
|
Identifies suspicious creation of Alternate Data Streams on highly targeted files using a script or command interpreter. This is uncommon for legitimate files and sometimes done by adversaries to hide malware. |
update |
321 |
|
Identifies instances of an unusual process enumerating built-in Windows privileged local groups membership like Administrators or Remote Desktop users. |
update |
420 |
|
Unusual Discovery Signal Alert with Unusual Process Command Line |
This rule leverages alert data from various Discovery building block rules to alert on signals with unusual unique host.id, user.id and process.command_line entries. |
update |
3 |
Unusual Discovery Signal Alert with Unusual Process Executable |
This rule leverages Discovery building block rule alert data to alert on signals with unusual unique host.id, user.id and process.executable entries. |
update |
4 |
Identifies a suspicious parent child process relationship with cmd.exe descending from svchost.exe |
update |
424 |
|
Identifies the PowerShell engine being invoked by unexpected processes. Rather than executing PowerShell functionality with powershell.exe, some attackers do this to operate more stealthily. |
update |
216 |
|
This rule identifies the creation of multiple files with same name and over SMB by the same user. This behavior may indicate the successful remote execution of a ransomware dropping file notes to different folders. |
update |
214 |
|
Identifies first-time modifications to scheduled tasks by user accounts, excluding system activity and machine accounts. |
update |
117 |
|
Identifies the creation of ASPX files in specific directories that are commonly targeted by attackers to deploy web shells. |
update |
2 |
|
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. |
update |
319 |