diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-aws-backup-recovery-point-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-aws-backup-recovery-point-deleted.asciidoc new file mode 100644 index 0000000000..81a4965490 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-aws-backup-recovery-point-deleted.asciidoc @@ -0,0 +1,116 @@ +[[prebuilt-rule-8-19-27-aws-backup-recovery-point-deleted]] +=== AWS Backup Recovery Point Deleted + +Identifies deletion of an AWS Backup recovery point via DeleteRecoveryPoint. A recovery point is a stored backup of a protected resource (EBS, RDS, DynamoDB, EFS, S3, and others). Deleting recovery points removes the ability to restore the associated data and is a core anti-recovery technique used in ransomware and data-destruction attacks to ensure victims cannot recover without paying or rebuilding. Routine lifecycle expirations are performed by the AWS Backup service itself; deletion by a non-service principal is rare and should be reviewed. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/aws-backup/latest/devguide/API_DeleteRecoveryPoint.html +* https://docs.aws.amazon.com/aws-backup/latest/devguide/vault-lock.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS Backup +* Use Case: Threat Detection +* Tactic: Impact +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Backup Recovery Point Deleted* + + +AWS Backup recovery points are the restorable copies of protected resources. "DeleteRecoveryPoint" permanently removes a recovery point from its vault, eliminating the ability to restore that backup. Adversaries delete recovery points to inhibit recovery after data destruction or encryption, maximizing the impact of ransomware or sabotage. Because scheduled expirations are carried out by the AWS Backup service itself (excluded by this rule), a deletion by a user or role principal is uncommon and high-signal, especially when several recovery points are removed in a short window. + + +*Possible investigation steps* + + +- Identify the actor in "aws.cloudtrail.user_identity.arn" and "aws.cloudtrail.user_identity.type", and review "source.ip", "source.as.organization.name", and "user_agent.original" for an unexpected origin. +- Identify the affected recovery point and vault from "aws.cloudtrail.request_parameters", and determine which resource and data it protected. +- Determine whether multiple recovery points or vaults were affected in the same window, indicating a broader anti-recovery effort. +- Correlate with adjacent destructive or evasion activity by the same principal, such as DeleteBackupVault, Vault Lock removal, KMS key deletion, or resource deletions. + + +*False positive analysis* + + +- Retention cleanup, migration, or decommissioning may delete recovery points. Confirm the deletion is expected and exclude known administration roles on "aws.cloudtrail.user_identity.arn" after validation. + + +*Response and remediation* + + +- If the deletion is unauthorized, treat it as a potential precursor to or part of a destructive attack: preserve remaining backups, enable Vault Lock where possible, and engage incident response. +- Rotate or restrict credentials for the principal if compromise is suspected, and restrict "backup:DeleteRecoveryPoint" to a small set of trusted administrators via IAM and SCPs. + + +*Additional information* + + +- https://docs.aws.amazon.com/aws-backup/latest/devguide/API_DeleteRecoveryPoint.html[DeleteRecoveryPoint API] +- https://docs.aws.amazon.com/aws-backup/latest/devguide/vault-lock.html[AWS Backup Vault Lock] + + +==== Setup + + +This rule requires AWS CloudTrail management events for AWS Backup and ingestion via the Elastic AWS CloudTrail integration. See https://docs.elastic.co/integrations/aws/cloudtrail. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "backup.amazonaws.com" + and event.action: "DeleteRecoveryPoint" + and event.outcome: "success" + and not aws.cloudtrail.user_identity.type: "AWSService" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Inhibit System Recovery +** ID: T1490 +** Reference URL: https://attack.mitre.org/techniques/T1490/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-aws-backup-vault-deleted-or-vault-lock-removed.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-aws-backup-vault-deleted-or-vault-lock-removed.asciidoc new file mode 100644 index 0000000000..95c90acb07 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-aws-backup-vault-deleted-or-vault-lock-removed.asciidoc @@ -0,0 +1,127 @@ +[[prebuilt-rule-8-19-27-aws-backup-vault-deleted-or-vault-lock-removed]] +=== AWS Backup Vault Deleted or Vault Lock Removed + +Identifies deletion of an AWS Backup vault or removal of its Vault Lock configuration via DeleteBackupVault or DeleteBackupVaultLockConfiguration. A backup vault stores recovery points, and Vault Lock enforces WORM (write-once, read-many) immutability that prevents recovery points from being deleted before their retention expires. Removing the lock defeats the primary control designed to stop ransomware from destroying backups, and deleting the vault removes the backup container entirely. Both actions are strong anti-recovery signals and are rare in normal operations. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/aws-backup/latest/devguide/vault-lock.html +* https://docs.aws.amazon.com/aws-backup/latest/devguide/API_DeleteBackupVault.html +* https://docs.aws.amazon.com/aws-backup/latest/devguide/API_DeleteBackupVaultLockConfiguration.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS Backup +* Use Case: Threat Detection +* Tactic: Impact +* Tactic: Defense Evasion +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Backup Vault Deleted or Vault Lock Removed* + + +A backup vault is the container for AWS Backup recovery points, and Vault Lock applies immutability so recovery points cannot be deleted or shortened before retention expires. "DeleteBackupVaultLockConfiguration" removes that immutability (for governance-mode locks), and "DeleteBackupVault" deletes the vault itself. Adversaries remove the lock to enable subsequent deletion of otherwise-immutable recovery points, or delete the vault to destroy backups outright. These are high-impact, rare operations and should be deliberate and tightly controlled. + + +*Possible investigation steps* + + +- Identify the actor in "aws.cloudtrail.user_identity.arn" and "aws.cloudtrail.user_identity.type", and review "source.ip", "source.as.organization.name", and "user_agent.original" for an unexpected origin. +- Determine the affected vault from "aws.cloudtrail.request_parameters" and whether it held recovery points. +- For lock removal, check whether DeleteRecoveryPoint or DeleteBackupVault followed shortly after, indicating a staged anti-recovery sequence. +- Correlate with other destructive or evasion activity by the same principal (KMS key deletion, resource deletions, logging changes). + + +*False positive analysis* + + +- Decommissioning of empty vaults or planned governance changes may match. Confirm the change is expected and exclude known administration roles on "aws.cloudtrail.user_identity.arn" after validation. + + +*Response and remediation* + + +- If unauthorized, treat as a likely precursor to backup destruction: preserve remaining recovery points, re-apply Vault Lock (in compliance mode where appropriate), and engage incident response. +- Rotate or restrict credentials for the principal if compromise is suspected, and restrict "backup:DeleteBackupVault" and "backup:DeleteBackupVaultLockConfiguration" to break-glass roles via IAM and SCPs. + + +*Additional information* + + +- https://docs.aws.amazon.com/aws-backup/latest/devguide/vault-lock.html[AWS Backup Vault Lock] +- https://docs.aws.amazon.com/aws-backup/latest/devguide/API_DeleteBackupVault.html[DeleteBackupVault API] +- https://docs.aws.amazon.com/aws-backup/latest/devguide/API_DeleteBackupVaultLockConfiguration.html[DeleteBackupVaultLockConfiguration API] + + +==== Setup + + +This rule requires AWS CloudTrail management events for AWS Backup and ingestion via the Elastic AWS CloudTrail integration. See https://docs.elastic.co/integrations/aws/cloudtrail. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "backup.amazonaws.com" + and event.action: ("DeleteBackupVault" or "DeleteBackupVaultLockConfiguration") + and event.outcome: "success" + and not aws.cloudtrail.user_identity.type: "AWSService" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Inhibit System Recovery +** ID: T1490 +** Reference URL: https://attack.mitre.org/techniques/T1490/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-aws-ecr-repository-or-registry-policy-granted-public-access.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-aws-ecr-repository-or-registry-policy-granted-public-access.asciidoc new file mode 100644 index 0000000000..6d446f55a7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-aws-ecr-repository-or-registry-policy-granted-public-access.asciidoc @@ -0,0 +1,111 @@ +[[prebuilt-rule-8-19-27-aws-ecr-repository-or-registry-policy-granted-public-access]] +=== AWS ECR Repository or Registry Policy Granted Public Access + +Detects when an Amazon ECR repository or registry policy is modified to grant public access using a wildcard principal (Principal:"*") statement. This rule analyzes SetRepositoryPolicy and PutRegistryPolicy events whose policy document grants an Allow effect to a wildcard ("*") principal, indicating that pull (and potentially push) permissions were extended to all identities, including unauthenticated users. A public container registry can expose proprietary images and any secrets baked into their layers, and, if push is allowed, enables supply-chain implantation. Public ECR access is sometimes intentional for image distribution, so the granting principal and the permissions should be validated. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 10m + +*Searches indices from*: now-15m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/AmazonECR/latest/APIReference/API_SetRepositoryPolicy.html +* https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-policies.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS ECR +* Use Case: Threat Detection +* Tactic: Exfiltration +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS ECR Repository or Registry Policy Granted Public Access* + + +This rule detects "SetRepositoryPolicy" or "PutRegistryPolicy" calls where the policy document grants an Allow effect to a wildcard ("*") principal, granting access to all identities. A public ECR repository allows anyone to pull its images, exposing proprietary code and any secrets embedded in image layers; if push actions are granted, an adversary can implant a malicious image that downstream ECS, EKS, or Lambda workloads then run. + + +*Possible investigation steps* + + +- Identify the actor in "aws.cloudtrail.user_identity.arn" and "aws.cloudtrail.user_identity.type", and review "source.ip" and "user_agent.original" for an unexpected origin or tool. +- Extract the policy from "aws.cloudtrail.request_parameters" and identify the granted actions; pull actions (BatchGetImage, GetDownloadUrlForLayer) expose images, while push actions (PutImage, UploadLayerPart) enable implantation. +- Confirm whether a Deny statement restricts the same access, in which case the alert may be a false positive. +- Determine which repository is affected and whether it contains sensitive images, and correlate with subsequent pull or push activity from external principals. + + +*False positive analysis* + + +- Public image distribution legitimately uses Principal:"*". Confirm the exposure is intended, the actions are pull-only, and the granting principal is approved. + + +*Response and remediation* + + +- If the exposure is unauthorized, restore a known-good policy or remove the public statement, and review for any external pulls or pushes since the change. +- Rotate or restrict credentials for the principal if compromise is suspected, and restrict "ecr:SetRepositoryPolicy" and "ecr:PutRegistryPolicy" to trusted administrators. + + +==== Setup + + +This rule requires AWS CloudTrail logs ingested via the Elastic AWS integration. See https://docs.elastic.co/integrations/aws/cloudtrail for setup details. + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-aws.cloudtrail-* METADATA _id, _version, _index +| WHERE event.provider == "ecr.amazonaws.com" + AND event.action IN ("SetRepositoryPolicy", "PutRegistryPolicy") + AND event.outcome == "success" + AND (aws.cloudtrail.user_identity.type IS NULL OR aws.cloudtrail.user_identity.type != "AWSService") + AND aws.cloudtrail.request_parameters RLIKE """.*\"Effect\": *\"Allow\".*""" + AND (aws.cloudtrail.request_parameters RLIKE """.*\"Principal\": *\"\*\".*""" + OR aws.cloudtrail.request_parameters RLIKE """.*\"Principal\": *\{ *\"AWS\": *\"\*\".*""") +| KEEP _id, _version, _index, @timestamp, aws.*, cloud.*, event.*, source.*, user.*, user_agent.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Transfer Data to Cloud Account +** ID: T1537 +** Reference URL: https://attack.mitre.org/techniques/T1537/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-aws-iam-account-password-policy-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-aws-iam-account-password-policy-deleted.asciidoc new file mode 100644 index 0000000000..de3dd05f93 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-aws-iam-account-password-policy-deleted.asciidoc @@ -0,0 +1,110 @@ +[[prebuilt-rule-8-19-27-aws-iam-account-password-policy-deleted]] +=== AWS IAM Account Password Policy Deleted + +Identifies deletion of the AWS account password policy via DeleteAccountPasswordPolicy. The account password policy enforces minimum password requirements (length, complexity, rotation, and reuse) for all IAM users in the account. Deleting it removes those requirements account-wide, weakening authentication and easing follow-on credential-based attacks. This is an account-level change that legitimately occurs only during deliberate administration, so its deletion by an unexpected principal warrants review. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html +* https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteAccountPasswordPolicy.html + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS IAM +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM Account Password Policy Deleted* + + +The account password policy is an account-wide control that sets minimum password length, character complexity, maximum age, and reuse-prevention for all IAM users. `DeleteAccountPasswordPolicy` removes it entirely, reverting the account to no enforced password requirements — which weakens authentication and can facilitate credential attacks or mask weak credentials created later. Because this is a single, account-level, high-impact change, it should be deliberate and rare. + + +*Possible investigation steps* + + +- Identify the actor in `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, and `aws.cloudtrail.user_identity.session_context.session_issuer.arn`, and review `source.ip` / `user_agent.original`. +- Determine whether a replacement policy was set shortly after (`UpdateAccountPasswordPolicy`) or whether the account was left with no policy. +- Confirm whether the change aligns with an approved governance change. +- Correlate with recent activity by the same principal, such as creation of IAM users or login profiles, or other defense-evasion actions (CloudTrail/logging changes) that may indicate a broader effort to weaken controls. + + +*False positive analysis* + + +- Approved governance or infrastructure-as-code may delete/replace the policy. Confirm the change is expected and exclude known administration roles or automation on `aws.cloudtrail.user_identity.arn` after validation. +- Note: AWS GuardDuty also surfaces account password policy changes via `Stealth:IAMUser/PasswordPolicyChange`; correlate if GuardDuty is enabled. + + +*Response and remediation* + + +- If the deletion is unauthorized, restore an appropriate account password policy (`UpdateAccountPasswordPolicy`) that meets your organization's standards, and review any IAM users or login profiles created while no policy was enforced. +- Rotate or restrict credentials for the principal if compromise is suspected, and constrain `iam:DeleteAccountPasswordPolicy` and `iam:UpdateAccountPasswordPolicy` to a small set of trusted administrators. + + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "iam.amazonaws.com" + and event.action: "DeleteAccountPasswordPolicy" + and event.outcome: "success" + and not aws.cloudtrail.user_identity.type: "AWSService" + and not user_agent.original: (*terraform* or *pulumi* or *ansible*) + and not aws.cloudtrail.user_identity.arn: (*terraform* or *pulumi* or *ansible*) + and not source.address: ("cloudformation.amazonaws.com" or "servicecatalog.amazonaws.com") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-aws-iam-inline-policy-added-to-a-group.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-aws-iam-inline-policy-added-to-a-group.asciidoc new file mode 100644 index 0000000000..6f336d4d5b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-aws-iam-inline-policy-added-to-a-group.asciidoc @@ -0,0 +1,130 @@ +[[prebuilt-rule-8-19-27-aws-iam-inline-policy-added-to-a-group]] +=== AWS IAM Inline Policy Added to a Group + +Identifies an inline policy added to an IAM group via PutGroupPolicy. An inline policy attached to a group grants its permissions to every current and future member of that group. Adversaries can abuse this to escalate privileges (grant elevated permissions to a group they belong to, or will add themselves to) and to establish persistence through a durable, membership-based grant that is easy to overlook. Group inline policies are uncommon compared to managed-policy attachments, so their creation by an unexpected principal warrants review. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html +* https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutGroupPolicy.html + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS IAM +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM Inline Policy Added to a Group* + + +`PutGroupPolicy` embeds an inline permissions policy directly on an IAM group. Because the policy applies to all members of the group, it is an effective way to broadly grant permissions — and, for an adversary, to escalate privileges or persist while drawing less attention than attaching a well-known managed policy such as `AdministratorAccess`. Group inline policies are relatively rare, which makes their creation a useful signal. + + +*Possible investigation steps* + + +- Identify the actor in `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, and `aws.cloudtrail.user_identity.session_context.session_issuer.arn`, and review `source.ip` / `user_agent.original` to determine how the change was made. +- Inspect `aws.cloudtrail.request_parameters` for the targeted `groupName`, the `policyName`, and the `policyDocument` to assess what permissions were granted (look for broad `Action`/`Resource` of `*`, IAM, or data-access permissions). +- Enumerate the group's current members to understand who immediately gains the new permissions, and whether the actor is or could become a member. +- Confirm whether the change aligns with an approved access request, onboarding, or deployment. +- Correlate with recent activity by the same principal, such as group creation, adding users to the group, or other IAM modifications that may form an escalation chain. + + +*False positive analysis* + + +- Approved access governance and infrastructure-as-code may add group inline policies. Confirm the change is expected and exclude known administration roles or automation on `aws.cloudtrail.user_identity.arn` after validation. + + +*Response and remediation* + + +- If the change is unauthorized, remove the inline policy from the group (`DeleteGroupPolicy`) and review which members used the granted permissions while it was in place. +- Rotate or restrict credentials for the principal if compromise is suspected, and constrain `iam:PutGroupPolicy` to a small set of trusted administrators. + + +*Additional information* + + +- https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html[IAM identity-based policies (inline)] +- https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutGroupPolicy.html[PutGroupPolicy API] + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "iam.amazonaws.com" + and event.action: "PutGroupPolicy" + and event.outcome: "success" + and not aws.cloudtrail.user_identity.type: "AWSService" + and not user_agent.original: (*terraform* or *pulumi* or *ansible*) + and not aws.cloudtrail.user_identity.arn: (*terraform* or *pulumi* or *ansible*) + and not source.as.organization.name: (Amazon* or AMAZON* or Google*) + and not source.address: ("cloudformation.amazonaws.com" or "servicecatalog.amazonaws.com") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-aws-iam-login-profile-created-or-modified-for-an-iam-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-aws-iam-login-profile-created-or-modified-for-an-iam-user.asciidoc new file mode 100644 index 0000000000..04b4524c76 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-aws-iam-login-profile-created-or-modified-for-an-iam-user.asciidoc @@ -0,0 +1,121 @@ +[[prebuilt-rule-8-19-27-aws-iam-login-profile-created-or-modified-for-an-iam-user]] +=== AWS IAM Login Profile Created or Modified for an IAM User + +Identifies creation or modification of a console login profile for an AWS IAM user via CreateLoginProfile or UpdateLoginProfile. A login profile enables password-based console sign-in for an IAM user. Adversaries who obtain programmatic credentials may create a login profile to add persistent interactive console access, or update an existing profile to reset another user's password and take over the account, even after the original access keys are rotated. Because console access for IAM users is increasingly provisioned through federation or IAM Identity Center, direct use of these APIs by an unexpected principal warrants review. This rule targets IAM users (the userName parameter is present); creation of a login profile for the account root user is covered by a separate rule. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateLoginProfile.html +* https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateLoginProfile.html + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS IAM +* Use Case: Identity and Access Audit +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM Login Profile Created or Modified for an IAM User* + + +A login profile enables password-based AWS console access for an IAM user. "CreateLoginProfile" adds a console password to a user that did not have one, and "UpdateLoginProfile" changes the password of an existing profile. An adversary operating with stolen programmatic credentials can use "CreateLoginProfile" to establish persistent interactive access, or "UpdateLoginProfile" to reset a privileged user's password and hijack the account, retaining access even if the compromised access keys are later disabled. + +Because IAM-user console access is commonly provisioned through federation or IAM Identity Center rather than these APIs directly, unexpected use is a meaningful signal. Note that a user changing their own password uses ChangePassword, not UpdateLoginProfile, so UpdateLoginProfile typically reflects an administrative (or adversarial) reset of another user. + + +*Possible investigation steps* + + +- Identify the actor in "aws.cloudtrail.user_identity.arn", "aws.cloudtrail.user_identity.type", and "aws.cloudtrail.user_identity.session_context.session_issuer.arn", and review "source.ip", "source.as.organization.name", and "user_agent.original" to determine whether the action came from an expected network path or automation platform. +- Identify the target user in "aws.cloudtrail.request_parameters" and determine whether that user normally has console access and how privileged it is. +- Check "aws.cloudtrail.request_parameters" for "passwordResetRequired"; a value of false (or omitted) may indicate the actor set a password they intend to reuse. +- Correlate with surrounding activity by the same principal, such as CreateAccessKey, AttachUserPolicy, PutUserPolicy, virtual MFA registration, or a subsequent ConsoleLogin for the target user, which may indicate persistence or account takeover. + + +*False positive analysis* + + +- Onboarding, password resets, and break-glass procedures legitimately use these APIs. Confirm the change is expected and exclude known administration roles or provisioning automation on "aws.cloudtrail.user_identity.arn" after validation. + + +*Response and remediation* + + +- If the change is unauthorized, delete the login profile or reset the affected user's password, and revoke active console sessions for that user. +- Rotate or restrict credentials for the acting principal if compromise is suspected, and review any IAM permission changes or access keys created by the same session. +- Restrict "iam:CreateLoginProfile" and "iam:UpdateLoginProfile" to a small set of trusted administrators, and prefer federation or IAM Identity Center for console access. + + +==== Setup + + +This rule requires AWS CloudTrail logs ingested via the Elastic AWS integration. See https://docs.elastic.co/integrations/aws/cloudtrail for setup details. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "iam.amazonaws.com" + and event.action: ("CreateLoginProfile" or "UpdateLoginProfile") + and event.outcome: "success" + and not aws.cloudtrail.user_identity.type: "AWSService" + and not user_agent.original: (*terraform* or *pulumi* or *ansible*) + and not aws.cloudtrail.user_identity.arn: (*terraform* or *pulumi* or *ansible*) + and not source.as.organization.name: (Amazon* or AMAZON* or Google*) + and not source.address: ("cloudformation.amazonaws.com" or "servicecatalog.amazonaws.com") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Credentials +** ID: T1098.001 +** Reference URL: https://attack.mitre.org/techniques/T1098/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-aws-iam-permissions-boundary-modified-or-removed.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-aws-iam-permissions-boundary-modified-or-removed.asciidoc new file mode 100644 index 0000000000..f7275634b0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-aws-iam-permissions-boundary-modified-or-removed.asciidoc @@ -0,0 +1,116 @@ +[[prebuilt-rule-8-19-27-aws-iam-permissions-boundary-modified-or-removed]] +=== AWS IAM Permissions Boundary Modified or Removed + +Identifies the modification or removal of an IAM permissions boundary on an IAM user or role. A permissions boundary caps the maximum permissions an identity can have, regardless of its attached identity policies. An adversary who can delete a boundary ("DeleteUserPermissionsBoundary", "DeleteRolePermissionsBoundary") or replace it with a more permissive one ("PutUserPermissionsBoundary", "PutRolePermissionsBoundary") can lift that cap and unlock permissions the identity's policies already grant, enabling privilege escalation. Boundary changes are infrequent and usually performed by a small set of administrators or infrastructure-as-code pipelines, so changes by unexpected principals warrant review. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html +* https://hackingthe.cloud/aws/exploitation/iam_privilege_escalation/ + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS IAM +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM Permissions Boundary Modified or Removed* + + +An IAM permissions boundary is the maximum set of permissions an identity can ever have — even if its identity policies grant more, the effective permissions are the intersection of the two. Removing a boundary (`DeleteUserPermissionsBoundary` / `DeleteRolePermissionsBoundary`) or replacing it with a broader one (`PutUserPermissionsBoundary` / `PutRolePermissionsBoundary`) lifts that cap, so any permissions already present in the identity's attached policies immediately take effect. This is a recognized privilege-escalation path: an adversary who can edit a boundary can unlock latent permissions without attaching any new policy. + + +*Possible investigation steps* + + +- Identify the actor in `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, and `aws.cloudtrail.user_identity.session_context.session_issuer.arn`, and review `source.ip` / `user_agent.original` to determine how the change was made (console, CLI, SDK, automation). +- Inspect `aws.cloudtrail.request_parameters` for the targeted `userName`/`roleName` and, for `Put*` operations, the `permissionsBoundary` policy ARN that was applied. +- Determine the identity's attached identity policies to assess what permissions are now unlocked by the boundary change (the effective blast radius). +- Confirm whether the change aligns with an approved governance change, onboarding, or deployment. +- Correlate with recent activity by the same principal, such as policy attachment, access key creation, or role assumption that may indicate an escalation chain. + + +*False positive analysis* + + +- Identity/platform teams and infrastructure-as-code routinely set and update boundaries. Confirm the change is approved and exclude known administration roles or automation on `aws.cloudtrail.user_identity.arn` after validation. + + +*Response and remediation* + + +- If the change is unauthorized, restore the intended permissions boundary on the affected identity and review what the identity could access while the boundary was relaxed or absent. +- Rotate or restrict credentials for the principal that made the change if compromise is suspected, and constrain `iam:PutUserPermissionsBoundary`, `iam:PutRolePermissionsBoundary`, `iam:DeleteUserPermissionsBoundary`, and `iam:DeleteRolePermissionsBoundary` to a small set of trusted administrators. + + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "iam.amazonaws.com" + and event.action: ( + "PutUserPermissionsBoundary" or + "PutRolePermissionsBoundary" or + "DeleteUserPermissionsBoundary" or + "DeleteRolePermissionsBoundary" + ) + and event.outcome: "success" + and not aws.cloudtrail.user_identity.type: "AWSService" + and not user_agent.original: (*terraform* or *pulumi* or *ansible*) + and not aws.cloudtrail.user_identity.arn: (*terraform* or *pulumi* or *ansible*) + and not source.as.organization.name: (Amazon* or AMAZON* or Google*) + and not source.address: ("cloudformation.amazonaws.com" or "servicecatalog.amazonaws.com") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-aws-iam-user-console-login-from-multiple-geolocations.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-aws-iam-user-console-login-from-multiple-geolocations.asciidoc new file mode 100644 index 0000000000..a75ae3df7c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-aws-iam-user-console-login-from-multiple-geolocations.asciidoc @@ -0,0 +1,132 @@ +[[prebuilt-rule-8-19-27-aws-iam-user-console-login-from-multiple-geolocations]] +=== AWS IAM User Console Login from Multiple Geolocations + +Identifies an IAM user that successfully signs in to the AWS Management Console from two or more distinct countries within a short window. A single user authenticating from multiple geographic locations in a brief period is physically implausible and indicates that the account's credentials or console session are being used from more than one place at once. This is a hallmark of adversary-in-the-middle (AiTM) phishing and session theft, where the legitimate user signs in from their location while the attacker replays the captured session or credentials from their own infrastructure. Because the attacker logs in from a different network, the divergent sign-in geolocations are the detectable signal even when MFA appears satisfied (AiTM relays the live MFA challenge). This is the CloudTrail-native analog of identity-provider impossible-travel sign-in detections. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 10m + +*Searches indices from*: now-65m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://securitylabs.datadoghq.com/articles/behind-the-console-aws-aitm-phishing-kit-and-beyond/ + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS Sign-In +* Use Case: Identity and Access Audit +* Tactic: Initial Access +* Tactic: Credential Access +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM User Console Login from Multiple Geolocations* + + +This rule aggregates successful "ConsoleLogin" events for each IAM user over the lookback window and alerts when the logins originate from two or more distinct countries. Concurrent sign-ins from different geographies indicate the credentials or console session are in use from more than one location, a strong signal of adversary-in-the-middle (AiTM) phishing or session theft. AiTM relays the victim's live MFA, so the console login records MFA as used; the divergent geolocations, not the MFA field, are the indicator. + + +*Possible investigation steps* + + +- Review "Esql.source_geo_country_iso_code_values" and "Esql.source_ip_values" to identify the locations and networks, and determine which (if any) is the user's expected origin. +- Compare "Esql.timestamp_min" and "Esql.timestamp_max" to assess how implausible the travel is. +- Identify the user in "aws.cloudtrail.user_identity.arn" and check for hands-on-keyboard activity immediately after the logins (CreateAccessKey, login profile or MFA changes, IAM policy changes, data access). +- Determine whether any of the source networks are VPNs, proxies, or hosting providers inconsistent with the user. + + +*False positive analysis* + + +- VPN/proxy exit nodes, border travel, and mobile roaming can place a legitimate user in multiple countries. Confirm the activity is expected and exclude known networks after validation. Shared IAM users will also trigger this and should be remediated. + + +*Response and remediation* + + +- If unauthorized, revoke the user's console sessions, reset the password and MFA, and rotate access keys. +- Review and revert changes made during the sessions, and migrate console access to IAM Identity Center with phishing-resistant MFA (FIDO2/passkeys), which defeats AiTM relay. + + +*Additional information* + + +- https://docs.aws.amazon.com/IAM/latest/UserGuide/cloudtrail-integration.html[AWS sign-in CloudTrail events] + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-aws.cloudtrail-* +| WHERE event.provider == "signin.amazonaws.com" + AND event.action == "ConsoleLogin" + AND event.outcome == "success" + AND aws.cloudtrail.user_identity.type == "IAMUser" + AND source.geo.country_iso_code IS NOT NULL +| STATS + Esql.source_geo_country_iso_code_count_distinct = COUNT_DISTINCT(source.geo.country_iso_code), + Esql.source_as_organization_name_count_distinct = COUNT_DISTINCT(source.as.organization.name), + Esql.source_ip_values = VALUES(source.ip), + Esql.source_geo_country_iso_code_values = VALUES(source.geo.country_iso_code), + Esql.timestamp_min = MIN(@timestamp), + Esql.timestamp_max = MAX(@timestamp) + BY aws.cloudtrail.user_identity.arn, cloud.account.id +| WHERE Esql.source_geo_country_iso_code_count_distinct >= 2 +| KEEP aws.cloudtrail.user_identity.arn, cloud.account.id, Esql.source_geo_country_iso_code_count_distinct, Esql.source_as_organization_name_count_distinct, Esql.source_ip_values, Esql.source_geo_country_iso_code_values, Esql.timestamp_min, Esql.timestamp_max + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Web Session Cookie +** ID: T1539 +** Reference URL: https://attack.mitre.org/techniques/T1539/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-aws-kms-imported-key-material-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-aws-kms-imported-key-material-deleted.asciidoc new file mode 100644 index 0000000000..303ecc7667 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-aws-kms-imported-key-material-deleted.asciidoc @@ -0,0 +1,124 @@ +[[prebuilt-rule-8-19-27-aws-kms-imported-key-material-deleted]] +=== AWS KMS Imported Key Material Deleted + +Identifies deletion of imported key material from an AWS KMS customer managed key via DeleteImportedKeyMaterial. Keys created with an external key material origin (BYOK) rely on key material that the customer imports. Deleting that material immediately makes the key unusable and renders all data encrypted under it inaccessible, with no recovery window. Unlike ScheduleKeyDeletion, which enforces a pending deletion period of 7 to 30 days, this action takes effect instantly, making it an attractive primitive for cloud ransomware and data-destruction attacks. Because this operation only applies to external-origin keys and is rare in normal operations, its use by an unexpected principal warrants prompt review. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/kms/latest/APIReference/API_DeleteImportedKeyMaterial.html +* https://docs.aws.amazon.com/kms/latest/developerguide/importing-keys.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS KMS +* Use Case: Threat Detection +* Tactic: Impact +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS KMS Imported Key Material Deleted* + + +AWS KMS keys can be created with an external key material origin (BYOK), where the customer imports the cryptographic material rather than having KMS generate it. "DeleteImportedKeyMaterial" removes that material, immediately transitioning the key to a "PendingImport" state where it can no longer encrypt or decrypt. All data protected by the key becomes inaccessible until the exact same material is re-imported. Unlike "ScheduleKeyDeletion", there is no pending window, so the impact is instant and, for an adversary who controls and withholds the original material, effectively irreversible. + +Because this action only applies to external-origin keys and is uncommon in normal operations, it should be treated as a high-risk, destructive action when performed unexpectedly. Adversaries may delete imported key material to sabotage recovery, destroy data, or hold encrypted resources for ransom. + + +*Possible investigation steps* + + +- Identify the actor and authentication context in "aws.cloudtrail.user_identity.arn", "aws.cloudtrail.user_identity.access_key_id", and "aws.cloudtrail.user_identity.type", and review "source.ip" and "user_agent.original" to determine whether the action came from an expected network path or automation platform. +- Identify the affected key from "aws.cloudtrail.resources.arn" or the "keyId" in "aws.cloudtrail.request_parameters", and determine which services and data depend on it (S3, EBS, RDS, Secrets Manager, etc.). +- Determine whether the same material was re-imported shortly after ("ImportKeyMaterial") or whether the key was left unusable. +- Correlate with surrounding activity by the same principal, such as KMS key policy changes, scheduled key deletions, S3 or EBS destructive actions, or credential changes that may indicate a broader sabotage or ransom attempt. + + +*False positive analysis* + + +- Organizations with BYOK/HYOK requirements may delete and re-import key material during planned rotation, migration, or decommissioning. Confirm the change is expected and exclude known administration roles or automation on "aws.cloudtrail.user_identity.arn" after validation. + + +*Response and remediation* + + +- If the deletion is unauthorized, re-import the original key material if it is securely retained, and restore access to affected services. +- Treat any encrypted data whose key material cannot be re-imported as potentially unrecoverable, and engage incident response and data owners to assess impact. +- Rotate or restrict credentials for the principal if compromise is suspected, and constrain "kms:DeleteImportedKeyMaterial" and "kms:ImportKeyMaterial" to a small set of trusted administrators. +- Use AWS Organizations SCPs to limit who can manage imported key material in production accounts. + + +*Additional information* + + +- https://docs.aws.amazon.com/kms/latest/APIReference/API_DeleteImportedKeyMaterial.html[DeleteImportedKeyMaterial API] +- https://docs.aws.amazon.com/kms/latest/developerguide/importing-keys.html[Importing key material into AWS KMS keys] + + +==== Setup + + +This rule requires AWS CloudTrail management events for AWS Backup and ingestion via the Elastic AWS CloudTrail integration. See https://docs.elastic.co/integrations/aws/cloudtrail. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "kms.amazonaws.com" + and event.action: "DeleteImportedKeyMaterial" + and event.outcome: "success" + and not aws.cloudtrail.user_identity.type: "AWSService" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ +* Sub-technique: +** Name: Lifecycle-Triggered Deletion +** ID: T1485.001 +** Reference URL: https://attack.mitre.org/techniques/T1485/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-aws-lambda-function-high-frequency-invocation-by-a-single-principal.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-aws-lambda-function-high-frequency-invocation-by-a-single-principal.asciidoc new file mode 100644 index 0000000000..9d9ee18932 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-aws-lambda-function-high-frequency-invocation-by-a-single-principal.asciidoc @@ -0,0 +1,142 @@ +[[prebuilt-rule-8-19-27-aws-lambda-function-high-frequency-invocation-by-a-single-principal]] +=== AWS Lambda Function High-Frequency Invocation by a Single Principal + +Identifies a single principal directly invoking AWS Lambda functions at a high volume within a one-hour window. Adversaries may drive excessive invocations to abuse functions for resource hijacking or cryptomining, to inflate costs in a denial-of-wallet attack, or to enumerate function behavior. This is a volumetric heuristic: the threshold is environment-dependent and high-throughput applications can exceed it, so tune it to the deployment. This rule relies on AWS Lambda data event logging, which is not enabled by default. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 60m + +*Searches indices from*: now-61m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/lambda/latest/dg/logging-using-cloudtrail.html +* https://docs.aws.amazon.com/lambda/latest/dg/lambda-concurrency.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS CloudTrail +* Data Source: AWS Lambda +* Use Case: Threat Detection +* Tactic: Impact +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Lambda Function High-Frequency Invocation by a Single Principal* + + +A principal issuing a high volume of direct Lambda invocations in a short window can indicate function abuse for resource hijacking or cryptomining, a denial-of-wallet cost attack, or behavioral enumeration. Because Lambda data events record only the invocation metadata (caller, function, source) and not the function's internal behavior, this rule is purely volumetric and should be treated as corroborating signal. + + +*Possible investigation steps* + + +- Identify the principal in `aws.cloudtrail.user_identity.arn` and determine whether the volume exceeds its historical baseline. +- Determine whether the principal is a known high-throughput application or automation identity, or an unexpected user. +- Review `source.ip` / `user_agent.original` and recent credential activity for signs of compromise. +- Correlate with billing/concurrency metrics and with other Lambda or IAM activity by the same principal. + + +*False positive analysis* + + +- High-throughput apps, batch processing, and load tests routinely exceed fixed thresholds. Tune the threshold and exclude known high-volume identities after validation. + + +*Response and remediation* + + +- If abuse is confirmed, throttle or disable the affected functions (reserved concurrency), rotate or restrict the principal's credentials, and review function code and execution-role permissions. +- Apply per-function reserved concurrency and account-level guardrails to bound cost and blast radius. + + +*Additional information* + + +- https://docs.aws.amazon.com/lambda/latest/dg/logging-using-cloudtrail.html[Logging Lambda data events with CloudTrail] +- https://docs.aws.amazon.com/lambda/latest/dg/lambda-concurrency.html[Lambda function scaling and concurrency] + + +==== Setup + + + +*Setup* + + +This rule requires AWS Lambda data events to be logged in CloudTrail and ingested via the AWS integration. Lambda +invocation (`Invoke`) is a data-plane event and is NOT logged by default; enable data event logging for Lambda functions +in the trail (optionally scoped to sensitive functions to manage volume). Tune the invocation-count threshold in the +query to the environment before enabling. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-aws.cloudtrail-* + +// Lambda invocation data events (data-plane; requires data event logging enabled) +| where + event.provider == "lambda.amazonaws.com" + and event.action like "Invoke*" + and event.outcome == "success" + and aws.cloudtrail.user_identity.arn IS NOT NULL + +| stats + Esql.invocation_count = count(*), + Esql.source_ips = values(source.ip) + by + aws.cloudtrail.user_identity.arn + +// Threshold is environment-dependent — tune to the deployment +| where Esql.invocation_count >= 1000 + +| keep + aws.cloudtrail.user_identity.arn, + Esql.invocation_count, + Esql.source_ips + +| sort Esql.invocation_count desc + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Resource Hijacking +** ID: T1496 +** Reference URL: https://attack.mitre.org/techniques/T1496/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-aws-lambda-function-invoked-by-an-unusual-principal.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-aws-lambda-function-invoked-by-an-unusual-principal.asciidoc new file mode 100644 index 0000000000..1d6703a6c9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-aws-lambda-function-invoked-by-an-unusual-principal.asciidoc @@ -0,0 +1,124 @@ +[[prebuilt-rule-8-19-27-aws-lambda-function-invoked-by-an-unusual-principal]] +=== AWS Lambda Function Invoked by an Unusual Principal + +Identifies the first time within the prior 14 days that a principal directly invokes an AWS Lambda function in an account, excluding invocations made on behalf of AWS services (normal event-source triggers). Adversaries who compromise credentials or move laterally may directly invoke functions to execute code, retrieve data returned by a function, or abuse an over-permissioned execution role. Direct, ad hoc invocation by a principal that does not normally call Lambda deviates from the usual event-driven invocation pattern and is worth reviewing. This rule relies on AWS Lambda data event logging, which is not enabled by default. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html +* https://docs.aws.amazon.com/lambda/latest/dg/logging-using-cloudtrail.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS Lambda +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Lambda Function Invoked by an Unusual Principal* + + +Most Lambda invocations are driven by event sources (S3, EventBridge, SQS, API Gateway, etc.), which CloudTrail records with `aws.cloudtrail.user_identity.invoked_by` set to the calling service. A principal invoking a function **directly** (via the SDK, CLI, or console) is comparatively rare and, when it comes from an identity that does not normally do so, can indicate lateral movement, credential abuse, or data retrieval from a function. This rule uses a new terms approach to surface the first time a given principal directly invokes a function in an account within the prior 14 days. + + +*Possible investigation steps* + + +- Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, and `aws.cloudtrail.user_identity.access_key_id` to identify the actor, and `source.ip` / `user_agent.original` to determine how the call was made. +- Inspect `aws.cloudtrail.request_parameters` for the `functionName` and map it to its application, owner, and sensitivity. +- Determine whether the principal is expected to invoke functions directly and whether the activity aligns with an approved operation, test, or deployment. +- Correlate with recent activity by the same principal or access key, such as credential issuance, role assumption, or other data-plane access, and check whether the credential was recently seen from an unusual source. + + +*False positive analysis* + + +- Direct invocation is a normal operational and testing activity. Confirm whether the principal is a known operator or automation identity and exclude it on `aws.cloudtrail.user_identity.arn` after validation. + + +*Response and remediation* + + +- If the invocation is unauthorized, review what the function returns and accesses, and assess data exposure. +- Rotate or restrict credentials for the principal if compromise is suspected, and constrain `lambda:InvokeFunction` to the identities and services that require it. + + +*Additional information* + + +- https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html[Invoke API] +- https://docs.aws.amazon.com/lambda/latest/dg/logging-using-cloudtrail.html[Logging Lambda data events with CloudTrail] + + +==== Setup + + + +*Setup* + + +This rule requires AWS Lambda data events to be logged in CloudTrail and ingested via the AWS integration +(`aws.cloudtrail` data stream). Lambda invocation (`Invoke`) is a data-plane event and is NOT logged by default; enable +data event logging for Lambda functions in the trail (optionally scoped to sensitive functions to manage volume). + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "lambda.amazonaws.com" + and event.action: Invoke* + and event.outcome: "success" + and not aws.cloudtrail.user_identity.invoked_by: * + and aws.cloudtrail.user_identity.arn: * + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Serverless Execution +** ID: T1648 +** Reference URL: https://attack.mitre.org/techniques/T1648/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-aws-lambda-function-invoked-cross-account.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-aws-lambda-function-invoked-cross-account.asciidoc new file mode 100644 index 0000000000..79786487e3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-aws-lambda-function-invoked-cross-account.asciidoc @@ -0,0 +1,148 @@ +[[prebuilt-rule-8-19-27-aws-lambda-function-invoked-cross-account]] +=== AWS Lambda Function Invoked Cross-Account + +Identifies an AWS Lambda function invoked by a principal whose AWS account differs from the account that owns the function (a cross-account invocation). The caller's account is parsed from the invoking principal's ARN and compared to the function account. Adversaries who have been granted invoke permission on a function from an external account, or who operate from a separate attacker-controlled account, can use cross-account invocation to execute functions or retrieve the data they return. This is the data-plane counterpart to detecting the cross-account grant itself, and relies on AWS Lambda data event logging, which is not enabled by default. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 60m + +*Searches indices from*: now-61m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/lambda/latest/dg/access-control-resource-based.html +* https://docs.aws.amazon.com/lambda/latest/dg/logging-using-cloudtrail.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS Lambda +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Lambda Function Invoked Cross-Account* + + +A Lambda function invoked by a principal from a different AWS account indicates cross-account invocation - the data-plane realization of a cross-account resource-policy grant. CloudTrail data events record the invoking principal's ARN (which contains the caller's account) and the function's owning account. When these differ, an external account executed the function. This can be a legitimate multi-account integration or an adversary using granted or attacker-controlled cross-account access. + + +*Possible investigation steps* + + +- Review `Esql.caller_account` (the invoking principal's account) versus `Esql.function_account` (the invoked function's owning account) and confirm whether the caller account is a known, trusted account. +- Identify the principal in `aws.cloudtrail.user_identity.arn` and pivot to the raw CloudTrail events (for the same principal/time window) to identify the invoked function(s) in `aws.cloudtrail.request_parameters`. +- Determine whether a corresponding `AddPermission` cross-account grant exists for the function and whether it was expected (correlate with the cross-account resource-policy rule). +- Review `Esql.source_ips` and recent activity from the caller account for other cross-account actions. + + +*False positive analysis* + + +- Cross-account invocation is common in multi-account architectures and partner integrations. Confirm the caller account is approved and exclude known trusted accounts or identities after validation. + + +*Response and remediation* + + +- If the cross-account access is unauthorized, remove the function's cross-account resource-policy statement (`RemovePermission`) and review what the function accessed or returned. +- Constrain `lambda:InvokeFunction` grants to approved accounts and review the function's execution-role permissions. + + +*Additional information* + + +- https://docs.aws.amazon.com/lambda/latest/dg/access-control-resource-based.html[Lambda resource-based policies] +- https://docs.aws.amazon.com/lambda/latest/dg/logging-using-cloudtrail.html[Logging Lambda data events with CloudTrail] + + +==== Setup + + + +*Setup* + + +This rule requires AWS Lambda data events to be logged in CloudTrail and ingested via the AWS integration. Lambda +invocation (`Invoke`) is a data-plane event and is NOT logged by default; enable data event logging for Lambda functions +in the trail (optionally scoped to sensitive functions to manage volume). + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-aws.cloudtrail-* + +| where + event.provider == "lambda.amazonaws.com" + and event.action like "Invoke*" + and event.outcome == "success" + and aws.cloudtrail.user_identity.arn IS NOT NULL + and aws.cloudtrail.user_identity.invoked_by IS NULL + and aws.cloudtrail.request_parameters IS NOT NULL + +| grok aws.cloudtrail.user_identity.arn """:(?[0-9]{12}):""" +| grok aws.cloudtrail.request_parameters """functionName=arn:aws:lambda:[a-z0-9-]*:(?[0-9]{12}):""" + +| where Esql.caller_account IS NOT NULL and Esql.function_account IS NOT NULL and Esql.caller_account != Esql.function_account + +| stats + Esql.invocation_count = count(*), + Esql.source_ips = values(source.ip), + Esql.function_arns = values(aws.cloudtrail.resources.arn) + by + aws.cloudtrail.user_identity.arn, + Esql.caller_account, + Esql.function_account + +| keep + aws.cloudtrail.user_identity.arn, + Esql.caller_account, + Esql.function_account, + Esql.function_arns, + Esql.invocation_count, + Esql.source_ips + + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Serverless Execution +** ID: T1648 +** Reference URL: https://attack.mitre.org/techniques/T1648/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-aws-lambda-function-invoked-from-an-unusual-source-asn.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-aws-lambda-function-invoked-from-an-unusual-source-asn.asciidoc new file mode 100644 index 0000000000..332180b91f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-aws-lambda-function-invoked-from-an-unusual-source-asn.asciidoc @@ -0,0 +1,126 @@ +[[prebuilt-rule-8-19-27-aws-lambda-function-invoked-from-an-unusual-source-asn]] +=== AWS Lambda Function Invoked from an Unusual Source ASN + +Identifies an AWS Lambda function invoked directly by a principal from a source network (ASN) not seen for that principal in the prior 10 days, excluding common cloud provider networks. Direct invocation from an unfamiliar external network can indicate use of stolen execution-role or user credentials from attacker-controlled infrastructure to execute functions or retrieve the data they return. This rule relies on AWS Lambda data event logging, which is not enabled by default. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html +* https://docs.aws.amazon.com/lambda/latest/dg/logging-using-cloudtrail.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS Lambda +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Lambda Function Invoked from an Unusual Source ASN* + + +Lambda execution-role credentials and user credentials are frequently abused after theft (for example via SSRF or RCE against a function, or leaked access keys). When such credentials are replayed from attacker infrastructure, the resulting direct `Invoke` calls originate from a network the legitimate principal has not used. This rule uses a new terms approach over the source ASN organization and the principal, excluding common cloud provider networks, to surface invocation from unfamiliar external networks. + + +*Possible investigation steps* + + +- Review `source.ip`, `source.as.organization.name`, and `source.geo` for the invoking network and determine whether it is expected for the principal in `aws.cloudtrail.user_identity.arn`. +- Inspect `aws.cloudtrail.request_parameters` for the `functionName` and `user_agent.original` for the client used. +- Determine whether the credential (`aws.cloudtrail.user_identity.access_key_id`) was recently seen used elsewhere or outside the Lambda runtime, which would corroborate credential theft. +- Correlate with other activity by the same principal from the same network, including data-plane access, IAM, or STS calls. + + +*False positive analysis* + + +- New legitimate networks (offices, VPNs, home IPs, new egress) will generate this alert. Confirm the principal and network are expected and exclude known operator networks or identities after validation. +- If source ASN is legitimate and expected, add as an exclusion to reduce false-positives. + + +*Response and remediation* + + +- If credential abuse is confirmed, rotate or revoke the affected credentials and execution-role permissions, and review what the invoked function accessed or returned. +- Constrain `lambda:InvokeFunction` to expected identities and, where possible, restrict invocation to known networks using IAM conditions. + + +*Additional information* + + +- https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html[Invoke API] +- https://docs.aws.amazon.com/lambda/latest/dg/logging-using-cloudtrail.html[Logging Lambda data events with CloudTrail] + + +==== Setup + + + +*Setup* + + +This rule requires AWS Lambda data events to be logged in CloudTrail and ingested via the AWS integration +(`aws.cloudtrail` data stream). Lambda invocation (`Invoke`) is a data-plane event and is NOT logged by default; enable +data event logging for Lambda functions in the trail (optionally scoped to sensitive functions to manage volume). Source +ASN enrichment (`source.as.organization.name`) must be available on the ingested events. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "lambda.amazonaws.com" + and event.action: Invoke* + and event.outcome: "success" + and not aws.cloudtrail.user_identity.invoked_by: * + and source.as.organization.name:(* and not (Amazon* or AMAZON* or Google* or GOOGLE* or Microsoft* or MICROSOFT*)) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Serverless Execution +** ID: T1648 +** Reference URL: https://attack.mitre.org/techniques/T1648/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-aws-sagemaker-notebook-lifecycle-configuration-with-suspicious-script-content.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-aws-sagemaker-notebook-lifecycle-configuration-with-suspicious-script-content.asciidoc new file mode 100644 index 0000000000..4e54f2abfa --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-aws-sagemaker-notebook-lifecycle-configuration-with-suspicious-script-content.asciidoc @@ -0,0 +1,123 @@ +[[prebuilt-rule-8-19-27-aws-sagemaker-notebook-lifecycle-configuration-with-suspicious-script-content]] +=== AWS SageMaker Notebook Lifecycle Configuration With Suspicious Script Content + +Identifies an Amazon SageMaker notebook lifecycle configuration whose OnStart or OnCreate script, after base64 decoding, contains patterns associated with malicious activity such as reverse shells, EC2 instance metadata (IMDS) credential access, or download-and-execute commands. A lifecycle configuration runs as root on the notebook instance, so a script with these patterns is a strong indicator of an attempt to backdoor the notebook, steal the execution role's credentials, or establish persistent code execution. This rule decodes the script in the request and matches high-signal indicators; it is a higher-fidelity companion to the rule that alerts on any lifecycle configuration change. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 10m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/sagemaker/latest/dg/notebook-lifecycle-config.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS SageMaker +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Execution +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS SageMaker Notebook Lifecycle Configuration With Suspicious Script Content* + + +A SageMaker notebook lifecycle configuration is a shell script that runs as root on the notebook instance at create or start. This rule base64-decodes the OnStart/OnCreate script from the request (surfaced as "Esql_priv.aws_cloudtrail_lifecycle_script") and flags high-signal indicators across several categories: reverse shells ("/dev/tcp/", "/dev/udp/", "bash -i", "nc -e", "ncat", "socat", "mkfifo", "import socket", "pty.spawn", "perl"/"ruby"/"php" socket idioms), IMDS credential access ("169.254.169.254", "/latest/meta-data/", "/latest/api/token"), download-and-execute and decode-and-execute ("| sh", "| bash", "base64 -d"), cryptominers ("xmrig", "minerd", "stratum+"), and persistence ("authorized_keys", "crontab", "/etc/cron"). A match is a strong indicator of an implant attempt. + + +*Possible investigation steps* + + +- Review the decoded "Esql_priv.aws_cloudtrail_lifecycle_script" field and the full "aws.cloudtrail.request_parameters" to understand what the script does. +- Identify the actor in "aws.cloudtrail.user_identity.arn" and review "source.ip" and "user_agent.original" for an unexpected origin. +- Determine which notebook instances reference this configuration and whether they have started since the change. +- Correlate with adjacent activity by the same principal, such as notebook creation, presigned URL generation, or use of the execution role's credentials outside SageMaker. + + +*False positive analysis* + + +- Setup scripts can legitimately reference metadata endpoints or download tooling. Confirm the script is expected and exclude known automation roles after validation. This rule only matches unobfuscated indicators, so it can miss obfuscated scripts (use the broad lifecycle-configuration-change rule for full coverage) and can match benign scripts that contain these strings. + + +*Response and remediation* + + +- If unauthorized, remove the lifecycle configuration, stop affected notebook instances, and rotate the notebook execution role's credentials. +- Review actions taken by the execution role since the change, and restrict "sagemaker:CreateNotebookInstanceLifecycleConfig" and "sagemaker:UpdateNotebookInstanceLifecycleConfig" to trusted administrators. + + +==== Setup + + +This rule requires AWS CloudTrail logs ingested via the Elastic AWS integration. See https://docs.elastic.co/integrations/aws/cloudtrail for setup details. + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-aws.cloudtrail-* METADATA _id, _version, _index +| WHERE event.provider == "sagemaker.amazonaws.com" + AND event.action IN ("CreateNotebookInstanceLifecycleConfig", "UpdateNotebookInstanceLifecycleConfig") + AND event.outcome == "success" + AND aws.cloudtrail.user_identity.type != "AWSService" +| GROK aws.cloudtrail.request_parameters "[Cc]ontent=(?[A-Za-z0-9+/=]+)" +| EVAL Esql_priv.aws_cloudtrail_lifecycle_script = FROM_BASE64(script_b64) +| WHERE TO_LOWER(Esql_priv.aws_cloudtrail_lifecycle_script) RLIKE """.*(/dev/tcp/|/dev/udp/|bash -i|sh -i|nc -e|ncat |socat |mkfifo|169\.254\.169\.254|/latest/meta-data/|/latest/api/token|\| ?sh|\| ?bash|base64 -d|import socket|pty\.spawn|perl -e|ruby -rsocket|php -r|xmrig|minerd|stratum\+|authorized_keys|/etc/cron|crontab ).*""" +| KEEP _id, _version, _index, @timestamp, aws.*, cloud.*, event.*, source.*, user.*, user_agent.*, Esql_priv.aws_cloudtrail_lifecycle_script + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-azure-ad-graph-access-with-unusual-user-and-asn.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-azure-ad-graph-access-with-unusual-user-and-asn.asciidoc new file mode 100644 index 0000000000..711a051fab --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-azure-ad-graph-access-with-unusual-user-and-asn.asciidoc @@ -0,0 +1,136 @@ +[[prebuilt-rule-8-19-27-azure-ad-graph-access-with-unusual-user-and-asn]] +=== Azure AD Graph Access with Unusual User and ASN + +Identifies Azure AD Graph (graph.windows.net) requests originating from network sources outside the major public-cloud and Microsoft ASNs that legitimate first-party callers normally come from. Adversary tooling typically rides on commodity hosting (residential ISPs, VPS providers, anonymisers) which produces an ASN distribution very different from the Microsoft / AWS / GCP / Akamai / Cloudflare ranges that dominate legitimate AAD Graph traffic. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-azure.aadgraphactivitylogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/graph/migrate-azure-ad-graph-overview +* https://github.com/dirkjanm/ROADtools + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Data Source: Azure AD Graph +* Data Source: Azure AD Graph Activity Logs +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Tactic: Initial Access +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure AD Graph Access with Unusual User and ASN* + + +Legitimate AAD Graph callers in most tenants come from a small set of ASNs: Microsoft itself, the major +hyperscalers (AWS, GCP), and a handful of CDN / edge -networks that proxy first-party traffic. AAD Graph +traffic originating from outside that set, especially from residential ISPs, generic VPS providers, or +anonymising networks, is a signal worth a closer look. This rule excludes the common Microsoft / AWS / +GCP / Akamai / Cloudflare ASN organisations and surfaces everything else. + + +*Possible investigation steps* + + +- Identify the ASN and the geographic context. + - `source.as.organization.name`, `source.as.number`, `source.geo.country_name`, `source.geo.city_name`. +- Identify the user and whether the source matches normal behavior. + - `user.id` and recent legitimate sign-in geo / network for the same user. +- Cross-check user-agent and calling client for known offensive tooling fingerprints. + - `user_agent.original` (`aiohttp`, `AADInternals`, `curl`, etc.) and `azure.aadgraphactivitylogs.properties.app_id` (FOCI / first-party client IDs). +- Pivot to sign-in logs (`logs-azure.signinlogs-*`) for the same user / source IP to understand how the calling token was obtained. +- Check tenant-wide blast radius. + - Are other users in the tenant calling from the same ASN within the window? If so, treat as a systematic intrusion rather than a single account compromise. +- Confirm the activity is not attributable to authorized testing (red team engagement, penetration test, internal tooling validation) before treating as malicious. + + +*Response and remediation* + + +- Revoke refresh tokens and active sessions for the calling user. + - `POST /v1.0/users/{id}/revokeSignInSessions`. +- Temporarily disable the user if the alert is high-confidence or you need to halt further activity while investigation continues. + - `PATCH /v1.0/users/{id}` with body `{"accountEnabled": false}`. +- Check for device registrations created by the user during or around the burst window and remove rogue devices. + - `GET /v1.0/users/{id}/registeredDevices` and `GET /v1.0/users/{id}/ownedDevices`, then `DELETE /v1.0/devices/{deviceObjectId}`. + - Do this BEFORE session revocation: device-bound PRTs survive `revokeSignInSessions`. +- Apply Conditional Access requiring compliant device or trusted network for AAD Graph access for the affected user population. +- If the ASN belongs to known abusive infrastructure, add it to a tenant block list (Named Locations / CA policy). + + +==== Setup + + + +*Azure AD Graph Activity Logs* + +Requires Azure AD Graph Activity Logs ingested into `logs-azure.aadgraphactivitylogs-*` via the Elastic Azure +integration. Enable the `AzureADGraphActivityLogs` diagnostic-settings category on Entra ID. ASN enrichment +depends on the geoip / ASN ingest pipelines applied during integration ingestion. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.aadgraphactivitylogs and + user.id:* and source.as.number:(* and + not ( + 3598 or 7224 or 8068 or 8069 or 8070 or + 8071 or 8072 or 8073 or 8074 or 8075 or + 8987 or 12076 or 14618 or 15169 or 16509 or + 19527 or 36040 or 36384 or 36385 or 36492 or + 39111 or 394089 or 396982 + ) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-base64-decoded-payload-piped-to-interpreter.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-base64-decoded-payload-piped-to-interpreter.asciidoc new file mode 100644 index 0000000000..825b56319b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-base64-decoded-payload-piped-to-interpreter.asciidoc @@ -0,0 +1,210 @@ +[[prebuilt-rule-8-19-27-base64-decoded-payload-piped-to-interpreter]] +=== Base64 Decoded Payload Piped to Interpreter + +This rule detects when a base64 decoded payload is piped to an interpreter on Linux systems. Adversaries may use base64 encoding to obfuscate data and pipe it to an interpreter to execute malicious code. This technique may be used to evade detection by host- or network-based security controls. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* +* logs-crowdstrike.fdr* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Execution +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Data Source: Crowdstrike + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Base64 Decoded Payload Piped to Interpreter* + + +Base64 encoding is a method to encode binary data into ASCII text, often used for data obfuscation. Adversaries exploit this by encoding malicious payloads and decoding them on a target system, piping the output to interpreters like bash or python for execution. The detection rule identifies such activities by monitoring for processes that decode Base64 and subsequently execute scripts, indicating potential malicious behavior. + + +*Possible investigation steps* + + +- Review the process command line arguments to identify the specific Base64 decoding activity, focusing on the presence of flags like `-d` or `-a` in conjunction with tools such as `base64`, `openssl`, or scripting languages like `python`, `perl`, or `ruby`. +- Examine the parent process entity ID and command line to understand the context in which the Base64 decoding was initiated, identifying any potentially suspicious parent processes. +- Investigate the subsequent interpreter process that was executed, such as `bash`, `python`, or `ruby`, to determine the nature of the script or command being run, looking for any signs of malicious activity. +- Check the timing and sequence of the processes involved to confirm if the Base64 decoding and interpreter execution occurred within the specified maxspan of 3 seconds, indicating a likely automated or scripted action. +- Analyze the host ID and any associated user accounts to determine if the activity aligns with expected behavior for that system or user, or if it suggests unauthorized access or compromise. +- Correlate the alert with other security events or logs from the same host or user to identify any additional indicators of compromise or related suspicious activities. + + +*False positive analysis* + + +- Legitimate administrative scripts may use Base64 encoding to handle data securely. Review the context of the script execution and consider excluding specific scripts or directories from monitoring if they are verified as safe. +- Automated backup or data transfer processes might use Base64 encoding for data integrity. Identify these processes and create exceptions for known, trusted applications or scripts. +- Development environments often use Base64 encoding for testing purposes. If a development tool or script is frequently triggering alerts, consider excluding the specific development environment or user accounts from this rule. +- Security tools or monitoring solutions may use Base64 encoding as part of their normal operations. Verify the source of the alert and exclude known security tools from triggering this rule. +- System updates or package installations might involve Base64 operations. Monitor the timing and context of these alerts and exclude specific update processes if they are consistently identified as false positives. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further execution of potentially malicious code and lateral movement. +- Terminate any suspicious processes identified by the detection rule, particularly those involving base64 decoding and piping to interpreters. +- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise, such as unauthorized file modifications or network connections. +- Restore the system from a known good backup if malicious activity is confirmed and the integrity of the system is compromised. +- Update and patch all software and systems to mitigate vulnerabilities that could be exploited by similar techniques. +- Implement enhanced monitoring and logging for base64 decoding activities and interpreter executions to detect similar threats in the future. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if broader organizational impacts exist. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id, process.parent.entity_id with maxspan=3s + [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "ProcessRollup2") and ( + (process.name in ("base64", "base64plain", "base64url", "base64mime", "base64pem", "base32", "base16") and process.command_line like~ "*-*d*") or + (process.name == "openssl" and process.args == "enc" and process.args in ("-d", "-base64", "-a")) or + (process.name like "python*" and + (process.args == "base64" and process.args in ("-d", "-u", "-t")) or + (process.args == "-c" and process.args like "*base64*" and process.command_line like~ "*b64decode*") + ) or + (process.name like "perl*" and process.command_line like~ "*decode_base64*") or + (process.name like "ruby*" and process.args == "-e" and process.command_line like~ "*Base64.decode64*") + )] + [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "ProcessRollup2") and process.name like~ ( + "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "python*", "perl*", "ruby*", "lua*", "php*" + ) and + not ( + ?process.parent.command_line in ( + "bash ./run_tests.sh unit-integration", + "/bin/sh /var/lib/dpkg/info/nmap-common.postinst configure", + "bash -c base64 -d <<< Zm9yIHN2YyBpbiBxZW11LWt2bSBvdnMtdnN3aXRjaGQgbGlidmlydGQgdmlydGxvY2tkIHBhY2VtYWtlciBwY3NkOyBkbyBzeXN0ZW1jdGwgaXMtYWN0aXZlICRzdmM7IGRvbmU= | bash -l" + ) or + process.command_line == "/usr/bin/perl /usr/bin/shasum -a 256" or + ?process.working_directory like ( + "/usr/local/zeek", "/opt/zeek", "/var/lib/docker/overlay2/*/opt/zeek", "/usr/local/zeek_old_install", + "/var/lib/docker/overlay2/*/usr/local/zeek", "/proc/self/fd/*/usr/local/zeek" + ) or + (?process.parent.name == "zsh" and ?process.parent.command_line like "*extendedglob*") or + (process.name like "python*" and ?process.parent.name == "python*") or + process.args like "/tmp/apt-key-gpghome*" or + ?process.parent.executable like ("/home/*/.aimee-code/bin/claude", "/home/*/.aimee-code/bin/opencode") or + ?process.parent.command_line like "*/home/*/.claude/shell-snapshots/snapshot-*" + )] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Obfuscated Files or Information +** ID: T1027 +** Reference URL: https://attack.mitre.org/techniques/T1027/ +* Technique: +** Name: Deobfuscate/Decode Files or Information +** ID: T1140 +** Reference URL: https://attack.mitre.org/techniques/T1140/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Sub-technique: +** Name: Python +** ID: T1059.006 +** Reference URL: https://attack.mitre.org/techniques/T1059/006/ +* Sub-technique: +** Name: Lua +** ID: T1059.011 +** Reference URL: https://attack.mitre.org/techniques/T1059/011/ +* Technique: +** Name: User Execution +** ID: T1204 +** Reference URL: https://attack.mitre.org/techniques/T1204/ +* Sub-technique: +** Name: Malicious File +** ID: T1204.002 +** Reference URL: https://attack.mitre.org/techniques/T1204/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-credential-acquisition-via-registry-hive-dumping.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-credential-acquisition-via-registry-hive-dumping.asciidoc new file mode 100644 index 0000000000..46afd9f3e5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-credential-acquisition-via-registry-hive-dumping.asciidoc @@ -0,0 +1,179 @@ +[[prebuilt-rule-8-19-27-credential-acquisition-via-registry-hive-dumping]] +=== Credential Acquisition via Registry Hive Dumping + +Identifies attempts to export a registry hive which may contain credentials using the Windows reg.exe tool. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://medium.com/threatpunter/detecting-attempts-to-steal-passwords-from-the-registry-7512674487f8 +* https://www.elastic.co/security-labs/detect-credential-access + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Sysmon +* Data Source: Crowdstrike + +*Version*: 318 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Credential Acquisition via Registry Hive Dumping* + + + +*Possible investigation steps* + + +- What exact hive-export behavior did the alert capture? + - Focus: `process.command_line`, `process.executable`, `process.pe.original_file_name`, and `process.code_signature.subject_name`. + - Implication: escalate if the command saves or exports SAM or SECURITY to temp, public, admin-share, UNC, removable, or deceptive paths; lower suspicion only when the signed Microsoft reg.exe identity, destination, and export set fit the same recognized backup, recovery, forensic, or break-glass workflow. Identity alone never clears the export. + +- Does the parent and session context explain why credential-bearing hives were exported? + - Focus: `process.parent.executable`, `process.parent.command_line`, `process.Ext.session_info.logon_type`, and `user.id`. + - Hint: If the parent is generic and lineage remains unclear, expand ancestry before accepting a maintenance explanation. + - Implication: escalate when an interactive shell, script host, RMM tool, service account, remote-style session, or unexpected user initiated the export; lower suspicion when the same user or service identity, parent workflow, and session type recur for a recognized backup, recovery, forensic, or break-glass process. + +- Did the alert parent launch accompanying SYSTEM export, staging, transfer, cleanup, or alternate dump commands? + - Focus: process events from the alert parent and reg.exe children, using `process.parent.entity_id`, `process.parent.pid`, `process.executable`, and `process.command_line`. !{investigate{"description":"","label":"Processes from same parent as alert","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.pid","queryType":"phrase","value":"{{process.parent.pid}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} !{investigate{"description":"","label":"Child processes of reg.exe","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: If `process.parent.entity_id` is absent, use the `host.id` + alert `process.parent.pid` branch in a tight alert-time window; if reg.exe spawned a helper, pivot from alert `process.entity_id` to child `process.parent.entity_id`. + - Hint: If file or network telemetry is available, recover file activity and connections for reg.exe and its children to identify hive output, archives, share writes, removable-media staging, or off-host transfer. Missing network telemetry is unresolved, not benign. !{investigate{"description":"","label":"File activity for reg.exe and children","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} !{investigate{"description":"","label":"Network activity for reg.exe and children","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when the same parent exports SYSTEM, packages, copies, deletes, or transfers hive output, or launches vssadmin.exe, diskshadow.exe, or shadow-copy paths to continue dumping outside this rule; absence of same-parent support reduces staging evidence but does not clear the original export. + +- Does the host role or hive combination raise credential-exposure severity? + - Focus: `host.id`, `host.name`, and `process.command_line`, plus asset or case records only as corroboration. + - Hint: Do not infer privileged role from `host.name` alone. + - Implication: raise urgency when asset context or host history identifies a jump host, backup node, admin workstation, server, or shared management platform, or when same-parent process review confirms SYSTEM was exported with SAM or SECURITY; lower urgency only when the host role and export set fit the same recognized workflow. + +- If local evidence remains suspicious or unresolved, does related alert scope show broader credential-access activity? + - Focus: related alerts for the same `user.id` and `host.id`, looking for credential dumping, archiving, privilege escalation, persistence, or lateral movement. + - Hint: Start with same-user alerts. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: Compare same-host alerts. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden scope and credential review when related alerts show complementary abuse; keep the case local when related alert scope is quiet and local telemetry already binds the export to one recognized workflow. + +- Based on the evidence gathered, what disposition is supported? + - Focus: binary identity, hive targets and output path, parent/session context, same-parent or child-process activity, host exposure, and related-alert scope. + - Implication: escalate when an unrecognized SAM or SECURITY export has a risky destination, suspicious lineage or session, follow-on staging, privileged-host exposure, or related credential-access alerts; close only when the same evidence categories bind one exact recognized workflow on this host, with outside confirmation if telemetry cannot prove legitimacy; preserve artifacts and escalate when evidence is mixed or incomplete. + + +*False positive analysis* + + +- Backup, recovery, forensic, or break-glass workflows can legitimately export SAM or SECURITY hives. Confirm that the signed Microsoft utility identity, command-line hive and destination pattern, parent workflow, session context, `user.id`, `host.id`, host role, and same-parent or child-process activity all align with the same workflow. If telemetry cannot prove legitimacy, use case records, change records, or owner confirmation only as corroboration for that exact activity. If any evidence dimension contradicts the workflow, do not close as benign. +- Before creating an exception, validate that the same `process.executable`, `process.code_signature.subject_name`, `process.parent.command_line`, `process.command_line` hive/destination pattern, `user.id`, and `host.id` recur across prior alerts from this rule. Build from that minimum confirmed pattern. Avoid exceptions on `process.name`, reg.exe, the hive name, or the host alone. + + +*Response and remediation* + + +- If confirmed benign, reverse any temporary restriction and document the recognized utility path, hive/destination pattern, parent and session context, `user.id`, `host.id`, host role, and corroborating case evidence that justified closure. Create an exception only if that same pattern recurs consistently across prior alerts from this rule. +- If suspicious but unconfirmed, preserve the alert record, process tree, `process.entity_id`, `process.command_line`, output path named in the command, same-parent or child-process command lines, session context, `user.id`, and `host.id` before containment or cleanup. Apply reversible containment tied to the findings, such as temporary share restriction or limited outbound access for the affected host; escalate to host isolation or account action only if staging, transfer commands, related alerts, or host criticality justify the impact. +- If confirmed malicious, preserve the same evidence set, then isolate the host if its role can tolerate it and the findings show unauthorized hive export or movement risk. Contain the responsible account only when the user/session evidence indicates account misuse. Terminate the process only after evidence capture if it is still running. +- Scope exposure from the copied material: SAM implies local account hash exposure; SECURITY implies LSA secret or cached-credential exposure; a same-parent SYSTEM export makes offline decryption more plausible and should raise urgency. +- Before deleting or rotating anything, review related `host.id` and `user.id` activity for the same command patterns, hive-copy names, archive names, share paths, transfer commands, and alternate copy methods such as vssadmin.exe, diskshadow.exe, or raw shadow-copy access. Then remove only the unauthorized dump scripts, archives, copied hive files, and persistence mechanisms identified during the investigation, and remediate the access path that allowed the export. +- Post-incident hardening: restrict hive export activity to recognized recovery or forensic workflows, document the confirmed `process.command_line` and destination patterns behind any exception, and retain process telemetry needed to distinguish future recovery work from repeated abuse. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + (?process.pe.original_file_name == "reg.exe" or process.name : "reg.exe") and + process.args : ("save", "export") and + process.args : ( + "hklm\\sam", "hklm\\security", "hklm\\system", + "hkey_local_machine\\sam", "hkey_local_machine\\security", "hkey_local_machine\\system" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Sub-technique: +** Name: Security Account Manager +** ID: T1003.002 +** Reference URL: https://attack.mitre.org/techniques/T1003/002/ +* Sub-technique: +** Name: LSA Secrets +** ID: T1003.004 +** Reference URL: https://attack.mitre.org/techniques/T1003/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-deprecated-tls-version-or-weak-cipher-negotiated-externally.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-deprecated-tls-version-or-weak-cipher-negotiated-externally.asciidoc new file mode 100644 index 0000000000..d48b851ea8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-deprecated-tls-version-or-weak-cipher-negotiated-externally.asciidoc @@ -0,0 +1,178 @@ +[[prebuilt-rule-8-19-27-deprecated-tls-version-or-weak-cipher-negotiated-externally]] +=== Deprecated TLS Version or Weak Cipher Negotiated Externally + +Identifies successful outbound TLS sessions that negotiate deprecated protocol versions (SSLv3, TLS 1.0, or TLS 1.1) or weak cipher suites such as RC4, 3DES, NULL, EXPORT, or anonymous Diffie-Hellman. Adversaries-in-the-middle and legacy malware often force these negotiations to decrypt or intercept traffic. Modern clients and services should negotiate TLS 1.2 or 1.3 with strong ciphers on internet-bound connections. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-network_traffic.tls-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1557/ +* https://www.elastic.co/docs/reference/integrations/network_traffic +* https://www.elastic.co/docs/reference/ecs/ecs-tls +* https://www.rfc-editor.org/rfc/rfc9325.html + +*Tags*: + +* Domain: Network +* Use Case: Network Security Monitoring +* Use Case: Threat Detection +* Data Source: Network Traffic +* Tactic: Credential Access +* Tactic: Command and Control +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Deprecated TLS Version or Weak Cipher Negotiated Externally* + + +TLS downgrade and weak-cipher negotiation expose sessions to interception or decryption. This rule flags completed +outbound TLS handshakes from internal hosts to external destinations that negotiated SSLv3, TLS 1.0, TLS 1.1, or a +cipher suite containing RC4, 3DES, NULL, EXPORT, or anonymous key exchange material. + + +*Possible investigation steps* + + +- Review `source.ip`, `destination.ip`, `destination.port`, `tls.version`, `tls.version_protocol`, and `tls.cipher`. +- Determine whether the destination is a known legacy partner, vendor appliance, or unmanaged IoT device. +- Check for concurrent alerts on the source host (credential access, C2, or proxy manipulation). +- Compare against baseline: does this destination normally negotiate modern TLS from other clients? + + +*False positive analysis* + + +- Exclude validated legacy B2B endpoints, mainframe gateways, or SCADA systems that cannot be upgraded immediately. +- Some older mobile or embedded clients may still offer weak ciphers even when connecting to modern services; confirm + whether the server accepted the weak option (this rule requires `tls.established:true`). + + +*Response and remediation* + + +- Block or proxy traffic to the destination if downgrade appears attacker-driven. +- Patch or replace the client or server that accepted deprecated TLS. +- Enable TLS 1.2+ minimums on egress proxies and inspect for MITM appliances forcing weak negotiation. + + +==== Setup + + + +*Setup* + + +This rule requires TLS metadata from the Elastic network_traffic integration (`network_traffic.tls` data stream) that +populates ECS `tls.version`, `tls.version_protocol`, `tls.cipher`, and `tls.established` fields. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:network_traffic.tls + and network.protocol: tls + and network.transport: tcp + and tls.established: true + and source.ip:(10.0.0.0/8 or 172.16.0.0/12 or 192.168.0.0/16) + and not destination.ip:( + 10.0.0.0/8 or + 100.64.0.0/10 or + 127.0.0.0/8 or + 169.254.0.0/16 or + 172.16.0.0/12 or + 192.0.0.0/24 or + 192.0.0.0/29 or + 192.0.0.10/32 or + 192.0.0.170/32 or + 192.0.0.171/32 or + 192.0.0.8/32 or + 192.0.0.9/32 or + 192.0.2.0/24 or + 192.168.0.0/16 or + 192.175.48.0/24 or + 192.31.196.0/24 or + 192.52.193.0/24 or + 192.88.99.0/24 or + 198.18.0.0/15 or + 198.51.100.0/24 or + 203.0.113.0/24 or + 224.0.0.0/4 or + 240.0.0.0/4 or + "::1" or + "FE80::/10" or + "FF00::/8" + ) + and ( + tls.version:(1.0 or 1.1) or + (tls.version_protocol:ssl and tls.version:3.0) or + ( + not tls.version:1.3 and ( + tls.cipher:( + *RC4* or + *3DES* or + *NULL* or + *EXPORT* or + *_anon_* or + *ADH* or + *AECDH* + ) + ) + ) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Adversary-in-the-Middle +** ID: T1557 +** Reference URL: https://attack.mitre.org/techniques/T1557/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Encrypted Channel +** ID: T1573 +** Reference URL: https://attack.mitre.org/techniques/T1573/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-entra-id-oauth-device-code-phishing-via-aitm.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-entra-id-oauth-device-code-phishing-via-aitm.asciidoc new file mode 100644 index 0000000000..1b955a1380 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-entra-id-oauth-device-code-phishing-via-aitm.asciidoc @@ -0,0 +1,133 @@ +[[prebuilt-rule-8-19-27-entra-id-oauth-device-code-phishing-via-aitm]] +=== Entra ID OAuth Device Code Phishing via AiTM + +Detects successful Microsoft Entra ID sign-ins that use the OAuth device code authentication protocol with the Microsoft Authentication Broker client requesting first-party Office API resources (Exchange Online, Microsoft Graph, or SharePoint) while flagged as interactive. This pattern is associated with adversary-in-the-middle (AiTM) phishing kits such as Tycoon 2FA, where victims complete device code flows that ultimately broker tokens for mail and collaboration APIs. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.signinlogs-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://any.run/malware-trends/tycoon/ +* https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-authentication-flows +* https://www.microsoft.com/en-us/security/blog/2025/02/13/storm-2372-conducts-device-code-phishing-campaign/ + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Sign-in Logs +* Use Case: Threat Detection +* Threat: Tycoon2FA +* Tactic: Initial Access +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID OAuth Device Code Phishing via AiTM* + + +Review `azure.signinlogs.properties.user_principal_name`, `azure.signinlogs.properties.session_id`, `source.ip`, +`user_agent.original`, and `azure.signinlogs.properties.resource_display_name` for context around the device code +completion. + +Confirm whether the user knowingly entered a device code (for example on a shared or headless device) and whether +broker-mediated access to Exchange, Graph, or Yammer is expected for that account. + + +*Possible investigation steps* + + +- Interview the user about recent links, QR codes, or prompts to approve a device code. +- Correlate with `azure.signinlogs` and Microsoft 365 audit logs for mailbox, Teams, or file access from the same + session or IP shortly after the event. +- Review conditional access and MFA satisfaction details for the same `session_id`. + + +*Response and remediation* + + +- If malicious, revoke refresh tokens for the user, reset credentials per policy, and review application consent. +- Block or monitor the source IP and escalate per incident procedures. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"azure.signinlogs" and event.category:"authentication" and event.action:"Sign-in activity" and +event.outcome:success and azure.signinlogs.properties.app_id:"29d9ed98-a469-4536-ade2-f981bc1d605e" and +azure.signinlogs.properties.authentication_protocol:deviceCode and +azure.signinlogs.properties.resource_id:( + "00000002-0000-0ff1-ce00-000000000000" or + "00000003-0000-0ff1-ce00-000000000000" or + "00000003-0000-0000-c000-000000000000" +) and azure.signinlogs.properties.is_interactive:true + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Sub-technique: +** Name: Spearphishing Link +** ID: T1566.002 +** Reference URL: https://attack.mitre.org/techniques/T1566/002/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-first-time-seen-dns-query-to-rmm-domain.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-first-time-seen-dns-query-to-rmm-domain.asciidoc new file mode 100644 index 0000000000..d97fdb8fb6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-first-time-seen-dns-query-to-rmm-domain.asciidoc @@ -0,0 +1,367 @@ +[[prebuilt-rule-8-19-27-first-time-seen-dns-query-to-rmm-domain]] +=== First Time Seen DNS Query to RMM Domain + +Detects DNS queries to commonly abused remote monitoring and management (RMM) or remote access software domains from processes that are not browsers. Intended to surface RMM clients, scripts, or other non-browser activity contacting these services. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-7205m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1219/002/ +* https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-025a +* https://lolrmm.io/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Command and Control +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Sysmon + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating First Time Seen DNS Query to RMM Domain* + + +This rule flags DNS queries to commonly abused RMM or remote access domains when the requesting process is not a browser. Legitimate RMM and remote desktop software is frequently abused for C2, persistence, and lateral movement. + + +*Possible investigation steps* + + +- Identify the process process.executable that performed the DNS query and verify if it is an approved RMM or remote access tool. +- Review the full process tree and parent process to understand how the binary was launched. +- Check process.code_signature for trusted RMM publishers; unsigned or unexpected signers may indicate abuse or trojanized installers. +- Correlate with the companion rule "First Time Seen Remote Monitoring and Management Tool" for the same host to see if the RMM process was first-time seen. +- Investigate other alerts for the same host or user in the past 48 hours. + + +*False positive analysis* + + +- Approved RMM or remote support tools used by IT will trigger this rule; consider allowlisting by process path or code signer for known managed tools. +- Some updaters or installers (e.g. signed by the RMM vendor) may resolve these domains; combine with process name or parent context to reduce noise. + + +*Response and remediation* + + +- If unauthorized RMM use is confirmed: isolate the host, remove the RMM software, rotate credentials, and block the domains at DNS/firewall where policy permits. +- Enforce policy that only approved RMM tools from approved publishers may be used, and only by authorized staff. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sysmon-event-22-setup[Sysmon Event ID 22 - DNS Query] + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-endpoint.events.network-*, logs-windows.sysmon_operational-* METADATA _index +| WHERE host.os.type == "windows" + AND event.category == "network" + AND event.action in ("lookup_requested", "DNSEvent (DNS query)") + AND dns.question.name IS NOT NULL + +// Exclude browser processes +| WHERE NOT + process.name IN ( + "chrome.exe", "msedge.exe", "MicrosoftEdge.exe", "MicrosoftEdgeCP.exe", + "firefox.exe", "iexplore.exe", "safari.exe", "brave.exe", + "opera.exe", "vivaldi.exe", "msedgewebview2.exe" + ) + +// Extract the parent domain (last two labels, e.g. example.com) +| GROK dns.question.name """(?:[^.]+\.)+(?[^.]+\.[^.]+)$""" +| EVAL parent_domain = COALESCE(parent_domain, dns.question.name) + +// Known RMM parent domains, add or remove entries here as your environment changes. +| WHERE parent_domain IN ( + "01com.com", + "247ithelp.com", + "action1.com", + "addigy.com", + "aeroadmin.com", + "ammyy.com", + "anydesk.com", + "anyplace-control.com", + "anysupport.net", + "atera.com", + "aurelius.host", + "auvik.com", + "aweray.com", + "aweray.net", + "backdrop.cloud", + "barracudamsp.com", + "beamyourscreen.com", + "beanywhere.com", + "beinsync.com", + "beinsync.net", + "beyondtrustcloud.com", + "bomgar.com", + "bomgarcloud.com", + "centrastage.net", + "centuriontech.com", + "connectwise.com", + "crossloop.com", + "dameware.com", + "datto.com", + "datto.net", + "deskday.ai", + "deskroll.com", + "desktopstreaming.com", + "distantdesktop.com", + "donkz.nl", + "dwservice.net", + "ehorus.com", + "electric.ai", + "emcosoftware.com", + "ericom.com", + "fastsupport.com", + "fastviewer.com", + "fixme.it", + "fleetdeck.io", + "gatherplace.com", + "gatherplace.net", + "getgo.com", + "getscreen.me", + "gotoassist.at", + "gotoassist.com", + "gotoassist.me", + "gotohttp.com", + "gotoresolve.com", + "goverlan.com", + "heartbeatrm.com", + "helpme.net", + "helpwire.app", + "hoptodesk.com", + "hostedrmm.com", + "immy.bot", + "immybot.com", + "imperosoftware.com", + "instanthousecall.com", + "instanthousecall.net", + "intelliadmin.com", + "internapcdn.net", + "internetid.ru", + "iperius-rs.com", + "iperius.net", + "iperiusremote.com", + "islonline.com", + "islonline.net", + "itarian.com", + "itsupport247.net", + "jumpcloud.com", + "jumpdesktop.com", + "jumpto.me", + "kabuto.io", + "kabutoservices.com", + "kaseya.com", + "kaseya.net", + "kickidler.com", + "laplink.com", + "level.io", + "liongard.com", + "litemanager.com", + "litemanager.ru", + "logicnow.com", + "logmein-gateway.com", + "logmein.com", + "logmeininc.com", + "logmeinrescue.com", + "logmeinrescue.eu", + "lunixar.com", + "meshcentral.com", + "mikogo.com", + "mikogo4.com", + "miradore.com", + "msp360.com", + "mygreenpc.com", + "n-able.com", + "naverisk.com", + "nchuser.com", + "netop.com", + "netsupportmanager.com", + "netsupportsoftware.com", + "netviewer.com", + "ninjaone.com", + "ninjarmm.com", + "ninjarmm.net", + "nomachine.com", + "ntrsupport.com", + "opti-tune.com", + "optitune.us", + "oray.com", + "oray.net", + "panorama9.com", + "parsec.app", + "parsecusercontent.com", + "pcvisit.de", + "pilixo.com", + "playanext.com", + "pulseway.com", + "qetqo.com", + "r-hud.net", + "real-time-collaboration.com", + "remmon.hu", + "remote.it", + "remote.management", + "remotecall.com", + "remotedesktop.com", + "remotepc.com", + "remotetopc.com", + "remoteutilities.com", + "remotix.com", + "remotly.com", + "repairshopr.com", + "rmansys.ru", + "rmmservice.ca", + "rmmservice.eu", + "royalapps.com", + "rport.io", + "rudesktop.ru", + "rustdesk.com", + "rview.com", + "screenconnect.com", + "screenmeet.com", + "scrn.mt", + "servably.com", + "server-eye.de", + "set.me", + "setme.net", + "showmypc.com", + "signalserver.xyz", + "simple-help.com", + "skyfex.com", + "sorillus.com", + "splashtop.com", + "splashtop.eu", + "spyanywhere.com", + "spytech-web.com", + "startsupport.com", + "superops.ai", + "superops.com", + "superopsalpha.com", + "superopsbeta.com", + "supremocontrol.com", + "swi-rc.com", + "swi-tc.com", + "syncroapi.com", + "syncromsp.com", + "syspectr.com", + "system-monitor.com", + "systemmonitor.us", + "tacticalrmm.com", + "tailscale.com", + "teamviewer.com", + "techinline.net", + "tele-desk.com", + "tiflux.com", + "tightvnc.com", + "tmate.io", + "todesk.com", + "twingate.com", + "ultraviewer.net", + "ultravnc.com", + "vnc.com", + "weezo.me", + "weezo.net", + "xeox.com", + "zoho.eu", + "zohoassist.com", + "zohoassist.jp" +) + +// Aggregate by parent domain and get 1st time seen timestamp as well as unique count of agents +| STATS + event_count = COUNT(*), + Esql.first_time_seen = MIN(@timestamp), + Esql.count_distinct_host_id = COUNT_DISTINCT(host.id), + Esql.process_executable_values = VALUES(process.executable), + Esql.dns_question_name_values = VALUES(dns.question.name), + Esql.host_name_values = VALUES(host.name), + Esql.host_id_values = VALUES(host.id), + Esql.user_name_values = VALUES(user.name), + Esql.user_id_values = VALUES(user.id), + Esql.namespace_values = VALUES(data_stream.namespace) BY parent_domain + +// Calculate the time difference between first time seen and rule execution time +| eval Esql.recent = DATE_DIFF("minute", Esql.first_time_seen, now()) + +// First time seen is within 6m of the rule execution time and first seen in the last 5 days as per the rule from schedule and limited to 1 unique host +| where Esql.recent <= 6 and Esql.count_distinct_host_id == 1 + +// populate fields for rule exception and triage +| eval host.name = MV_FIRST(Esql.host_name_values), + host.id = MV_FIRST(Esql.host_id_values), + user.name = MV_FIRST(Esql.user_name_values), + user.id = MV_FIRST(Esql.user_id_values), + data_stream.namespace = MV_FIRST(Esql.namespace_values), + process.executable = MV_FIRST(Esql.process_executable_values), + dns.question.name = MV_FIRST(Esql.dns_question_name_values) +| keep host.name, host.id, user.name, user.id, data_stream.namespace, process.executable, dns.question.name, Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Remote Access Tools +** ID: T1219 +** Reference URL: https://attack.mitre.org/techniques/T1219/ +* Sub-technique: +** Name: Remote Desktop Software +** ID: T1219.002 +** Reference URL: https://attack.mitre.org/techniques/T1219/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-first-time-seen-remote-monitoring-and-management-tool.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-first-time-seen-remote-monitoring-and-management-tool.asciidoc new file mode 100644 index 0000000000..fe34886fdf --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-first-time-seen-remote-monitoring-and-management-tool.asciidoc @@ -0,0 +1,391 @@ +[[prebuilt-rule-8-19-27-first-time-seen-remote-monitoring-and-management-tool]] +=== First Time Seen Remote Monitoring and Management Tool + +Adversaries may install legitimate remote monitoring and management (RMM) tools or remote access software on compromised endpoints for command-and-control (C2), persistence, and execution of native commands. This rule detects when a process is started whose name or code signature matches commonly abused RMM or remote access tools. New Terms type: the host.id and process.name pair has not been seen before within the configured 7-day history window. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.process-* +* endgame-* +* winlogbeat-* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* logs-system.security* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://thedfirreport.com/2023/04/03/malicious-iso-file-leads-to-domain-wide-ransomware/ +* https://github.com/redcanaryco/surveyor/blob/master/definitions/remote-admin.json +* https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-025a +* https://www.cisa.gov/sites/default/files/2025-06/aa25-163a-ransomware-simplehelp-rmm-compromise.pdf +* https://lolrmm.io/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Command and Control +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Windows Security Event Logs +* Data Source: Sysmon + +*Version*: 118 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating First Time Seen Remote Monitoring and Management Tool* + + + +*Possible investigation steps* + + +- Validate the alert-local process event and identify the matched RMM artifact. + - Focus: `host.name`, `host.id`, `process.name`, `process.executable`, `process.code_signature.subject_name`. + - Review the exact process entity on the alerted host with !{investigate{"description":"Find the exact alerted process entity on the same host around the alert window.","label":"Matched process context","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: The alert proves one Windows process start from the supported process data sources where the `host.id` and `process.name` pair is first seen within the 7-day new terms window; it does not prove the remote session or legitimacy. Close only if the exact host, account, process name, executable, signer, and support or deployment window match a validated change record or verified owner confirmation; otherwise continue. +- Determine why this RMM process is new for the host. + - Focus: `host.id`, `process.name`, `process.executable`, `process.command_line`, `process.hash.sha256`. + - Review same-host executions across the rule history window with !{investigate{"description":"Find same-host executions of the matched process name across the rule history window.","label":"Same host process name history","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.name","queryType":"phrase","value":"{{process.name}}","valueType":"string"}]],"relativeFrom":"now-7d/d","relativeTo":"now"}} + - Implication: Repeated executions clustered around the same deployment or support window can support a bounded benign explanation only when the exact executable, command line, hash, host, and account match the recovered business context. A new hash, renamed executable, unexpected arguments, or executions outside that window keep the case suspicious. +- Reconstruct the parent process and logon context that launched the tool. + - Focus: `process.parent.name`, `process.parent.executable`, `process.parent.command_line`, `process.Ext.session_info.logon_type`, `user.name`. + - Review the parent process entity on the same host with !{investigate{"description":"Recover events for the parent process entity that launched the matched RMM process.","label":"Parent process activity","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"}]],"relativeFrom":"now-24h","relativeTo":"now"}} + - Implication: A parent and session that match the same validated change record and account owner confirmation can bound the activity to one workflow. A launch from user-download, browser, archive, script, or unrelated service context is suspicious for social engineering or staged access. +- Inspect endpoint artifacts and child behavior before broader scoping. + - Focus: `process.entity_id`, `process.Ext.ancestry`, `process.args`, `process.working_directory`, `process.Ext.token.elevation_level`. + - Implication: Recover child process, service, file, registry, and persistence evidence from endpoint timeline or live host data before interpretation because those artifact fields are not guaranteed on the alert. Child execution, persistence, unusual working directories, or elevated token use by the matched RMM process supports escalation; absence of recoverable artifacts does not prove benign. +- If local process, parent, and endpoint-artifact evidence is suspicious or incomplete, broaden scope for the RMM hypothesis. + - Focus: `host.id`, `user.name`, `process.name`, `process.hash.sha256`, `process.code_signature.subject_name`. + - Review same host and account activity with !{investigate{"description":"Review activity by the same account on the same host before broader scoping.","label":"Host account activity","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"user.name","queryType":"phrase","value":"{{user.name}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Review the same executable hash across available process events with !{investigate{"description":"Find other executions of the same executable hash when local evidence is suspicious or unresolved.","label":"Executable hash scope","providers":[[{"excluded":false,"field":"process.hash.sha256","queryType":"phrase","value":"{{process.hash.sha256}}","valueType":"string"}]],"relativeFrom":"now-7d/d","relativeTo":"now"}} + - Implication: The hypothesis is RMM staging or reuse across hosts or accounts; matching hash activity, related alerts, or repeated account use should drive host and account scoping plus evidence preservation. No related alerts or hash matches only limits currently observed spread and does not prove benign; exact matches limited to the validated host, account, and time window may support closure after the earlier evidence aligns. + +Disposition: Escalate suspicious RMM artifacts, launch chains, or expanded scope; close only when alert-local evidence and recovered context prove one expected support or deployment workflow on the exact host and account; preserve and escalate mixed or incomplete cases for more context before final disposition. + + +*False positive analysis* + + +- Potential benign cases include first deployment of a remote support tool, first use after host rebuild, a product update that changes `process.name`, or a one-time support session only when alert-local and recovered process evidence match `host.id`, `user.name`, `process.name`, `process.executable`, `process.code_signature.subject_name`, `process.code_signature.trusted`, `process.pe.original_file_name`, and `process.hash.sha256` when available, and that evidence aligns with a verified owner confirmation or validated change record for the observed support or deployment window. +- Do not close on the tool name, signer, executable path, or lack of related alerts alone. Escalate when artifacts indicate social engineering, an unexpected parent or session, a renamed executable, hash mismatch, or unbounded account or host spread. +- Scope exceptions only to durable future-alert fields that match the validated benign workflow, using `host.id`, `user.name`, `process.name`, `process.executable`, `process.code_signature.subject_name`, `process.code_signature.trusted`, `process.pe.original_file_name`, and `process.hash.sha256` when available. Do not scope exceptions by prose-only groups such as support teams or known RMM activity; preserve and escalate mixed or incomplete cases instead of creating broad exclusions. + + +*Response and remediation* + + +- Preserve or export case evidence plus volatile process, memory, executable, or file-system artifacts that could be lost before isolation, process termination, cleanup, or other disruptive action. +- For confirmed malicious activity, scope first by reviewing the matched process, parent and child processes, persistence artifacts, same-hash executions, related alerts, and account activity across affected hosts. +- After evidence capture and initial scoping, isolate affected hosts or disable active remote access paths when containment is required to prevent continued access. +- After containment decisions and evidence review, terminate malicious RMM processes, remove persistence, clean up dropped files or services, revoke active sessions, and reset credentials exposed through the RMM session or related activity. +- If social engineering led to the remote access, validate the user interaction, collect relevant communications or download sources when available, and include affected accounts in credential review. +- Document confirmed indicators and logging or detection gaps for the responsible detection or logging owners after scoping and containment. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type: "windows" and + event.category: "process" and event.type: "start" and + ( + process.code_signature.subject_name : ( + "Action1 Corporation" or + "Aeroadmin LLC" or + "AeroAdmin LLC" or + "AmidaWare LLC" or + "Ammyy LLC" or + "AnyDesk Software GmbH" or + "AOMEI International Network Limited" or + "Atera Networks Ltd" or + "AWERAY PTE. LTD." or + "BeamYourScreen GmbH" or + "Bomgar Corporation" or + "BreakingSecurity.net" or + "ConnectWise, Inc." or + "ConnectWise, LLC" or + "Connectwise, LLC" or + "Devolutions Inc" or + "Devolutions inc." or + "DOMOTZ INC." or + "DUC FABULOUS CO.,LTD" or + "DWSNET OÜ" or + "DWSNET srl" or + "Electronic Team, Inc." or + "Famatech Corp." or + "FleetDeck Inc" or + "GlavSoft LLC" or + "GlavSoft LLC." or + "GoTo Technologies USA, LLC" or + "Hefei Pingbo Network Technology Co. Ltd" or + "IDrive, Inc." or + "Impero Solutions Limited" or + "IMPERO SOLUTIONS LIMITED" or + "Instant Housecall" or + "ISL Online Ltd." or + "JumpCloud Inc" or + "Level Software, Inc." or + "LogMeIn, Inc." or + "LUNIXAR SAS DE CV" or + "MMSOFT Design Ltd." or + "Monitoring Client" or + "MSPBytes Corp" or + "MSPBytes, Corp." or + "N-ABLE TECHNOLOGIES LTD" or + "Nanosystems S.r.l." or + "NetSupport Ltd" or + "NetSupport Ltd." or + "NETSUPPORT LTD." or + "NinjaOne LLC" or + "NinjaRMM, LLC" or + "Open Source Developer, Huabing Zhou" or + "Parallels International GmbH" or + "philandro Software GmbH" or + "Pro Softnet Corporation" or + "PURSLANE" or + "RealVNC" or + "RealVNC Limited" or + "REMOTE UTILITIES PTE. LTD." or + "Remote Utilities LLC" or + "Rocket Software, Inc." or + "Rsupport Co., Ltd." or + "SAFIB" or + "ScreenConnect Client" or + "Servably, Inc." or + "Servably Inc." or + "ShowMyPC INC" or + "SimpleHelp Ltd" or + "Splashtop Inc." or + "Superops Inc." or + "Tailscale Inc." or + "TeamViewer" or + "TeamViewer GmbH" or + "TeamViewer Germany GmbH" or + "Techinline Limited" or + "uvnc bvba" or + "Yakhnovets Denis Aleksandrovich IP" or + "Zhou Huabing" or + "ZOHO Corporation Private Limited" + ) or + + process.name.caseless : ( + AA_v*.exe or + "AcronisCyberProtectConnectAgent.exe" or + "AeroAdmin.exe" or + "AgentMon.exe" or + "AnyDesk.exe" or + "apc_Admin.exe" or + "apc_host.exe" or + "AteraAgent.exe" or + aweray_remote*.exe or + "AweSun.exe" or + "B4-Service.exe" or + "BASupSrvc.exe" or + "bomgar-scc.exe" or + "CagService.exe" or + "CloudRaCmd.exe" or + "CloudRaSd.exe" or + "CloudRaService.exe" or + ConnectWiseControl*.exe or + "connectwisecontrol.client.exe" or + "domotzagent.exe" or + "domotz-windows-x64-10.exe" or + "dwagsvc.exe" or + "DWRCC.exe" or + "dwrcs.exe" or + "dwrcst.exe" or + fleetdeck_commander*.exe or + "g2aservice.exe" or + "getscreen.exe" or + "GoToAssistService.exe" or + "GoToResolveProcessChecker.exe" or + "GoToResolveRemoteControl.exe" or + "GoToResolveService.exe" or + "GoToResolveTerminal.exe" or + "GoToResolveUnattended.exe" or + "gotohttp.exe" or + "helpwire.exe" or + "ImmyAgent.exe" or + "ImmyBot.Agent.Ephemeral.exe" or + "ImmyUpdater.exe" or + "ImperoClientSVC.exe" or + "ImperoServerSVC.exe" or + "ISLLight.exe" or + "ISLLightClient.exe" or + "jumpcloud-agent.exe" or + "komari.exe" or + "komari-agent.exe" or + "level.exe" or + "lmi_rescue.exe" or + "lmi_rescue_srv.exe" or + "LMIIgnition.exe" or + "LogMeIn.exe" or + "ltsvc.exe" or + "ltsvcmon.exe" or + "lttray.exe" or + "Lunixar.exe" or + "LunixarRemote.exe" or + "LunixarUpdater.exe" or + "LvAgent.exe" or + "ManageEngine_Remote_Access_Plus.exe" or + "MeshAgent.exe" or + "Mikogo-Service.exe" or + "nezha-agent.exe" or + "NinjaRMMAgent.exe" or + "NinjaRMMAgentPatcher.exe" or + "ninjarmm-cli.exe" or + "parsec.exe" or + "PService.exe" or + "quickassist.exe" or + "r_server.exe" or + "radmin.exe" or + "radmin3.exe" or + "rcengmgru.exe" or + "RCClient.exe" or + "rcmgrsvc.exe" or + "RCService.exe" or + "Remote Support.exe" or + "RemoteDesktopManager.exe" or + "Remotely_Agent.exe" or + "Remotely_Desktop.exe" or + "RemotePC.exe" or + "RemotePCDesktop.exe" or + "RemotePCService.exe" or + "remoteview.exe" or + "rfusclient.exe" or + "RMM.Agent.exe" or + "ROMServer.exe" or + "ROMViewer.exe" or + "RPCSuite.exe" or + "rserver3.exe" or + "rustdesk.exe" or + "rutserv.exe" or + "rutview.exe" or + "rvagent.exe" or + "rvagtray.exe" or + "saazapsc.exe" or + ScreenConnect*.exe or + "ScreenConnect.ClientService.exe" or + "session_win.exe" or + "simplegatewayservice.exe" or + "simplehelpcustomer.exe" or + "smpcview.exe" or + "spclink.exe" or + "Splashtop-streamer.exe" or + "SplashtopSOS.exe" or + "spsrv.exe" or + "sragent.exe" or + "SRService.exe" or + "srmanager.exe" or + "srserver.exe" or + "strwinclt.exe" or + "Supremo.exe" or + "SupremoService.exe" or + "Syncro.App.Runner.exe" or + "Syncro.Installer.exe" or + "Syncro.Overmind.Service.exe" or + "Syncro.Service.exe" or + "SyncroLive.Agent.exe" or + "SyncroLive.Agent.Runner.exe" or + "SyncroLive.Service.exe" or + "tacticalrmm.exe" or + "tailscale.exe" or + "tailscaled.exe" or + "teamviewer.exe" or + "teamviewer_desktop.exe" or + "teamviewer_service.exe" or + "TiAgent.exe" or + "TiClientCore.exe" or + "ToDesk_Service.exe" or + "ToolsIQ.exe" or + "TSClient.exe" or + "tvn.exe" or + "tvnserver.exe" or + "tvnviewer.exe" or + "twingate.exe" or + UltraVNC*.exe or + UltraViewer*.exe or + "Velociraptor.exe" or + "vncserver.exe" or + "vncviewer.exe" or + "winvnc.exe" or + "winwvc.exe" or + "ZA_Access.exe" or + "za_connect.exe" or + "Zaservice.exe" or + "ZMAgent.exe" or + "ZohoMeeting.exe" or + "zohotray.exe" or + "ZohoURS.exe" or + "ZohoURSService.exe" + ) + ) and + not (process.pe.original_file_name : ("G2M.exe" or "Updater.exe" or "powershell.exe") and process.code_signature.subject_name : "LogMeIn, Inc.") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Remote Access Tools +** ID: T1219 +** Reference URL: https://attack.mitre.org/techniques/T1219/ +* Sub-technique: +** Name: Remote Desktop Software +** ID: T1219.002 +** Reference URL: https://attack.mitre.org/techniques/T1219/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-genai-cli-started-with-unsafe-permission-bypass.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-genai-cli-started-with-unsafe-permission-bypass.asciidoc new file mode 100644 index 0000000000..98a70fdd2d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-genai-cli-started-with-unsafe-permission-bypass.asciidoc @@ -0,0 +1,191 @@ +[[prebuilt-rule-8-19-27-genai-cli-started-with-unsafe-permission-bypass]] +=== GenAI CLI Started with Unsafe Permission Bypass + +Identifies GenAI agent CLIs started with permission-bypass or auto-approval flags that disable human-in-the-loop guardrails. These modes are intended for isolated sandboxes but are frequently misused on internet-connected developer workstations, allowing prompt injection, compromised dependencies, or malicious skills to execute commands, modify files, or reach sensitive paths without confirmation. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://code.claude.com/docs/en/permission-modes +* https://developers.openai.com/codex/cli/reference +* https://developers.openai.com/codex/agent-approvals-security +* https://google-gemini.github.io/gemini-cli/docs/get-started/configuration.html +* https://specterops.io/blog/2025/11/21/an-evening-with-claude-code/ + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* OS: macOS +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Domain: LLM + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GenAI CLI Started with Unsafe Permission Bypass* + + +GenAI coding agents normally prompt before running shell commands or editing files. Vendor-supplied bypass flags remove +those controls entirely or auto-approve all tool calls. On a networked host this materially increases blast radius from +prompt injection, poisoned MCP servers, malicious project configs, and autonomous agent workflows. + + +*Possible investigation steps* + + +- Identify which GenAI tool and bypass flag were used from `process.command_line` and `process.executable`. +- Determine whether the session was intentional (CI/CD, isolated lab VM) or an interactive developer workstation. +- Review child processes spawned after startup for credential access, network exfiltration, or persistence. +- Check for recent GenAI config changes (MCP servers, skills, `.claude/settings.json`, `~/.codex/config.toml`). +- Correlate with other GenAI-related alerts on the same host and user. + + +*False positive analysis* + + +- Deliberate use in approved sandbox/CI images with no outbound network access. +- Internal automation scripts that wrap GenAI CLIs with bypass flags; scope exceptions by host or user group. +- Each matching process start produces one alert; habitual bypass use in CI or developer workflows may need host or user exceptions. + + +*Response and remediation* + + +- Remove bypass flags from scripts, shell profiles, and CI job definitions; use default or plan-only permission modes. +- Rotate API keys and cloud credentials accessible to the user account that ran the agent. +- Audit GenAI tool configs and MCP servers loaded during the session. +- Restrict GenAI agent usage policies to disallow permission bypass on production endpoints. + + +==== Rule query + + +[source, js] +---------------------------------- +process where event.type == "start" and event.action in ("exec", "start") and +( + ( + process.args in ( + "--dangerously-skip-permissions", + "--allow-dangerously-skip-permissions", + "--permission-mode=bypassPermissions" + ) or + (process.args == "--permission-mode" and process.args == "bypassPermissions") + ) and + ( + process.name in ("claude", "claude.exe") or + process.executable : ( + "*/.local/share/claude/versions/*", + "*/.claude/downloads/*", + "*Caskroom/claude-code/*", + "*\\Claude\\versions\\*" + ) or + (process.name in ("node", "node.exe") and process.args : "*@anthropic-ai/claude-code*") + ) +) or +( + ( + process.args in ("--dangerously-bypass-approvals-and-sandbox", "--full-auto", "--yolo") or + process.command_line : ( + "* -s danger-full-access*", + "*--sandbox danger-full-access*", + "*--sandbox=danger-full-access*", + "*--ask-for-approval never*", + "*--ask-for-approval=never*" + ) + ) and + ( + process.name in ( + "codex", "codex.exe", "codex-exec", + "codex-aarch64-apple-darwin", "codex-x86_64-apple-darwin", + "codex-linux-arm64", "codex-linux-x64" + ) or + (process.name in ("node", "node.exe") and process.args : ("*@openai/codex*", "*/codex", "*\\codex*")) + ) +) or +( + ( + process.args in ("--yolo", "-y") or + (process.args == "--approval-mode" and process.args == "yolo") or + process.args == "--approval-mode=yolo" + ) and + ( + process.name in ("gemini", "gemini-cli", "gemini.exe", "gemini-cli.exe") or + (process.name in ("node", "node.exe") and process.args : ("*@google/gemini-cli*", "*/gemini", "*\\gemini*")) + ) +) or +( + ( + process.args in ( + "--yolo", + "--autopilot", + "--allow-all", + "--allow-all-tools", + "--allow-all-paths", + "--allow-all-urls" + ) + ) and + ( + process.name in ("copilot", "copilot.exe") or + (process.name in ("node", "node.exe") and process.args : ("*@github/copilot*", "*/copilot", "*\\copilot*")) + ) +) or +( + process.args == "--dangerously-skip-permissions" and + ( + process.name in ("opencode", "opencode.exe", ".opencode") or + process.executable : ("*opencode-ai*", "*\\.opencode*") or + (process.name in ("node", "node.exe") and process.args : ("*opencode-ai*", "*/opencode", "*\\opencode*")) + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-genai-process-accessing-sensitive-files.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-genai-process-accessing-sensitive-files.asciidoc new file mode 100644 index 0000000000..b426328d47 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-genai-process-accessing-sensitive-files.asciidoc @@ -0,0 +1,205 @@ +[[prebuilt-rule-8-19-27-genai-process-accessing-sensitive-files]] +=== GenAI Process Accessing Sensitive Files + +Detects when GenAI tools access sensitive files such as cloud credentials, SSH keys, browser password databases, or shell configurations. Attackers leverage GenAI agents to systematically locate and exfiltrate credentials, API keys, and tokens. Access to credential stores (.aws/credentials, .ssh/id_*) suggests harvesting, while writes to shell configs (.bashrc, .zshrc) indicate persistence attempts. Note: On linux only creation events are available. Access events are not yet implemented. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://atlas.mitre.org/techniques/AML.T0085 +* https://atlas.mitre.org/techniques/AML.T0085.001 +* https://atlas.mitre.org/techniques/AML.T0055 +* https://glama.ai/blog/2025-11-11-the-lethal-trifecta-securing-model-context-protocol-against-data-flow-attacks +* https://www.elastic.co/security-labs/elastic-advances-llm-security +* https://specterops.io/blog/2025/11/21/an-evening-with-claude-code + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* OS: macOS +* OS: Windows +* Use Case: Threat Detection +* Tactic: Collection +* Tactic: Credential Access +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Domain: LLM +* Mitre Atlas: T0085 +* Mitre Atlas: T0085.001 +* Mitre Atlas: T0055 + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GenAI Process Accessing Sensitive Files* + + +This rule detects GenAI tools accessing credential files, SSH keys, browser data, or shell configurations. While GenAI tools legitimately access project files, access to sensitive credential stores is unusual and warrants investigation. + + +*Possible investigation steps* + + +- Review the GenAI process that triggered the alert to identify which tool is being used and verify if it's an expected/authorized tool. +- Investigate the user account associated with the GenAI process to determine if this activity is expected for that user. +- Review the types of sensitive files being accessed (credentials, keys, browser data, etc.) to assess the potential impact of credential harvesting or data exfiltration. +- Check for other alerts or suspicious activity on the same host around the same time, particularly network exfiltration events. +- Verify if the GenAI tool or extension is from a trusted source and if it's authorized for use in your environment. +- Determine if the GenAI process accessed multiple sensitive directories in sequence, an indication of credential harvesting. +- Check if the GenAI tool recently created or accessed AI agent config files, which may contain instructions enabling autonomous file scanning. +- Review whether the access was preceded by an MCP server, LangChain agent, or background automation. + + +*False positive analysis* + + +- Automated security scanning or auditing tools that leverage GenAI may access sensitive files as part of their normal operation. +- Development workflows that use GenAI tools for code analysis may occasionally access credential files. + + +*Response and remediation* + + +- Immediately review the GenAI process that accessed the documents to determine if it's compromised or malicious. +- Review, rotate, and revoke any API keys, tokens, or credentials that may have been exposed or used by the GenAI tool. +- Investigate the document access patterns to determine the scope of potential data exfiltration. +- Update security policies to restrict or monitor GenAI tool usage in the environment, especially for access to sensitive files. + + +==== Rule query + + +[source, js] +---------------------------------- +file where event.action in ("open", "creation", "modification") and event.outcome == "success" and + + // GenAI process + ( + process.name in~ ( + "ollama.exe", "ollama", + "textgen.exe", "textgen", "text-generation-webui.exe", "oobabooga.exe", + "lmstudio.exe", "lmstudio", "LM Studio", + "claude.exe", "claude", + "cursor.exe", "cursor", + "copilot.exe", "copilot", + "codex.exe", "codex", + "jan.exe", "jan", + "gpt4all.exe", "gpt4all", + "gemini-cli.exe", "gemini-cli", "gemini.exe", + "genaiscript.exe", "genaiscript", + "grok.exe", "grok", + "qwen.exe", "qwen", + "koboldcpp.exe", "koboldcpp", + "llama-server", "llama-cli", + "windsurf.exe", "windsurf", + "zed.exe", "zed", + "opencode.exe", "opencode", + "goose.exe", "goose" + ) + ) and + + // Sensitive file paths + ( + // Persistence via Shell configs + file.name in (".bashrc", ".bash_profile", ".zshrc", ".zshenv", ".zprofile", ".profile", ".bash_logout") or + + // Credentials In Files + file.name like~ + ("key?.db", + "logins.json", + "Login Data", + "Local State", + "signons.sqlite", + "Cookies", + "cookies.sqlite", + "Cookies.binarycookies", + "login.keychain-db", + "System.keychain", + "credentials.db", + "credentials", + "access_tokens.db", + "accessTokens.json", + "azureProfile.json", + "RDCMan.settings", + "known_hosts", + "KeePass.config.xml", + "Unattended.xml") + ) and not ( + host.os.type == "windows" and + file.name like~ "Local State" and + file.path : ( + "?:\\Users\\*\\AppData\\Roaming\\*\\Local State", + "?:\\Users\\*\\AppData\\Local\\Packages\\*\\LocalCache\\Roaming\\*\\Local State" + ) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Credentials In Files +** ID: T1552.001 +** Reference URL: https://attack.mitre.org/techniques/T1552/001/ +* Technique: +** Name: Credentials from Password Stores +** ID: T1555 +** Reference URL: https://attack.mitre.org/techniques/T1555/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Local System +** ID: T1005 +** Reference URL: https://attack.mitre.org/techniques/T1005/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Initialization Scripts +** ID: T1037 +** Reference URL: https://attack.mitre.org/techniques/T1037/ +* Sub-technique: +** Name: RC Scripts +** ID: T1037.004 +** Reference URL: https://attack.mitre.org/techniques/T1037/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-gke-admission-webhook-created-or-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-gke-admission-webhook-created-or-modified.asciidoc new file mode 100644 index 0000000000..ad8dc590d0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-gke-admission-webhook-created-or-modified.asciidoc @@ -0,0 +1,116 @@ +[[prebuilt-rule-8-19-27-gke-admission-webhook-created-or-modified]] +=== GKE Admission Webhook Created or Modified + +Detects creation or modification of GKE mutating or validating admission webhook configurations by non-system identities. Malicious webhooks can inject workloads, block security tooling, or intercept API traffic for persistence and defense evasion. + +*Rule type*: query + +*Rule indices*: + +* logs-gcp.audit-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/ + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Defense Evasion +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Admission Webhook Created or Modified* + + +Review webhook name, actor, and clientConfig destination in `gcp.audit.request`. + + +*Investigation steps* + + +- Confirm `user.email`, `event.action`, and webhook resource name. +- Inspect webhook URL or in-cluster service target for external endpoints. +- Hunt for pod mutations or blocked security deployments after the change. + + +*False positives* + + +- Approved controller upgrades during change windows. + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and event.outcome:success and event.action:( + "io.k8s.admissionregistration.v1.mutatingwebhookconfigurations.create" or + "io.k8s.admissionregistration.v1.mutatingwebhookconfigurations.update" or + "io.k8s.admissionregistration.v1.mutatingwebhookconfigurations.patch" or + "io.k8s.admissionregistration.v1.validatingwebhookconfigurations.create" or + "io.k8s.admissionregistration.v1.validatingwebhookconfigurations.update" or + "io.k8s.admissionregistration.v1.validatingwebhookconfigurations.patch" +) and not user.email:( + "system:kube-controller-manager" or "system:kube-scheduler" or system\:serviceaccount\:kube-system\:* or + system\:serviceaccount\:gke-managed-system\:* or system\:serviceaccount\:cert-manager\:* or + system\:serviceaccount\:gatekeeper-system\:* or system\:serviceaccount\:kyverno\:* or "system:addon-manager" or + *-operator or *-cainjector or *-webhook or *argocd* or "system:gke-common-webhooks" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-gke-api-request-failure-burst-by-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-gke-api-request-failure-burst-by-user.asciidoc new file mode 100644 index 0000000000..3f9afeb7a4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-gke-api-request-failure-burst-by-user.asciidoc @@ -0,0 +1,110 @@ +[[prebuilt-rule-8-19-27-gke-api-request-failure-burst-by-user]] +=== GKE API Request Failure Burst by User + +Detects bursts of failed GKE API requests from a single user identity within a five-minute window. Repeated authorization failures across multiple actions can indicate credential stuffing, RBAC probing, or reconnaissance with stolen tokens. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-11m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cloud.google.com/kubernetes-engine/docs/how-to/audit-logging +* https://attack.mitre.org/techniques/T1613/ + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Discovery +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE API Request Failure Burst by User* + + +The rule aggregates failed Kubernetes API calls per `user.email`, source IP, and user agent in five-minute buckets and +alerts when failures reach ten or more. + + +*Investigation steps* + + +- Review `Esql.actions` and `Esql.resources` for targeted API operations. +- Validate whether the identity should exist and whether the source IP is expected. +- Hunt for later successful calls indicating privilege escalation. + + +*False positives* + + +- Misconfigured automation or CI jobs with stale credentials may generate bursts; exclude known service accounts. + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +from logs-gcp.audit-* metadata _id, _index, _version +| eval Esql.time_interval = date_trunc(5 minutes, @timestamp) +| where data_stream.dataset == "gcp.audit" + and service.name == "k8s.io" + and event.outcome == "failure" + and event.type != "allowed" + and user.email is not null + and not to_string(user.email) rlike "(system:serviceaccount:|system:gke-spiffe-controller|system:kube-scheduler|system:node:).*" +| stats + Esql.unique_actions = count_distinct(event.action), + Esql.failures_count = count(*), + Esql.actions = values(event.action), + Esql.resources = values(orchestrator.resource.name) + by user.email, source.ip, user_agent.original, data_stream.namespace, Esql.time_interval +| where Esql.failures_count >= 10 +| keep Esql.*, user.email, source.ip, user_agent.original, data_stream.namespace + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Container and Resource Discovery +** ID: T1613 +** Reference URL: https://attack.mitre.org/techniques/T1613/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-gke-cluster-admin-role-binding-created-or-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-gke-cluster-admin-role-binding-created-or-modified.asciidoc new file mode 100644 index 0000000000..57635b092b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-gke-cluster-admin-role-binding-created-or-modified.asciidoc @@ -0,0 +1,118 @@ +[[prebuilt-rule-8-19-27-gke-cluster-admin-role-binding-created-or-modified]] +=== GKE Cluster-Admin Role Binding Created or Modified + +Detects creation or modification of a GKE ClusterRoleBinding that grants the cluster-admin ClusterRole, providing unrestricted cluster access and enabling rapid privilege escalation or persistence. + +*Rule type*: query + +*Rule indices*: + +* logs-gcp.audit-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cloud.google.com/kubernetes-engine/docs/how-to/role-based-access-control +* https://heilancoos.github.io/research/2025/12/16/kubernetes.html#overly-permissive-role-based-access-control + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Privilege Escalation +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Cluster-Admin Role Binding Created or Modified* + + +Identify who created or changed the binding and which subject received cluster-admin. + + +*Investigation steps* + + +- Review `user.email`, `source.ip`, and `gcp.audit.request` for the bound subject. +- Hunt for secret reads, privileged pod creation, or webhook changes from the same actor or new subject. + + +*False positives* + + +- Bootstrap, recovery, or GitOps workflows may recreate cluster-admin bindings during approved changes. + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and service.name:"k8s.io" and event.outcome:success and +event.action:( + "io.k8s.authorization.rbac.v1.clusterrolebindings.create" or + "io.k8s.authorization.rbac.v1.clusterrolebindings.patch" or + "io.k8s.authorization.rbac.v1.clusterrolebindings.update" +) and gcp.audit.request.kind:"ClusterRoleBinding" and +gcp.audit.resource_name:"rbac.authorization.k8s.io/v1/clusterrolebindings/cluster-admin" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-gke-container-created-with-excessive-linux-capabilities.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-gke-container-created-with-excessive-linux-capabilities.asciidoc new file mode 100644 index 0000000000..b0befed704 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-gke-container-created-with-excessive-linux-capabilities.asciidoc @@ -0,0 +1,109 @@ +[[prebuilt-rule-8-19-27-gke-container-created-with-excessive-linux-capabilities]] +=== GKE Container Created with Excessive Linux Capabilities + +Detects GKE pod creation with dangerous Linux capabilities that are commonly abused in container escape techniques. Standalone pods are included; controller-owned ReplicaSet, DaemonSet, and StatefulSet workloads are excluded. + +*Rule type*: query + +*Rule indices*: + +* logs-gcp.audit-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-capabilities-for-a-container +* https://0xn3va.gitbook.io/cheat-sheets/container/escaping/excessive-capabilities + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Execution +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Container Created with Excessive Linux Capabilities* + + +Capabilities such as SYS_ADMIN, NET_ADMIN, and BPF can enable host escape. Review `gcp.audit.request.spec.containers` +and the creating identity. + + +*Investigation steps* + + +- Confirm which capability was added and whether the image requires it. +- Review `user.email`, namespace, and follow-on API activity from the same actor. + + +*False positives* + + +- Known DaemonSet or operator images may need capabilities; exclude after validation. + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and event.action:"io.k8s.core.v1.pods.create" and event.outcome:success and +gcp.audit.request.spec.containers.securityContext.capabilities.add:( + "BPF" or "DAC_READ_SEARCH" or "NET_ADMIN" or "SYS_ADMIN" or "SYS_BOOT" or "SYS_MODULE" or "SYS_PTRACE" or "SYS_RAWIO" or + "SYSLOG" +) and not gcp.audit.request.metadata.ownerReferences.kind:("ReplicaSet" or "DaemonSet" or "StatefulSet") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Escape to Host +** ID: T1611 +** Reference URL: https://attack.mitre.org/techniques/T1611/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Deploy Container +** ID: T1610 +** Reference URL: https://attack.mitre.org/techniques/T1610/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-gke-pod-created-with-a-sensitive-hostpath-volume.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-gke-pod-created-with-a-sensitive-hostpath-volume.asciidoc new file mode 100644 index 0000000000..2aab74ab45 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-gke-pod-created-with-a-sensitive-hostpath-volume.asciidoc @@ -0,0 +1,111 @@ +[[prebuilt-rule-8-19-27-gke-pod-created-with-a-sensitive-hostpath-volume]] +=== GKE Pod Created with a Sensitive hostPath Volume + +Detects GKE pod create, update, or patch events that mount sensitive hostPath volumes such as the root filesystem, kubelet paths, or container runtime sockets. This can enable container escape and credential theft. System identities and controller-owned workloads are excluded. + +*Rule type*: query + +*Rule indices*: + +* logs-gcp.audit-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://kubernetes.io/docs/concepts/storage/volumes/#hostpath +* https://blog.appsecco.com/kubernetes-namespace-breakout-using-insecure-host-path-volume-part-1-b382f2a6e216 + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Execution +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Pod Created with a Sensitive hostPath Volume* + + +Review `gcp.audit.request.spec.volumes.hostPath.path` and whether the mount is required for the workload. + + +*Investigation steps* + + +- Confirm the hostPath and container images in the audit request. +- Review `user.email`, namespace, and follow-on secret or exec activity. + + +*False positives* + + +- Platform DaemonSets mounting /proc or kubelet paths; validate against known agents. + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and event.outcome:success and +event.action:("io.k8s.core.v1.pods.create" or "io.k8s.core.v1.pods.update" or "io.k8s.core.v1.pods.patch") and +gcp.audit.request.spec.volumes.hostPath.path:( + "/" or "/proc" or "/root" or "/var" or "/var/run" or "/var/run/docker.sock" or "/var/run/crio/crio.sock" or + "/var/run/cri-dockerd.sock" or "/var/lib/kubelet" or "/var/lib/kubelet/pki" or "/var/lib/docker/overlay2" or "/etc" or + "/etc/kubernetes" or "/etc/kubernetes/manifests" or "/etc/kubernetes/pki" or "/home/admin" +) and not user.email:system\:* and +not gcp.audit.request.metadata.ownerReferences.kind:("ReplicaSet" or "DaemonSet" or "StatefulSet") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Escape to Host +** ID: T1611 +** Reference URL: https://attack.mitre.org/techniques/T1611/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Deploy Container +** ID: T1610 +** Reference URL: https://attack.mitre.org/techniques/T1610/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-gke-pod-created-with-hostipc.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-gke-pod-created-with-hostipc.asciidoc new file mode 100644 index 0000000000..d64950a7c0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-gke-pod-created-with-hostipc.asciidoc @@ -0,0 +1,107 @@ +[[prebuilt-rule-8-19-27-gke-pod-created-with-hostipc]] +=== GKE Pod Created With HostIPC + +Detects GKE pod create, update, or patch events that enable host IPC namespace sharing. This exposes host inter-process communication mechanisms and can support privilege escalation. Controller-owned workloads are excluded. + +*Rule type*: query + +*Rule indices*: + +* logs-gcp.audit-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://kubernetes.io/docs/concepts/security/pod-security-standards/ +* https://bishopfox.com/blog/kubernetes-pod-privilege-escalation + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Execution +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Pod Created With HostIPC* + + +Host IPC lets a pod interact with host IPC facilities. Review the pod spec, actor, and whether the change was expected. + + +*Investigation steps* + + +- Confirm `gcp.audit.request.spec.hostIPC` and targeted namespace or pod. +- Review `user.email` and correlate with other risky pod modifications. + + +*False positives* + + +- Break-glass debugging on nodes; allowlist known admin identities. + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and event.outcome:success and +event.action:("io.k8s.core.v1.pods.create" or "io.k8s.core.v1.pods.update" or "io.k8s.core.v1.pods.patch") and +gcp.audit.request.spec.hostIPC:true and +not gcp.audit.request.metadata.ownerReferences.kind:("ReplicaSet" or "DaemonSet" or "StatefulSet") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Escape to Host +** ID: T1611 +** Reference URL: https://attack.mitre.org/techniques/T1611/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Deploy Container +** ID: T1610 +** Reference URL: https://attack.mitre.org/techniques/T1610/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-gke-pod-created-with-hostnetwork.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-gke-pod-created-with-hostnetwork.asciidoc new file mode 100644 index 0000000000..d192cbc180 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-gke-pod-created-with-hostnetwork.asciidoc @@ -0,0 +1,108 @@ +[[prebuilt-rule-8-19-27-gke-pod-created-with-hostnetwork]] +=== GKE Pod Created With HostNetwork + +Detects GKE pod create, update, or patch events that enable host network namespace sharing. HostNetwork grants access to the node network stack and can bypass namespace network policies. System identities and controller-owned workloads are excluded. + +*Rule type*: query + +*Rule indices*: + +* logs-gcp.audit-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://kubernetes.io/docs/concepts/security/pod-security-standards/ +* https://bishopfox.com/blog/kubernetes-pod-privilege-escalation + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Execution +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Pod Created With HostNetwork* + + +HostNetwork pods can observe or interact with node-local services. Validate the actor and workload purpose. + + +*Investigation steps* + + +- Review `user.email`, pod name, namespace, and container images in `gcp.audit.request`. +- Hunt for secret access or exec from the same identity after the change. + + +*False positives* + + +- Platform DaemonSets often use hostNetwork; controller ownerReferences exclusion reduces noise. + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and +event.action:("io.k8s.core.v1.pods.create" or "io.k8s.core.v1.pods.update" or "io.k8s.core.v1.pods.patch") and +gcp.audit.request.spec.hostNetwork:true and +not gcp.audit.request.metadata.ownerReferences.kind:("ReplicaSet" or "DaemonSet" or "StatefulSet") and +not user.email:system\:* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Escape to Host +** ID: T1611 +** Reference URL: https://attack.mitre.org/techniques/T1611/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Deploy Container +** ID: T1610 +** Reference URL: https://attack.mitre.org/techniques/T1610/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-gke-pod-created-with-hostpid.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-gke-pod-created-with-hostpid.asciidoc new file mode 100644 index 0000000000..a550ea3067 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-gke-pod-created-with-hostpid.asciidoc @@ -0,0 +1,107 @@ +[[prebuilt-rule-8-19-27-gke-pod-created-with-hostpid]] +=== GKE Pod Created With HostPID + +Detects GKE pod create, update, or patch events that enable host PID namespace sharing. HostPID exposes host processes and can support privilege escalation, especially with ptrace or privileged containers. System identities and controller-owned workloads are excluded. + +*Rule type*: query + +*Rule indices*: + +* logs-gcp.audit-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://kubernetes.io/docs/concepts/security/pod-security-standards/ +* https://bishopfox.com/blog/kubernetes-pod-privilege-escalation + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Execution +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Pod Created With HostPID* + + +HostPID visibility into host processes is high risk. Confirm whether the pod spec change was authorized. + + +*Investigation steps* + + +- Review actor (`user.email`), target pod, and images in the audit request. +- Correlate with exec, secret access, or RBAC changes from the same identity. + + +*False positives* + + +- Break-glass troubleshooting; tune by user or namespace. + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and +event.action:("io.k8s.core.v1.pods.create" or "io.k8s.core.v1.pods.update" or "io.k8s.core.v1.pods.patch") and +gcp.audit.request.spec.hostPID:true and not user.email:system\:* and +not gcp.audit.request.metadata.ownerReferences.kind:("ReplicaSet" or "DaemonSet" or "StatefulSet") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Escape to Host +** ID: T1611 +** Reference URL: https://attack.mitre.org/techniques/T1611/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Deploy Container +** ID: T1610 +** Reference URL: https://attack.mitre.org/techniques/T1610/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-gke-privileged-pod-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-gke-privileged-pod-created.asciidoc new file mode 100644 index 0000000000..654400800d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-gke-privileged-pod-created.asciidoc @@ -0,0 +1,108 @@ +[[prebuilt-rule-8-19-27-gke-privileged-pod-created]] +=== GKE Privileged Pod Created + +Detects successful GKE audit events where a pod is created with allowPrivilegeEscalation enabled. This weakens container isolation and can help an attacker escalate toward host access. Standalone pods are included; workloads owned by ReplicaSet, DaemonSet, or StatefulSet controllers are excluded. + +*Rule type*: query + +*Rule indices*: + +* logs-gcp.audit-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cloud.google.com/kubernetes-engine/docs/how-to/audit-logging +* https://kubernetes.io/docs/tasks/configure-pod-container/security-context/ + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Execution +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Privileged Pod Created* + + +Review `user.email`, `orchestrator.resource.name`, `orchestrator.namespace`, and the pod spec in `gcp.audit.request`. +Confirm whether allowPrivilegeEscalation is required for the workload. + + +*Investigation steps* + + +- Identify the actor and source (`user.email`, `source.ip`, `user_agent.original`). +- Inspect container images and securityContext in the audit request payload. +- Correlate with RBAC changes, secret access, or exec activity from the same identity. + + +*False positives* + + +- One-off admin debugging pods; tune by user or namespace when documented. + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and event.action:"io.k8s.core.v1.pods.create" and event.outcome:success and +gcp.audit.request.spec.containers.securityContext.allowPrivilegeEscalation:true and +not gcp.audit.request.metadata.ownerReferences.kind:("ReplicaSet" or "DaemonSet" or "StatefulSet") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Escape to Host +** ID: T1611 +** Reference URL: https://attack.mitre.org/techniques/T1611/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Deploy Container +** ID: T1610 +** Reference URL: https://attack.mitre.org/techniques/T1610/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-gke-secret-get-or-list-with-suspicious-user-agent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-gke-secret-get-or-list-with-suspicious-user-agent.asciidoc new file mode 100644 index 0000000000..ae37a1d999 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-gke-secret-get-or-list-with-suspicious-user-agent.asciidoc @@ -0,0 +1,102 @@ +[[prebuilt-rule-8-19-27-gke-secret-get-or-list-with-suspicious-user-agent]] +=== GKE Secret get or list with Suspicious User Agent + +Detects successful GKE secret get or list operations where the user agent matches scripting runtimes, minimal HTTP clients, or offensive-distribution fingerprints rather than typical kubectl or controller traffic. + +*Rule type*: query + +*Rule indices*: + +* logs-gcp.audit-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1552/007/ + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Secret get or list with Suspicious User Agent* + + +Review `user.email`, `user_agent.original`, targeted secret resource, and `source.ip`. + + +*Investigation steps* + + +- Confirm whether the identity should access secrets with this client fingerprint. +- Pivot on source IP for other API bursts, exec, or RBAC changes. + + +*False positives* + + +- Internal automation using generic libraries; exclude stable service accounts after review. + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and service.name:"k8s.io" and event.outcome:success and +event.action:("io.k8s.core.v1.secrets.list" or "io.k8s.core.v1.secrets.get") and user_agent.original:( + curl* or python* or Python* or wget* or Go-http* or perl* or java* or node* or php* or *distrib#kali* or *kali-amd64* or + *kali-arm64* or Bun* or axios* or undici* +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Container API +** ID: T1552.007 +** Reference URL: https://attack.mitre.org/techniques/T1552/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-gke-secrets-list-from-unusual-source-as-organization.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-gke-secrets-list-from-unusual-source-as-organization.asciidoc new file mode 100644 index 0000000000..ef8f848619 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-gke-secrets-list-from-unusual-source-as-organization.asciidoc @@ -0,0 +1,107 @@ +[[prebuilt-rule-8-19-27-gke-secrets-list-from-unusual-source-as-organization]] +=== GKE Secrets List from Unusual Source AS Organization + +Detects the first time a human GKE caller lists secrets cluster-wide or in default or kube-system from a source autonomous system that is not attributed to common cloud provider organizations. This can indicate remote secret enumeration using stolen credentials from an unusual network. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-gcp.audit-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1552/007/ + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Discovery +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Secrets List from Unusual Source AS Organization* + + +New-terms rule on `user.email` and `source.as.number` for cluster-wide or sensitive namespace secret list operations. + + +*Investigation steps* + + +- Confirm `gcp.audit.resource_name` and whether listing was authorized. +- Review `source.ip`, `source.as.organization.name`, and follow-on secret get or exec activity. + + +*False positives* + + +- First-time legitimate admin access from a new office or VPN provider. + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and service.name:"k8s.io" and event.action:io.k8s.core.v1.secrets.list and gcp.audit.resource_name:(core/v1/namespaces/default/secrets or core/v1/namespaces/kube-system/secrets or core/v1/secrets) and user.email:*@* and source.as.organization.name:(* and not ("Google LLC" or "Microsoft Corporation")) and source.as.number:* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Container API +** ID: T1552.007 +** Reference URL: https://attack.mitre.org/techniques/T1552/007/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Container and Resource Discovery +** ID: T1613 +** Reference URL: https://attack.mitre.org/techniques/T1613/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-gke-suspicious-self-subject-review-via-service-account.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-gke-suspicious-self-subject-review-via-service-account.asciidoc new file mode 100644 index 0000000000..adcb2af26a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-gke-suspicious-self-subject-review-via-service-account.asciidoc @@ -0,0 +1,102 @@ +[[prebuilt-rule-8-19-27-gke-suspicious-self-subject-review-via-service-account]] +=== GKE Suspicious Self-Subject Review via Service Account + +Detects GKE service account or node identities invoking self-subject access or rules review APIs. Non-human identities rarely enumerate their own permissions outside known controllers; this can indicate stolen tokens probing effective RBAC. + +*Rule type*: query + +*Rule indices*: + +* logs-gcp.audit-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://kubernetes.io/docs/reference/access-authn-authz/authorization/#checking-api-access + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Discovery +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Suspicious Self-Subject Review via Service Account* + + +Review the calling service account or node identity and subsequent API activity. + + +*Investigation steps* + + +- Confirm `user.email` and `event.action` (selfsubjectaccessreviews or selfsubjectrulesreviews). +- Correlate with denied requests, secret access, or RBAC changes from the same identity. + + +*False positives* + + +- Known observability or workflow controllers; extend exclusions if needed. + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and service.name:k8s.io and event.action:(io.k8s.authorization.v1.selfsubjectaccessreviews.create or io.k8s.authorization.v1.selfsubjectrulesreviews.create) and user.email:((system\:node\:* or system\:serviceaccount\:*) and not ("system:serviceaccount:default:argo-argo-workflows-server" or "system:serviceaccount:default:argo-argo-workflows-workflow-controller" or system\:serviceaccount\:*\:datadog-kube-state-metrics)) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Permission Groups Discovery +** ID: T1069 +** Reference URL: https://attack.mitre.org/techniques/T1069/ +* Sub-technique: +** Name: Cloud Groups +** ID: T1069.003 +** Reference URL: https://attack.mitre.org/techniques/T1069/003/ +* Technique: +** Name: Container and Resource Discovery +** ID: T1613 +** Reference URL: https://attack.mitre.org/techniques/T1613/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-gke-user-exec-into-pod.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-gke-user-exec-into-pod.asciidoc new file mode 100644 index 0000000000..6eb2157ead --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-gke-user-exec-into-pod.asciidoc @@ -0,0 +1,96 @@ +[[prebuilt-rule-8-19-27-gke-user-exec-into-pod]] +=== GKE User Exec into Pod + +Detects the first occurrence of a non-system GKE identity establishing an exec session into a pod. kubectl exec enables interactive command execution inside workloads and is a common post-compromise technique to access secrets and expand access. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-gcp.audit-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://kubernetes.io/docs/tasks/debug/debug-application/get-shell-running-container/ + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE User Exec into Pod* + + +This new-terms rule alerts on the first exec into a given pod by a user identity in the lookback window. + + +*Investigation steps* + + +- Review `user.email`, `orchestrator.resource.name`, `source.ip`, and `user_agent.original`. +- Determine whether the target pod holds sensitive data or cluster credentials. +- Correlate with secret access or RBAC changes from the same identity. + + +*False positives* + + +- Approved admin debugging; exclude stable operator identities after review. + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and event.action:("io.k8s.core.v1.pods.exec.create" or "io.k8s.core.v1.pods.exec.get") and +not user.email:system\:* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Container Administration Command +** ID: T1609 +** Reference URL: https://attack.mitre.org/techniques/T1609/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-icmp-redirect-message-from-internal-host.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-icmp-redirect-message-from-internal-host.asciidoc new file mode 100644 index 0000000000..567562468c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-icmp-redirect-message-from-internal-host.asciidoc @@ -0,0 +1,123 @@ +[[prebuilt-rule-8-19-27-icmp-redirect-message-from-internal-host]] +=== ICMP Redirect Message from Internal Host + +Identifies ICMP Redirect messages (type 5 for IPv4, type 137 for IPv6) sourced from an internal IPv4 or IPv6 address. Legitimate redirects are normally sent only by on-path routers. A workstation or server emitting redirects can indicate route manipulation for adversary-in-the-middle activity. + +*Rule type*: query + +*Rule indices*: + +* logs-network_traffic.icmp-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.rfc-editor.org/rfc/rfc792 +* https://www.rfc-editor.org/rfc/rfc4443 +* https://zimperium.com/blog/doubledirect-zimperium-discovers-full-duplex-icmp-redirect-attacks-in-the-wild + +*Tags*: + +* Domain: Network +* Tactic: Credential Access +* Use Case: Threat Detection +* Use Case: Network Security Monitoring +* Data Source: Network Traffic +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating ICMP Redirect Message from Internal Host* + + +ICMP Redirect instructs a host to send traffic for a destination through a different next hop. On most enterprise +segments, only infrastructure routers should emit redirects; a user workstation or server doing so is a strong +adversary-in-the-middle indicator. + + +*Possible investigation steps* + + +- Identify the redirect source in `source.ip` and locate the asset on the VLAN. Confirm whether it is an authorized + router or gateway. +- Review the redirect target and affected destination in ICMP fields and adjacent flow records to see which routes or + resolvers were being manipulated. +- Check whether affected clients show DNS, gateway, or VPN routing changes around the alert time. +- Correlate with DHCP, ARP, or LLMNR/NBT-NS alerts on the same segment for combined MITM activity. + + +*False positive analysis* + + +- Some legacy network appliances, hypervisor gateways, or misconfigured Linux hosts with IP forwarding enabled may + emit redirects. Maintain exceptions for known router and gateway IPs after validation. +- Lab networks that intentionally test route injection should be scoped out by source subnet. + + +*Response and remediation* + + +- Isolate the emitting host if it is not an authorized router. +- Disable ICMP redirect acceptance on affected clients where policy allows, and block redirect-generating hosts at the + access layer. +- Review segment routing, default gateways, and DHCP options for unauthorized changes. + +==== Setup + + + +*Setup* + + +This rule requires ICMP transaction telemetry from the Elastic network_traffic integration (`network_traffic.icmp` +data stream). Flow-only exporters that do not record ICMP type/code will not satisfy this rule. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:network_traffic.icmp + and (network_traffic.icmp.request.type:(5 or 137) or icmp.request.type:(5 or 137)) + and source.ip:(10.0.0.0/8 or 172.16.0.0/12 or 192.168.0.0/16 or "FC00::/7" or "FE80::/10") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Adversary-in-the-Middle +** ID: T1557 +** Reference URL: https://attack.mitre.org/techniques/T1557/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-icmp-timestamp-or-information-request-from-the-internet.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-icmp-timestamp-or-information-request-from-the-internet.asciidoc new file mode 100644 index 0000000000..fcbf486d5b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-icmp-timestamp-or-information-request-from-the-internet.asciidoc @@ -0,0 +1,164 @@ +[[prebuilt-rule-8-19-27-icmp-timestamp-or-information-request-from-the-internet]] +=== ICMP Timestamp or Information Request from the Internet + +Identifies inbound ICMP Timestamp (type 13) or Information (type 15) requests from external addresses to internal RFC1918 destinations. These message types are rarely used in modern networks and are commonly associated with host and path fingerprinting during reconnaissance. + +*Rule type*: query + +*Rule indices*: + +* logs-network_traffic.icmp-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.rfc-editor.org/rfc/rfc792 +* https://nmap.org/book/host-discovery-techniques.html +* https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml + +*Tags*: + +* Domain: Network +* Tactic: Discovery +* Tactic: Reconnaissance +* Use Case: Network Security Monitoring +* Use Case: Threat Detection +* Data Source: Network Traffic +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating ICMP Timestamp or Information Request from the Internet* + + +ICMP Timestamp and Information requests are legacy diagnostic messages. Inbound use from the Internet toward internal +hosts is uncommon in production networks and often indicates active scanning or OS fingerprinting. + + +*Possible investigation steps* + + +- Review `source.ip` against threat intelligence and prior scan activity on the environment. +- Determine whether the targeted `destination.ip` is an exposed host, VPN concentrator, or mis-NATed internal asset. +- Look for adjacent port scans, SYN sweeps, or exploit attempts from the same source around the alert window. +- Check whether the destination host replied and whether follow-on connections were attempted. + + +*False positive analysis* + + +- Some legacy network monitoring or SLA probes may still use ICMP Timestamp requests. Maintain exceptions for known + monitoring source ranges after validation. +- Shared hosting or multi-tenant environments with overlapping address space may require destination-specific tuning. + + +*Response and remediation* + + +- Block or rate-limit the external source at the perimeter if activity is unauthorized. +- Verify that the targeted internal host is not unintentionally exposed to the Internet. +- Increase monitoring on targeted assets for follow-on exploitation attempts. + +==== Setup + + + +*Setup* + + +This rule requires ICMP transaction telemetry from the Elastic network_traffic integration (`network_traffic.icmp` +data stream). + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:network_traffic.icmp + and (network_traffic.icmp.request.type:(13 or 15) or icmp.request.type:(13 or 15)) + and destination.ip:( + 10.0.0.0/8 or + 172.16.0.0/12 or + 192.168.0.0/16 + ) + and not source.ip:( + 10.0.0.0/8 or + 100.64.0.0/10 or + 127.0.0.0/8 or + 169.254.0.0/16 or + 172.16.0.0/12 or + 192.168.0.0/16 or + 192.0.0.0/24 or + 192.0.0.0/29 or + 192.0.0.8/32 or + 192.0.0.9/32 or + 192.0.0.10/32 or + 192.0.0.170/32 or + 192.0.0.171/32 or + 192.0.2.0/24 or + 192.175.48.0/24 or + 192.31.196.0/24 or + 192.52.193.0/24 or + 192.88.99.0/24 or + 198.18.0.0/15 or + 198.51.100.0/24 or + 203.0.113.0/24 or + 224.0.0.0/4 or + 240.0.0.0/4 or + "::1" or + "FE80::/10" or + "FF00::/8" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Remote System Discovery +** ID: T1018 +** Reference URL: https://attack.mitre.org/techniques/T1018/ +* Tactic: +** Name: Reconnaissance +** ID: TA0043 +** Reference URL: https://attack.mitre.org/tactics/TA0043/ +* Technique: +** Name: Active Scanning +** ID: T1595 +** Reference URL: https://attack.mitre.org/techniques/T1595/ +* Sub-technique: +** Name: Scanning IP Blocks +** ID: T1595.001 +** Reference URL: https://attack.mitre.org/techniques/T1595/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-ipsec-nat-traversal-port-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-ipsec-nat-traversal-port-activity.asciidoc new file mode 100644 index 0000000000..98a46397d7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-ipsec-nat-traversal-port-activity.asciidoc @@ -0,0 +1,159 @@ +[[prebuilt-rule-8-19-27-ipsec-nat-traversal-port-activity]] +=== IPSEC NAT Traversal Port Activity + +This rule detects outbound IPSEC NAT Traversal (NAT-T) tunnels established from an internal host to an external destination. IPSEC is a VPN technology that allows one system to talk to another using encrypted tunnels. NAT Traversal encapsulates IPSEC ESP traffic in UDP and, once a NAT device is detected, both peers float to UDP port 4500 for the tunnel data channel. The rule keys on this NAT-T signature, UDP traffic where both the source and destination port are 4500, from an internal source to an external destination, rather than on any UDP traffic to port 4500. This may be common on your network, but this technique is also used by threat actors to tunnel command and control or exfiltration traffic over the Internet to avoid detection. + +*Rule type*: query + +*Rule indices*: + +* packetbeat-* +* auditbeat-* +* filebeat-* +* logs-network_traffic.* +* logs-panw.* +* logs-pfsense.log-* +* logs-zeek.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Tactic: Command and Control +* Domain: Endpoint +* Use Case: Threat Detection +* Data Source: PAN-OS +* Data Source: Network Traffic +* Data Source: pfSense +* Data Source: Zeek +* Resources: Investigation Guide + +*Version*: 112 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating IPSEC NAT Traversal Port Activity* + + +IPSEC NAT Traversal facilitates secure VPN communication across NAT devices by encapsulating IPSEC packets in UDP, typically using port 4500. While essential for legitimate encrypted traffic, adversaries exploit this to mask malicious activities, bypassing network defenses. The detection rule identifies outbound NAT-T tunnels, UDP traffic where both the source and destination port are 4500, originating from an internal host to an external destination, flagging potential misuse for further investigation. + + +*Possible investigation steps* + + +- Review the source and destination IP addresses associated with the UDP traffic on port 4500 to determine if they are known or expected within your network environment. +- Analyze the volume and frequency of the detected traffic to assess whether it aligns with typical IPSEC NAT Traversal usage or if it appears anomalous. +- Check for any associated network traffic events in the same timeframe that might indicate a pattern of suspicious activity, such as unusual data transfer volumes or connections to known malicious IP addresses. +- Investigate the endpoint or device generating the traffic to verify if it is authorized to use IPSEC NAT Traversal and if it has any history of security incidents or vulnerabilities. +- Correlate the detected activity with any recent changes in network configurations or security policies that might explain the traffic pattern. +- Consult threat intelligence sources to determine if the destination IP address or domain has been associated with known threat actors or command and control infrastructure. + + +*False positive analysis* + + +- Legitimate VPN traffic using IPSEC NAT Traversal can trigger alerts. Regularly review and whitelist known IP addresses or subnets associated with authorized VPN connections to reduce false positives. +- Network devices or services that rely on IPSEC for secure communication may generate expected traffic on port 4500. Identify and document these devices, then create exceptions in the detection rule to prevent unnecessary alerts. +- Automated backup or synchronization services that use IPSEC for secure data transfer might be flagged. Monitor these services and exclude their traffic patterns if they are verified as non-threatening. +- Some enterprise applications may use IPSEC NAT Traversal for secure communication. Conduct an inventory of such applications and adjust the rule to exclude their traffic after confirming their legitimacy. +- Regularly update the list of known safe IP addresses and services to ensure that new legitimate sources of IPSEC NAT Traversal traffic are promptly excluded from triggering alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further potential malicious activity and lateral movement. +- Conduct a thorough analysis of the isolated system to identify any signs of compromise, such as unauthorized access or data exfiltration, focusing on logs and network traffic related to UDP port 4500. +- Block all suspicious IP addresses associated with the detected traffic on port 4500 at the network perimeter to prevent further communication with potential threat actors. +- Review and update firewall and intrusion detection/prevention system (IDS/IPS) rules to ensure they effectively block unauthorized IPSEC NAT Traversal traffic, particularly on UDP port 4500. +- Restore the affected system from a known good backup if any signs of compromise are confirmed, ensuring that all security patches and updates are applied before reconnecting to the network. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring and logging for UDP traffic on port 4500 to detect and respond to any future suspicious activity promptly. + +==== Rule query + + +[source, js] +---------------------------------- +(data_stream.dataset: (network_traffic.flow or zeek.connection) or (event.category: (network or network_traffic))) and + network.transport:udp and source.port:4500 and destination.port:4500 and + source.ip:( + 10.0.0.0/8 or + 172.16.0.0/12 or + 192.168.0.0/16 + ) and + not destination.ip:( + 10.0.0.0/8 or + 127.0.0.0/8 or + 169.254.0.0/16 or + 172.16.0.0/12 or + 192.0.0.0/24 or + 192.0.0.0/29 or + 192.0.0.8/32 or + 192.0.0.9/32 or + 192.0.0.10/32 or + 192.0.0.170/32 or + 192.0.0.171/32 or + 192.0.2.0/24 or + 192.31.196.0/24 or + 192.52.193.0/24 or + 192.168.0.0/16 or + 192.88.99.0/24 or + 224.0.0.0/4 or + 100.64.0.0/10 or + 192.175.48.0/24 or + 198.18.0.0/15 or + 198.51.100.0/24 or + 203.0.113.0/24 or + 240.0.0.0/4 or + "::1" or + "FE80::/10" or + "FF00::/8" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Non-Application Layer Protocol +** ID: T1095 +** Reference URL: https://attack.mitre.org/techniques/T1095/ +* Technique: +** Name: Protocol Tunneling +** ID: T1572 +** Reference URL: https://attack.mitre.org/techniques/T1572/ +* Technique: +** Name: Encrypted Channel +** ID: T1573 +** Reference URL: https://attack.mitre.org/techniques/T1573/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-kubernetes-secret-get-or-list-from-node-or-pod-service-account.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-kubernetes-secret-get-or-list-from-node-or-pod-service-account.asciidoc new file mode 100644 index 0000000000..1c5441494a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-kubernetes-secret-get-or-list-from-node-or-pod-service-account.asciidoc @@ -0,0 +1,128 @@ +[[prebuilt-rule-8-19-27-kubernetes-secret-get-or-list-from-node-or-pod-service-account]] +=== Kubernetes Secret get or list from Node or Pod Service Account + +Kubernetes audit identities for kubelet (`system:node:*`) and workloads (`system:serviceaccount:*`) are meant to operate with tight, predictable API usage. Direct `get` or `list` on the Secrets API from those principals is often a sign of credential access. Attackers who stole a pod service-account token or node credentials sweep Secret objects for tokens, registry credentials, TLS keys, or application configuration. Even denied attempts still reveal intent to reach sensitive material. Legitimate controllers do read secrets they mount or manage, so this signal is most valuable when paired with triage (namespace scope, user agent, RBAC, and whether the identity should touch those secret names at all). + +*Rule type*: query + +*Rule indices*: + +* logs-kubernetes.audit_logs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1552/007/ +* https://kubernetes.io/docs/reference/access-authn-authz/authentication/#service-account-tokens + +*Tags*: + +* Data Source: Kubernetes +* Domain: Kubernetes +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Kubernetes Secret get or list from Node or Pod Service Account* + + +This rule fires on Kubernetes audit events where the authenticated user is a node (`system:node:`) or a +pod service account (`system:serviceaccount::`) and the verb maps to read-style access +(`get`, `list`) on the **secrets** resource. Treat node-originated secret reads as high priority: kubelet should +not broadly enumerate cluster secrets. For service accounts, prioritize cross-namespace access, access to +high-value secret names, and clients that do not match the workload’s normal user agent or deployment. + + +*Possible investigation steps* + + +- Resolve `user.name` (or `kubernetes.audit.user.username` if present) to the node or workload and review RBAC + RoleBindings and ClusterRoleBindings for secret `get`/`list` scope. +- Inspect `kubernetes.audit.objectRef.namespace`, `kubernetes.audit.objectRef.name`, source IP, and + `user_agent.original` for automation you recognize versus anomalous scripts or generic HTTP clients. +- Review `kubernetes.audit.annotations.authorization_k8s_io/decision` for successful reads versus probing denials. +- Correlate with pod exec, token creation, RoleBinding changes, or secret modification in the same time window. + + +*False positive analysis* + + +- Controllers that reconcile Secrets (e.g. cert-manager, external-secrets, sealed-secrets) may match; allowlist their + service accounts if behavior is expected and scoped. +- Helm and package managers can list release secrets during deploys; correlate with pipelines and chart releases. + + +*Response and remediation* + + +- If malicious, revoke the token or node credentials, cordon or isolate the host or workload, rotate exposed secrets, and + tighten RBAC to least privilege for the affected identity. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"kubernetes.audit_logs" and +event.action:(get or list) and +kubernetes.audit.objectRef.resource:"secrets" and +user.name:(system\:serviceaccount\:* or system\:node\:*) and source.ip:(* and not "127.0.0.1") and +not kubernetes.audit.user.groups:( + "system:serviceaccounts:flux-system" + or "system:serviceaccounts:kyverno" + or "system:serviceaccounts:ibm-csi" + or "system:serviceaccounts:harvester-system" + or "system:serviceaccounts:cattle-system" + or "system:serviceaccounts:cattle-monitoring-system" + or system\:serviceaccounts\:cluster-fleet-local-local-* + or "system:serviceaccounts:rabbitmq-system" + or "system:serviceaccounts:cattle-fleet-system" +) and +not (kubernetes.audit.user.username:"system:serviceaccount:security:trivy-operator" and kubernetes.audit.user.extra.authentication.kubernetes.io/pod-name :trivy-operator-*) and +not (kubernetes.audit.user.username:"system:serviceaccount:cert-manager:cert-manager-cainjector" and kubernetes.audit.user.extra.authentication.kubernetes.io/pod-name:cert-manager-cainjector-*) and +not (kubernetes.audit.user.username:"system:serviceaccount:monitoring:plat-central-monitoring-pr-operator" and kubernetes.audit.user.extra.authentication.kubernetes.io/pod-name:plat-central-monitoring-pr-operator*) and +not (kubernetes.audit.user.username:"system:serviceaccount:cert-manager:cert-manager" and kubernetes.audit.user.extra.authentication.kubernetes.io/pod-name:cert-manager-*) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Container API +** ID: T1552.007 +** Reference URL: https://attack.mitre.org/techniques/T1552/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-linux-external-ip-address-discovery-via-curl.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-linux-external-ip-address-discovery-via-curl.asciidoc new file mode 100644 index 0000000000..260a3014bc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-linux-external-ip-address-discovery-via-curl.asciidoc @@ -0,0 +1,181 @@ +[[prebuilt-rule-8-19-27-linux-external-ip-address-discovery-via-curl]] +=== Linux External IP Address Discovery via Curl + +Detects applications making a curl request to a known public IP address lookup web service. Malware tends to perform this action to assess potential targets. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Discovery +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Linux External IP Address Discovery via Curl* + + +This rule flags a Linux process that uses curl to contact public IP lookup sites, a common way malware learns the host’s internet-facing address before choosing follow-on actions. An attacker who gains shell access on a server or container may run curl against services like ifconfig.me or ipify, then use the returned address to verify outbound reachability, tailor command-and-control, or decide whether the system sits behind cloud or NAT infrastructure. + + +*Possible investigation steps* + + +- Trace the full process ancestry and nearby commands to determine whether the curl execution came from an interactive shell, scheduled task, deployment script, container entrypoint, or an unexpected program launched from a writable path. +- Review the invoked URL, arguments, working directory, and any captured output to determine whether the request was a one-off connectivity check or part of a broader script performing follow-on discovery, download, or beaconing. +- Correlate the activity with the initiating account, TTY/session details, recent SSH and sudo events, and change records to quickly separate approved administrator troubleshooting from suspicious post-compromise behavior. +- Pivot to surrounding network activity from the same host to identify repeated lookups, subsequent outbound connections to unfamiliar infrastructure, or signs of staging and command-and-control immediately after the public IP query. +- Inspect the parent script or binary on disk for recent creation or modification, unusual persistence mechanisms, and prevalence on peer systems to assess whether the behavior is tied to malware, a rogue change, or benign automation. + + +*False positive analysis* + + +- Legitimate startup, login-banner, or scheduled maintenance scripts may use curl to learn the host’s public IP for configuration or status display, so verify the parent script or service path is expected, recently approved, and consistently seen at boot or on a routine schedule. +- An administrator or engineer may manually run curl to a public IP lookup site during troubleshooting or deployment validation, so confirm the initiating user, TTY or session context, and shell history align with authorized activity and that no suspicious follow-on commands occurred. + + +*Response and remediation* + + +- Isolate the affected Linux host or container from the network immediately, allow only a secured management path, and preserve volatile evidence such as the running parent process, shell history, and the script or binary that launched curl. +- Terminate the malicious process chain and remove persistence by inspecting and cleaning cron jobs, systemd unit files, rc.local, user shell profiles, container entrypoints, SSH authorized_keys, and any attacker files staged in writable locations such as /tmp, /var/tmp, or /dev/shm. +- Rotate credentials and secrets exposed to the compromised system, including SSH keys, API tokens, cloud instance credentials, and application secrets found in scripts, environment files, or shell history. +- Restore the asset to a known-good state by rebuilding from a trusted image or clean backup and validating startup scripts, packages, and container images before returning the system to production. +- Escalate to incident response and broaden scoping across peer systems if the IP lookup was followed by downloads, reverse shells, new outbound connections to unfamiliar infrastructure, or if the same parent script, binary, or persistence artifact appears on multiple hosts. +- Harden the environment by restricting outbound curl access to approved destinations, blocking public IP lookup services where not needed, limiting execution from writable directories, and adding detections for unexpected systemd, cron, and shell-profile modifications. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Elastic Defend + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start") and +process.name == "curl" and ( + process.parent.name like ".*" or process.parent.executable like ( + "/tmp/*", "/var/tmp/*", "/dev/shm/*", "/opt/*", "/etc/*", "./*", "/run/user/*", "/var/run/user/*", + "/usr/bin/*", "/bin/*", "/usr/local/bin/*", "/sbin/*", "/usr/sbin/*", "/usr/local/sbin/*", + "/usr/lib/*", "/usr/local/lib/*", "/lib/*", "/lib64/*", "/usr/lib64/*", "/usr/local/lib64/*" + ) +) and +process.command_line like~ ( + "*ip-api.com*", "*checkip.dyndns.org*", "*api.ipify.org*", "*whatismyip.akamai.com*", "*bot.whatismyipaddress.com*", + "*ifcfg.me*", "*ifconfig.me*", "*ident.me*", "*ipof.in*", "*ip.tyk.nu*", "*icanhazip.com*", "*curlmyip.com*", + "*wgetip.com*", "*eth0.me*", "*ipecho.net*", "*ip.appspot.com*", "*api.myip.com*", "*geoiptool.com*", "*api.2ip.ua*", + "*api.ip.sb*", "*ipinfo.io*", "*checkip.amazonaws.com*", "*wtfismyip.com*", "*iplogger.*", "*freegeoip.net*", + "*freegeoip.app*", "*geoplugin.net*", "*myip.dnsomatic.com*", "*www.geoplugin.net*", + "*api64.ipify.org*", "*ip4.seeip.org*", "*.geojs.io*", "*portmap.io*", "*api.db-ip.com*", + "*geolocation-db.com*", "*httpbin.org*", "*myip.opendns.com*", "*ipv4.icanhazip.com*", "*ipv6.icanhazip.com*" +) and +not ( + process.parent.name in ("jamf", "make") or + process.parent.name in (".", "./alert_api_call.sh", "nvim", "teleport") or + process.parent.executable like ( + "/usr/local/bin/teleport", "/usr/local/bin/current_ip", "/tmp/go-build*", "/usr/bin/neofetch", + "/usr/bin/show-location-info", "/opt/tpot/bin/myip.sh", "/usr/sbin/sshd", "/tmp/newroot/var/quest/kace/scripts/*", + "./Linux_Inventory_Sheets.sh", "/opt/qvm/bin/update_info_qsuite", "/usr/lib/check_mk_agent/local/public_ip_check", + "/opt/teleport/system/bin/teleport", "/opt/Elastic/Endpoint/elastic-endpoint", "/etc/update-motd.d/motd.sh", + "/opt/coe/cadence/IC231/tools.lnx86/cda/bin/64bit/cda.exe", "/etc/update-motd.d/10-armbian-header", + "/opt/saltstack/salt/bin/python*", "/usr/bin/python*", "/usr/local/bin/detect-external-ip" + ) or + process.parent.args in ("/var/www/html/admin/modules/leucoalarm/scripts/system.php", "/etc/cont-init.d/50-ddns") or + ( + process.parent.executable == "/usr/bin/java" and + process.args like "/opt/streamsets-datacollector/libexec/bootstrap-libs/*" + ) or + process.parent.command_line == "runc init" or + ( + process.parent.executable == "/usr/bin/busybox" and + (process.parent.command_line == "sh /etc/cont-init.d/50-ddns" or process.working_directory == "/opt/outline-server") + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Network Configuration Discovery +** ID: T1016 +** Reference URL: https://attack.mitre.org/techniques/T1016/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-microsoft-graph-request-email-access-by-unusual-user-and-client.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-microsoft-graph-request-email-access-by-unusual-user-and-client.asciidoc new file mode 100644 index 0000000000..60f2c2ea0c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-microsoft-graph-request-email-access-by-unusual-user-and-client.asciidoc @@ -0,0 +1,150 @@ +[[prebuilt-rule-8-19-27-microsoft-graph-request-email-access-by-unusual-user-and-client]] +=== Microsoft Graph Request Email Access by Unusual User and Client + +Identifies access to email resources via Microsoft Graph API using an first-party application on behalf of a user principal. This behavior may indicate an adversary using a phished OAuth refresh token or a Primary Refresh Token (PRT) to access email resources. The pattern includes requests to Microsoft Graph API endpoints related to email, such as /me/mailFolders/inbox/messages or /users/{user_id}/messages, using a public client application ID and a user principal object ID. This is a New Terms rule that only signals if the application ID and user principal object ID have not been seen doing this activity in the last 14 days. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-azure.graphactivitylogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/ +* https://github.com/dirkjanm/ROADtools +* https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/ +* https://pushsecurity.com/blog/consentfix + +*Tags*: + +* Domain: Cloud +* Domain: Email +* Data Source: Azure +* Data Source: Microsoft Graph +* Data Source: Microsoft Graph Activity Logs +* Use Case: Threat Detection +* Tactic: Collection +* Resources: Investigation Guide + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Microsoft Graph Request Email Access by Unusual User and Client* + + +This rule detects instances where a previously unseen or rare Microsoft Graph application client ID accesses email-related APIs, such as `/me/messages`, `/sendMail`, or `/mailFolders/inbox/messages`. These accesses are performed via delegated user credentials using common OAuth scopes like `Mail.Read`, `Mail.ReadWrite`, `Mail.Send`, or `email`. This activity may indicate unauthorized use of a newly consented or compromised application to read or exfiltrate mail content. This is a New Terms rule that only signals if the application ID (`azure.graphactivitylogs.properties.app_id`) and user principal object ID (`azure.graphactivitylogs.properties.user_principal_object_id`) have not been seen doing this activity in the last 14 days. + + +*Possible Investigation Steps:* + + +- `azure.graphactivitylogs.properties.app_id`: Investigate the application ID involved. Is it known and sanctioned in your tenant? Pivot to Azure Portal → Enterprise Applications → Search by App ID to determine app details, publisher, and consent status. +- `azure.graphactivitylogs.properties.scopes`: Review the scopes requested by the application. Email-related scopes such as `Mail.ReadWrite` and `Mail.Send` are especially sensitive and suggest the app is interacting with mail content. +- `url.path` / `azure.graphactivitylogs.properties.requestUri`: Determine exactly which mail-related APIs were accessed (e.g., reading inbox, sending messages, enumerating folders). +- `user.id`: Identify the user whose credentials were used. Determine if the user recently consented to a new app, clicked a phishing link, or reported suspicious activity. +- `user_agent.original`: Check for suspicious automation tools (e.g., `python-requests`, `curl`, non-browser agents), which may suggest scripted access. +- `source.ip` and `client.geo`: Investigate the source IP and geography. Look for unusual access from unexpected countries, VPS providers, or anonymizing services. +- `http.request.method`: Determine intent based on HTTP method — `GET` (reading), `POST` (sending), `PATCH`/`DELETE` (modifying/removing messages). +- `token_issued_at` and `@timestamp`: Determine how long the token has been active and whether access is ongoing or recent. +- `azure.graphactivitylogs.properties.c_sid`: Use the session correlation ID to identify other related activity in the same session. This may help identify if the app is accessing multiple users' mailboxes or if the same user is accessing multiple apps. +- Correlate with Microsoft Entra ID (`azure.auditlogs` and `azure.signinlogs`) to determine whether: + - The app was recently granted admin or user consent + - Risky sign-ins occurred just prior to or after mail access + - The same IP or app ID appears across multiple users + + +*False Positive Analysis* + + +- New legitimate apps may appear after a user consents via OAuth. Developers, third-party tools, or IT-supplied utilities may access mail APIs if users consent. +- Users leveraging Microsoft development environments (e.g., Visual Studio Code) may trigger this behavior with delegated `.default` permissions. +- Admin-approved apps deployed via conditional access may trigger similar access logs if not previously seen in detection baselines. + + +*Response and Remediation* + + +- If access is unauthorized or unexpected: + - Revoke the app's consent in Azure AD via the Enterprise Applications blade. + - Revoke user refresh tokens via Microsoft Entra or PowerShell. + - Investigate the user's session and alert them to possible phishing or OAuth consent abuse. +- Review and restrict risky OAuth permissions in Conditional Access and App Governance policies. +- Add known, trusted app IDs to a detection allowlist to reduce noise in the future. +- Continue monitoring the app ID for additional usage across the tenant or from suspicious IPs. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.graphactivitylogs + and azure.graphactivitylogs.properties.app_id:* + and azure.graphactivitylogs.result_signature:200 + and azure.graphactivitylogs.properties.c_idtyp:user + and azure.graphactivitylogs.properties.client_auth_method:0 + and http.request.method:(DELETE or GET or PATCH or POST or PUT) + and ( + ( + url.path:(/v1.0/me/* or /v1.0/users/*) + and ( + url.path:((*inbox* or *mail* or *messages*) and not *mailboxSettings*) + or azure.graphactivitylogs.properties.requestUri:(*inbox* or *mail* or *messages*) + ) + ) + or azure.graphactivitylogs.properties.scopes:(Mail.Read or Mail.ReadWrite or Mail.Send) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Email Collection +** ID: T1114 +** Reference URL: https://attack.mitre.org/techniques/T1114/ +* Sub-technique: +** Name: Remote Email Collection +** ID: T1114.002 +** Reference URL: https://attack.mitre.org/techniques/T1114/002/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-multiple-alerts-in-different-att-ck-tactics-on-a-single-host.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-multiple-alerts-in-different-att-ck-tactics-on-a-single-host.asciidoc new file mode 100644 index 0000000000..53e43eda45 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-multiple-alerts-in-different-att-ck-tactics-on-a-single-host.asciidoc @@ -0,0 +1,97 @@ +[[prebuilt-rule-8-19-27-multiple-alerts-in-different-att-ck-tactics-on-a-single-host]] +=== Multiple Alerts in Different ATT&CK Tactics on a Single Host + +This rule uses alert data to determine when multiple alerts in different phases of an attack involving the same host are triggered. Analysts can use this to prioritize triage and response, as these hosts are more likely to be compromised. + +*Rule type*: threshold + +*Rule indices*: + +* .alerts-security.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 1h + +*Searches indices from*: now-24h ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Use Case: Threat Detection +* Rule Type: Higher-Order Rule +* Resources: Investigation Guide + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Multiple Alerts in Different ATT&CK Tactics on a Single Host* + + +The detection rule identifies hosts with alerts across various attack phases, indicating potential compromise. Adversaries exploit system vulnerabilities, moving through different tactics like execution, persistence, and exfiltration. This rule prioritizes hosts with diverse tactic alerts, aiding analysts in focusing on high-risk threats by correlating alert data to detect complex attack patterns. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific host involved and the different ATT&CK tactics that triggered the alerts. +- Examine the timeline of the alerts to understand the sequence of events and determine if there is a pattern or progression in the tactics used. +- Correlate the alert data with other logs and telemetry from the host, such as process creation, network connections, and file modifications, to gather additional context. +- Investigate any known vulnerabilities or misconfigurations on the host that could have been exploited by the adversary. +- Check for any indicators of compromise (IOCs) associated with the alerts, such as suspicious IP addresses, domains, or file hashes, and search for these across the network. +- Assess the impact and scope of the potential compromise by determining if other hosts or systems have similar alerts or related activity. + + +*False positive analysis* + + +- Alerts from routine administrative tasks may trigger multiple tactics. Review and exclude known benign activities such as scheduled software updates or system maintenance. +- Security tools running on the host might generate alerts across different tactics. Identify and exclude alerts from trusted security applications to reduce noise. +- Automated scripts or batch processes can mimic adversarial behavior. Analyze and whitelist these processes if they are verified as non-threatening. +- Frequent alerts from development or testing environments can be misleading. Consider excluding these environments from the rule or applying a different risk score. +- User behavior anomalies, such as accessing multiple systems or applications, might trigger alerts. Implement user behavior baselines to differentiate between normal and suspicious activities. + + +*Response and remediation* + + +- Isolate the affected host from the network immediately to prevent further lateral movement by the adversary. +- Conduct a thorough forensic analysis of the host to identify the specific vulnerabilities exploited and gather evidence of the attack phases involved. +- Remove any identified malicious software or unauthorized access tools from the host, ensuring all persistence mechanisms are eradicated. +- Apply security patches and updates to the host to address any exploited vulnerabilities and prevent similar attacks. +- Restore the host from a known good backup if necessary, ensuring that the backup is free from compromise. +- Monitor the host and network for any signs of re-infection or further suspicious activity, using enhanced logging and alerting based on the identified attack patterns. +- Escalate the incident to the appropriate internal or external cybersecurity teams for further investigation and potential legal action if the attack is part of a larger campaign. + +==== Rule query + + +[source, js] +---------------------------------- +signal.rule.name:* and kibana.alert.rule.threat.tactic.id:* and host.id:* and host.name:* and +event.dataset:* and kibana.alert.risk_score > 21 and +not kibana.alert.rule.type:(threat_match or machine_learning) + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-multiple-remote-management-tool-vendors-on-same-host.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-multiple-remote-management-tool-vendors-on-same-host.asciidoc new file mode 100644 index 0000000000..420d4461d4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-multiple-remote-management-tool-vendors-on-same-host.asciidoc @@ -0,0 +1,297 @@ +[[prebuilt-rule-8-19-27-multiple-remote-management-tool-vendors-on-same-host]] +=== Multiple Remote Management Tool Vendors on Same Host + +Identifies a Windows host where two or more distinct remote monitoring and management (RMM) or remote-access tool vendors are observed starting processes within the same eight-minute window. Legitimate MSP environments may run multiple tools, but this pattern can also indicate compromise, shadow IT, or attacker staging of redundant access. Processes are mapped to a single vendor label so multiple binaries from the same vendor do not inflate the count. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 8m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1219/ +* https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-025a +* https://lolrmm.io/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Command and Control +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Crowdstrike +* Data Source: Windows Security Event Logs +* Data Source: Winlogbeat + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Multiple Remote Management Tool Vendors on Same Host* + + +This rule aggregates process start events by `host.id` and host name within the rule's nine-minute lookback window. Data can come from Elastic Defend, Sysmon, Winlogbeat, Windows Security / forwarded events, Microsoft Defender XDR, SentinelOne, or CrowdStrike FDR—where ECS process fields are populated. Each known RMM-related process name maps to one **vendor** label (e.g. TeamViewer, AnyDesk, ScreenConnect). If **two or more different vendor labels** appear within the same lookback window, the rule signals. + + +*Possible investigation steps* + + +- Open **Esql.vendors_seen** and **Esql.processes_executable_values** on the alert to see which tools fired in the window. +- Confirm whether the host is an MSP-managed jump box, helpdesk workstation, or lab where multiple RMM stacks are expected. +- For servers or standard user endpoints, treat as higher risk: review install source, code signatures, and recent logons. +- Correlate with other alerts (ingress tool transfer, suspicious scripting, new persistence) on the same `host.id`. +- Check asset inventory and change tickets for approved RMM software. + + +*False positive analysis* + + +- **MSP / IT tooling**: A technician machine with two approved agents (e.g. RMM + remote support) may match. Tune with host or organizational unit exceptions, or raise the vendor threshold if your environment standardizes on a known pair. +- **Vendor rebrands or bundles**: Rare overlaps during migrations can briefly show two vendors; validate timeline and packages. + + +*Response and remediation* + + +- If unauthorized or unexplained: isolate the host, inventory installed remote-access software, remove unapproved tools, and reset credentials that may have been exposed. Enforce a single approved RMM stack per asset class where possible. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-endpoint.events.process-*, logs-crowdstrike.fdr*, logs-m365_defender.event-*, logs-sentinel_one_cloud_funnel.*, logs-system.security*, logs-windows.sysmon_operational-*, logs-windows.forwarded*, winlogbeat-* metadata _id, _version, _index +| where (host.os.type == "windows" or host.os.family == "windows") + and event.category == "process" + and event.type == "start" + and process.name is not null +| eval Esql.rmm_vendor = case( + process.name.caseless like "aa_v*.exe", "AnyAssist", + process.name.caseless == "acroniscyberprotectconnectagent.exe", "Acronis", + process.name.caseless == "aeroadmin.exe", "AeroAdmin", + process.name.caseless == "agentmon.exe", "ConnectWiseAutomate", + process.name.caseless == "anydesk.exe", "AnyDesk", + process.name.caseless == "apc_admin.exe", "APC", + process.name.caseless == "apc_host.exe", "APC", + process.name.caseless == "ateraagent.exe", "Atera", + process.name.caseless like "aweray_remote*.exe", "AweSun", + process.name.caseless == "awesun.exe", "AweSun", + process.name.caseless == "b4-service.exe", "BeyondTrust", + process.name.caseless == "basupsrvc.exe", "BeyondTrust", + process.name.caseless == "bomgar-scc.exe", "BeyondTrust", + process.name.caseless == "remote support.exe", "BeyondTrust", + process.name.caseless == "cagservice.exe", "BarracudaRMM", + process.name.caseless == "cloudracmd.exe", "CloudRadial", + process.name.caseless == "cloudrasd.exe", "CloudRadial", + process.name.caseless == "cloudraservice.exe", "CloudRadial", + process.name.caseless like "connectwisecontrol*.exe", "ScreenConnect", + process.name.caseless == "domotzagent.exe", "Domotz", + process.name.caseless == "domotz-windows-x64-10.exe", "Domotz", + process.name.caseless == "dwagsvc.exe", "DWService", + process.name.caseless == "dwrcc.exe", "DWService", + process.name.caseless == "dwrcs.exe", "DWService", + process.name.caseless == "dwrcst.exe", "DWService", + process.name.caseless like "fleetdeck_commander*.exe", "FleetDeck", + process.name.caseless == "g2aservice.exe", "GoTo", + process.name.caseless == "getscreen.exe", "GetScreen", + process.name.caseless == "gotoassistservice.exe", "GoTo", + process.name.caseless == "gotohttp.exe", "GoTo", + process.name.caseless == "gotoresolveprocesschecker.exe", "GoTo", + process.name.caseless == "gotoresolveremotecontrol.exe", "GoTo", + process.name.caseless == "gotoresolveservice.exe", "GoTo", + process.name.caseless == "gotoresolveterminal.exe", "GoTo", + process.name.caseless == "gotoresolveunattended.exe", "GoTo", + process.name.caseless == "helpwire.exe", "HelpWire", + process.name.caseless == "immyagent.exe", "ImmyBot", + process.name.caseless == "immybot.agent.ephemeral.exe", "ImmyBot", + process.name.caseless == "immyupdater.exe", "ImmyBot", + process.name.caseless == "imperoclientsvc.exe", "Impero", + process.name.caseless == "imperoserversvc.exe", "Impero", + process.name.caseless == "isllight.exe", "ISLOnline", + process.name.caseless == "isllightclient.exe", "ISLOnline", + process.name.caseless == "jumpcloud-agent.exe", "JumpCloud", + process.name.caseless == "komari.exe", "Komari", + process.name.caseless == "komari-agent.exe", "Komari", + process.name.caseless == "level.exe", "Level", + process.name.caseless == "lmi_rescue.exe", "LogMeIn", + process.name.caseless == "lmi_rescue_srv.exe", "LogMeIn", + process.name.caseless == "lmiignition.exe", "LogMeIn", + process.name.caseless == "logmein.exe", "LogMeIn", + process.name.caseless == "ltsvc.exe", "ConnectWiseAutomate", + process.name.caseless == "ltsvcmon.exe", "ConnectWiseAutomate", + process.name.caseless == "lttray.exe", "ConnectWiseAutomate", + process.name.caseless == "lunixar.exe", "Lunixar", + process.name.caseless == "lunixarremote.exe", "Lunixar", + process.name.caseless == "lunixarupdater.exe", "Lunixar", + process.name.caseless == "lvagent.exe", "Level", + process.name.caseless == "manageengine_remote_access_plus.exe", "ManageEngine", + process.name.caseless == "meshagent.exe", "MeshCentral", + process.name.caseless == "mikogo-service.exe", "Mikogo", + process.name.caseless == "nezha-agent.exe", "Nezha", + process.name.caseless == "ninjarmmagent.exe", "NinjaOne", + process.name.caseless == "ninjarmmagentpatcher.exe", "NinjaOne", + process.name.caseless == "ninjarmm-cli.exe", "NinjaOne", + process.name.caseless == "parsec.exe", "Parsec", + process.name.caseless == "pservice.exe", "Pulseway", + process.name.caseless == "quickassist.exe", "QuickAssist", + process.name.caseless == "r_server.exe", "Radmin", + process.name.caseless == "radmin.exe", "Radmin", + process.name.caseless == "radmin3.exe", "Radmin", + process.name.caseless == "rcengmgru.exe", "Rsupport", + process.name.caseless == "rcclient.exe", "RPCSuite", + process.name.caseless == "rcmgrsvc.exe", "Rsupport", + process.name.caseless == "rcservice.exe", "RPCSuite", + process.name.caseless == "remotedesktopmanager.exe", "Devolutions", + process.name.caseless == "remotely_agent.exe", "Remotely", + process.name.caseless == "remotely_desktop.exe", "Remotely", + process.name.caseless == "remotepc.exe", "RemotePC", + process.name.caseless == "remotepcdesktop.exe", "RemotePC", + process.name.caseless == "remotepcservice.exe", "RemotePC", + process.name.caseless == "remoteview.exe", "Rsupport", + process.name.caseless == "rfusclient.exe", "RemoteUtilities", + process.name.caseless == "rmm.agent.exe", "SuperOps", + process.name.caseless == "romserver.exe", "RealVNC", + process.name.caseless == "romviewer.exe", "RealVNC", + process.name.caseless == "rpcsuite.exe", "RPCSuite", + process.name.caseless == "rserver3.exe", "Radmin", + process.name.caseless == "rustdesk.exe", "RustDesk", + process.name.caseless == "rutserv.exe", "RemoteUtilities", + process.name.caseless == "rutview.exe", "RemoteUtilities", + process.name.caseless == "rvagent.exe", "Rsupport", + process.name.caseless == "rvagtray.exe", "Rsupport", + process.name.caseless == "saazapsc.exe", "Kaseya", + process.name.caseless like "screenconnect*.exe", "ScreenConnect", + process.name.caseless == "session_win.exe", "ZohoAssist", + process.name.caseless == "simplegatewayservice.exe", "SimpleHelp", + process.name.caseless == "simplehelpcustomer.exe", "SimpleHelp", + process.name.caseless == "smpcview.exe", "Splashtop", + process.name.caseless == "spclink.exe", "Splashtop", + process.name.caseless == "splashtop-streamer.exe", "Splashtop", + process.name.caseless == "splashtopsos.exe", "Splashtop", + process.name.caseless == "spsrv.exe", "Splashtop", + process.name.caseless == "sragent.exe", "Splashtop", + process.name.caseless == "srservice.exe", "Splashtop", + process.name.caseless == "srmanager.exe", "Splashtop", + process.name.caseless == "srserver.exe", "Splashtop", + process.name.caseless == "strwinclt.exe", "Splashtop", + process.name.caseless == "supremo.exe", "Supremo", + process.name.caseless == "supremoservice.exe", "Supremo", + process.name.caseless == "syncro.app.runner.exe", "Splashtop", + process.name.caseless == "syncro.installer.exe", "Splashtop", + process.name.caseless == "syncro.overmind.service.exe", "Splashtop", + process.name.caseless == "syncro.service.exe", "Splashtop", + process.name.caseless == "syncrolive.agent.exe", "Splashtop", + process.name.caseless == "syncrolive.agent.runner.exe", "Splashtop", + process.name.caseless == "syncrolive.service.exe", "Splashtop", + process.name.caseless == "tacticalrmm.exe", "TacticalRMM", + process.name.caseless == "tailscale.exe", "Tailscale", + process.name.caseless == "tailscaled.exe", "Tailscale", + process.name.caseless == "teamviewer.exe", "TeamViewer", + process.name.caseless == "teamviewer_desktop.exe", "TeamViewer", + process.name.caseless == "teamviewer_service.exe", "TeamViewer", + process.name.caseless == "tiagent.exe", "Tiflux", + process.name.caseless == "ticlientcore.exe", "Tiflux", + process.name.caseless == "todesk_service.exe", "ToDesk", + process.name.caseless == "toolsiq.exe", "ToolsIQ", + process.name.caseless == "tsclient.exe", "Techinline", + process.name.caseless == "tvn.exe", "TightVNC", + process.name.caseless == "tvnserver.exe", "TightVNC", + process.name.caseless == "tvnviewer.exe", "TightVNC", + process.name.caseless == "twingate.exe", "Twingate", + process.name.caseless like "ultravnc*.exe", "UltraVNC", + process.name.caseless like "ultraviewer*.exe", "UltraViewer", + process.name.caseless == "velociraptor.exe", "Velociraptor", + process.name.caseless == "vncserver.exe", "RealVNC", + process.name.caseless == "vncviewer.exe", "RealVNC", + process.name.caseless == "winvnc.exe", "RealVNC", + process.name.caseless == "winwvc.exe", "TightVNC", + process.name.caseless == "za_access.exe", "ZohoAssist", + process.name.caseless == "za_connect.exe", "ZohoAssist", + process.name.caseless == "zaservice.exe", "ZohoAssist", + process.name.caseless == "zmagent.exe", "ZohoAssist", + process.name.caseless == "zohomeeting.exe", "ZohoAssist", + process.name.caseless == "zohotray.exe", "ZohoAssist", + process.name.caseless == "zohours.exe", "ZohoAssist", + process.name.caseless == "zohoursservice.exe", "ZohoAssist", + "" + ) +| where Esql.rmm_vendor != "" and Esql.rmm_vendor is not NULL +| stats Esql.vendor_count = count_distinct(Esql.rmm_vendor), + Esql.vendors_seen = values(Esql.rmm_vendor), + Esql.processes_executable_values = values(process.executable), + Esql.first_seen = min(@timestamp), + Esql.last_seen = max(@timestamp) + by host.name, host.id +| where Esql.vendor_count >= 2 +| sort Esql.vendor_count desc +| keep host.id, host.name, Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Remote Access Tools +** ID: T1219 +** Reference URL: https://attack.mitre.org/techniques/T1219/ +* Sub-technique: +** Name: Remote Desktop Software +** ID: T1219.002 +** Reference URL: https://attack.mitre.org/techniques/T1219/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-network-connection-followed-by-file-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-network-connection-followed-by-file-creation.asciidoc new file mode 100644 index 0000000000..1b26fd0341 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-network-connection-followed-by-file-creation.asciidoc @@ -0,0 +1,192 @@ +[[prebuilt-rule-8-19-27-network-connection-followed-by-file-creation]] +=== Network Connection Followed by File Creation + +Detects network connections originating from a binary located in a potentially suspicious location, followed by a file creation event. This behavior is consistent with C2 agents such as Poseidon and Athena, connecting to a C2 framework such as Mythic. The agent polls the C2 for commands through a web request, after which the command gets executed. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.network* +* logs-endpoint.events.file* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Command and Control +* Tactic: Execution +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Network Connection Followed by File Creation* + + +This rule spots a Linux process running from an unusual writable directory that makes an outbound connection and then creates a file within seconds, a pattern that often marks an active implant receiving tasks and staging follow-on activity. Attackers launch a loader from /dev/shm or /tmp, poll a remote web-based command server, and immediately drop a script or renamed payload for execution or persistence. + + +*Possible investigation steps* + + +- Review the process ancestry and launch context for the binary in the writable directory to determine whether it originated from a user session, script, scheduled task, package operation, or remote execution mechanism. +- Inspect the external destination's reputation, ownership, protocol details, and whether other hosts contacted it at similar times to distinguish approved software behavior from likely command-and-control traffic. +- Examine the created file's location, type, hash, contents, permissions, and any immediate chmod, rename, or execution activity to assess whether it is a staged payload, script, or persistence artifact. +- Build a concise timeline around the alert to identify preceding download, decode, or unpack actions and any follow-on child processes, credential access attempts, or lateral movement from the same host. +- Search the environment for the same executable hash, destination, or dropped artifact on other systems and contain the host if you observe repeated beaconing, additional suspicious file creation, or evidence of execution. + + +*False positive analysis* + + +- A legitimate software installer, updater, or bootstrap script launched from /tmp or /var/tmp can contact an external repository and immediately create unpacked files; verify the parent process, initiating user, shell history, and whether the destination IP and dropped files align with an approved installation or update at that time. +- An administrator or automation job may execute a temporary script from /dev/shm or /run/user to fetch remote content and write logs, configuration, or cache files; confirm the activity matches a scheduled task or provisioning change and inspect the created file paths and script contents for expected benign output. + + +*Response and remediation* + + +- Isolate the affected Linux host from the network except for approved management access, kill the suspicious process running from the writable directory, quarantine the binary and any files it created, and block the contacted external IP or domain at the firewall, proxy, and DNS layers. +- Remove attacker footholds by deleting malicious systemd services, cron jobs, shell profile modifications, SSH authorized_keys entries, and any copied or renamed payloads the implant placed under writable paths or startup locations, after preserving forensic copies. +- Reset potentially exposed access by rotating passwords, SSH keys, API tokens, and service credentials used on the host, especially if the process ran as root, touched authentication files, or dropped scripts and configuration files that may contain secrets. +- Restore the system to a known-good state by reimaging or rebuilding the host from a trusted baseline when the binary or dropped files executed, then validate package integrity, startup items, and critical application data before reconnecting it to production. +- Escalate immediately to incident response if the same executable hash, outbound destination, or dropped artifact appears on additional hosts, or if you identify privilege escalation, credential theft, persistence in multiple locations, or attempted lateral movement. +- Harden the environment by blocking execution from /tmp, /dev/shm, and other writable directories where feasible, tightening egress rules to approved destinations, enforcing application allowlisting, and improving monitoring for new outbound beacons followed by file creation. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id, process.entity_id with maxspan=5s + [network where host.os.type == "linux" and event.type == "start" and event.action == "connection_attempted" and + process.executable like ( + "/boot/*", "/dev/shm/*", "/tmp/*", "/var/tmp/*", "/var/log/*", "/var/run/user/*", "/run/user/*" + ) and + not ( + destination.ip == null or + destination.ip == "0.0.0.0" or + cidrmatch( + destination.ip, "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", + "192.0.0.0/24", "192.0.0.0/29","192.0.0.8/32", "192.0.0.9/32", "192.0.0.10/32", + "192.0.0.170/32", "192.0.0.171/32", "192.0.2.0/24", "192.31.196.0/24", "192.52.193.0/24", + "192.168.0.0/16", "192.88.99.0/24", "224.0.0.0/4", "100.64.0.0/10", "192.175.48.0/24", + "198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", "240.0.0.0/4", "::1", "FE80::/10", + "FF00::/8", "FC00::/7" + ) + )] + [file where host.os.type == "linux" and event.type == "creation" and process.executable like ( + "/boot/*", "/dev/shm/*", "/tmp/*", "/var/tmp/*", "/var/log/*", "/boot/*", "/var/run/user/*", "/run/user/*" + ) and + not ( + file.name like "tmp*" or file.extension in ("sqlite-journal", "db-journal", "lockfile", "tmp") or + file.path like ( + "/loki/wal/*", "/dev/shm/.org.chromium.Chromium.*", "/opt/rapid7/nexpose/*", + "/usr/local/ltechagent*", "/var/lib/cloudendure/agent_keystore_temp", "/var/cache/yum/*", + "/run/aws-node/ipam.json.tmp*", "/run/systemd/journal/streams/.*" + ) or + (process.executable == "/tmp/terraform" and file.path like "/tmp/terraform-provider*") or + process.name in ("podman", "minikube", "logrotate", "java", "aws-k8s-agent", "grafana", "postman") or + process.executable : ( + "/etc/cron.daily/logrotate", "/etc/update-motd.d/50-motd-news", "/etc/cron.hourly/0yum-hourly.cron", + "/etc/cron.hourly/BitdefenderRedline", "/tmp/token_handler", "/tmp/.sentry-cli*.exe", + "/etc/cron.daily/0yum-daily.cron", "/etc/init.d/fortiedr" + ) + )] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Sub-technique: +** Name: Web Protocols +** ID: T1071.001 +** Reference URL: https://attack.mitre.org/techniques/T1071/001/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-payload-downloaded-by-interpreter-and-piped-to-interpreter.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-payload-downloaded-by-interpreter-and-piped-to-interpreter.asciidoc new file mode 100644 index 0000000000..5dc14c00a6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-payload-downloaded-by-interpreter-and-piped-to-interpreter.asciidoc @@ -0,0 +1,147 @@ +[[prebuilt-rule-8-19-27-payload-downloaded-by-interpreter-and-piped-to-interpreter]] +=== Payload Downloaded by Interpreter and Piped to Interpreter + +This rule detects when a payload is downloaded by an interpreter, and piped to an interpreter. Attackers may use this technique to download and execute payloads for various malicious purposes, such as establishing persistence or exfiltrating data. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.network* +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Command and Control +* Tactic: Defense Evasion +* Data Source: Elastic Defend + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id, process.parent.entity_id, process.working_directory with maxspan=1s + [network where host.os.type == "linux" and event.type == "start" and event.action == "connection_attempted" and ( + process.name like ( + "bash", "dash", "sh", "tcsh", "tclsh", "wish", "csh", "zsh", "ksh", "fish", + "mksh", "busybox", "rscript", "r", "julia", "mono", "dotnet", "groovy", "kotlin", + "scala", "erlang", "escript", "ocaml", "ocamlopt", "ld.so", "ld-linux-x86-64.so.2", + "ld-musl-x86_64.so.1", "awk", "gawk", "mawk", "nawk", "node", "nodejs", "deno", + "env", "timeout", "nice", "stdbuf", "setsid", "setarch", "unshare", "nsenter", "flock", + "runuser", "sudo", "snap" + ) or + process.name like ("python*", "perl*", "ruby*", "lua*", "php*", "qemu-*-static") + ) and + not (destination.ip == null or destination.ip == "0.0.0.0" or cidrmatch( + destination.ip, "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", "192.0.0.0/24", "192.0.0.0/29", + "192.0.0.8/32", "192.0.0.9/32", "192.0.0.10/32", "192.0.0.170/32", "192.0.0.171/32", "192.0.2.0/24", + "192.31.196.0/24", "192.52.193.0/24", "192.168.0.0/16", "192.88.99.0/24", "224.0.0.0/4", "100.64.0.0/10", + "192.175.48.0/24","198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", "240.0.0.0/4", "::1", "FE80::/10", + "FF00::/8" + ) + )] + [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and ( + process.name like ( + "bash", "dash", "sh", "tcsh", "tclsh", "wish", "csh", "zsh", "ksh", "fish", + "mksh", "busybox", "rscript", "r", "julia", "mono", "dotnet", "groovy", "kotlin", + "scala", "erlang", "escript", "ocaml", "ocamlopt", "ld.so", "ld-linux-x86-64.so.2", + "ld-musl-x86_64.so.1", "awk", "gawk", "mawk", "nawk", "node", "nodejs", "deno" + ) or + process.name like ("python*", "perl*", "ruby*", "lua*", "php*") + ) and ( + stringcontains(process.executable, process.command_line) or + stringcontains(process.name, process.command_line) + ) and + process.args_count == 1] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-persistence-via-suspicious-launch-agent-or-launch-daemon.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-persistence-via-suspicious-launch-agent-or-launch-daemon.asciidoc new file mode 100644 index 0000000000..d301c830a9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-persistence-via-suspicious-launch-agent-or-launch-daemon.asciidoc @@ -0,0 +1,149 @@ +[[prebuilt-rule-8-19-27-persistence-via-suspicious-launch-agent-or-launch-daemon]] +=== Persistence via Suspicious Launch Agent or Launch Daemon + +Identifies the creation of a launch agent or daemon property list file containing abnormal or suspicious values. An adversary may establish persistence by installing a new launch agent or daemon which executes at login. This rule looks for plist files created in LaunchAgents/LaunchDaemons directories with paths commonly used by malware. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://medium.com/red-teaming-with-a-blue-team-mentality/a-brief-look-at-macos-detections-and-post-infection-analysis-b0ede7ecfeb9 +* https://objective-see.org/blog +* https://www.elastic.co/security-labs/DPRK-strikes-using-a-new-variant-of-rustbucket + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Persistence via Suspicious Launch Agent or Launch Daemon* + + +LaunchAgents and LaunchDaemons are the standard macOS mechanisms for starting programs automatically at user login or system boot. While essential for legitimate software, these persistence mechanisms are heavily abused by malware including RustBucket (DPRK), Shlayer, and CloudMensis. This detection rule identifies plist file creation in LaunchAgent/LaunchDaemon directories when performed by suspicious processes including scripts executing from temporary directories, unsigned binaries, or scripting interpreters like Python and osascript. + + +*Possible investigation steps* + + +- Examine the file.path to identify the specific plist file created and its location (user vs system LaunchAgent/LaunchDaemon directory). +- Read the plist contents using plutil or defaults to identify the Program or ProgramArguments configured for execution. +- Analyze the process.executable to understand what created the plist file and assess whether execution from that location (temp directory, hidden folder) is suspicious. +- Check the process.name and process.code_signature fields to determine if the creating process was a scripting interpreter or unsigned binary. +- Locate the binary or script referenced in the plist and calculate its hash for threat intelligence lookups. +- Review the parent process chain to trace back to the initial execution vector that led to plist creation. +- Correlate with other file and process events to identify additional malware components that may have been deployed simultaneously. + + +*False positive analysis* + + +- Legitimate software installers may create LaunchAgents/LaunchDaemons during setup, but typically from signed installer processes rather than scripts in temp directories. +- Development and testing environments may use scripting languages to create launch items. Verify with development teams if such activities are expected. +- Several legitimate signing IDs are already excluded including vim, JetBrains Toolbox, and Sublime Text. +- System utilities like cfprefsd may modify plist files during normal operations and are excluded. +- Enterprise deployment tools may use scripts to configure launch items. Document and exclude approved deployment processes. + + +*Response and remediation* + + +- Immediately unload the suspicious LaunchAgent or LaunchDaemon using launchctl unload with the plist path. +- Remove the malicious plist file from the LaunchAgent or LaunchDaemon directory. +- Locate and remove the executable or script referenced in the plist's Program or ProgramArguments keys. +- Check for other persistence mechanisms that may have been deployed by the same threat actor. +- Review system logs for evidence of the persistence mechanism executing and what actions it performed. +- If the detection matches patterns of known malware families (RustBucket, Shlayer), perform comprehensive IOC searches and threat hunting. +- Reset any credentials that may have been accessed while the malicious process was running. +- Monitor for recreation of similar plist files to detect persistent access or ongoing compromise. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "macos" and event.type != "deletion" and + file.extension == "plist" and + file.path like ("/Library/LaunchAgents/*", "/Library/LaunchDaemons/*", + "/Users/*/Library/LaunchAgents/*", "/System/Library/LaunchAgents/*", + "/System/Library/LaunchDaemons/*") and + (process.executable like ("/private/tmp/*", "/private/var/root/Library/*", "/var/tmp/*", + "/tmp/*", "/var/folders/*", "/Users/Shared/*", "/var/root/*", + "/Library/WebServer/*", "/Library/Graphics/*", "/Library/Fonts/*") or + process.name like~ ("python*", "osascript", "bash", "zsh", "sh", "curl", "nscurl", "wget", "java")) and + not process.executable like ("/System/*", "/Library/PrivilegedHelperTools/*") and + not (process.code_signature.signing_id in ("com.apple.vim", "com.apple.cat", "com.apple.cfprefsd", + "com.jetbrains.toolbox", "com.apple.pico", "com.apple.shove", + "com.sublimetext.4", "com.apple.ditto") and process.code_signature.trusted == true) and + not (file.path like ("/Library/LaunchDaemons/com.jumpcloud.*", + "/Library/LaunchAgents/com.jumpcloud.*", + "/Library/LaunchDaemons/com.wazuh.*", + "/Library/LaunchDaemons/com.zscaler.service.plist") and + process.executable == "/bin/bash") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Plist Modification +** ID: T1547.011 +** Reference URL: https://attack.mitre.org/techniques/T1547/011/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Sub-technique: +** Name: Launch Agent +** ID: T1543.001 +** Reference URL: https://attack.mitre.org/techniques/T1543/001/ +* Sub-technique: +** Name: Launch Daemon +** ID: T1543.004 +** Reference URL: https://attack.mitre.org/techniques/T1543/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-potential-dhcp-starvation-via-high-client-mac-cardinality.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-potential-dhcp-starvation-via-high-client-mac-cardinality.asciidoc new file mode 100644 index 0000000000..925b774c4e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-potential-dhcp-starvation-via-high-client-mac-cardinality.asciidoc @@ -0,0 +1,141 @@ +[[prebuilt-rule-8-19-27-potential-dhcp-starvation-via-high-client-mac-cardinality]] +=== Potential DHCP Starvation via High Client MAC Cardinality + +Identifies a burst of DHCP DISCOVER messages with an unusually high number of distinct client hardware addresses observed on the same capture segment within a short window. Attackers flood DISCOVER requests with spoofed or random MAC addresses to exhaust the DHCP lease pool, often as a precursor to deploying a rogue DHCP server. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1498/ +* https://www.leviathansecurity.com/blog/tunnelvision +* https://wazuh.com/blog/monitoring-dhcp-starvation-attack-with-suricata-and-wazuh/ + +*Tags*: + +* Domain: Network +* Use Case: Threat Detection +* Use Case: Network Security Monitoring +* Tactic: Impact +* Data Source: Network Traffic +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential DHCP Starvation via High Client MAC Cardinality* + + +DHCP starvation floods a segment with DISCOVER messages that use many distinct client hardware addresses to consume +available leases. This rule keys on high DHCP DISCOVER volume paired with high `client_mac` cardinality seen by the +same network capture sensor, which is the wire-level starvation pattern and does not depend on host operating system. + + +*Possible investigation steps* + + +- Review `Esql.count_distinct_client_macs` and sample values in `Esql.values_client_macs` to confirm the burst is not a + single client retrying with one address. +- Identify the L2 segment or VLAN monitored by `Esql.observer` and check DHCP server logs for pool exhaustion, NAK spikes, + or lease-denial events during the same window. +- Look for follow-on rogue DHCP OFFER/ACK activity on the segment, including the Multiple DHCP Servers Responding to the + Same Transaction rule. +- Locate the transmitting host using switch CAM tables if Ethernet source addresses are available in raw capture exports. + + +*False positive analysis* + + +- Large Wi-Fi reconnect or onboarding events can temporarily increase DISCOVER volume. Compare against historical + baselines for the same `Esql.observer` and time of day before treating as malicious. +- Virtualization or VDI provisioning bursts may generate many distinct client MAC addresses during imaging. Exclude known + provisioning VLANs or sensors when the workflow is confirmed. + + +*Response and remediation* + + +- Enable or verify DHCP snooping and rate limits on the affected access switches. +- Block or isolate the source host if link-layer evidence confirms a single transmitter is generating the flood. +- Restore DHCP service capacity and monitor for rogue OFFER/ACK responses after the starvation attempt. + + +==== Setup + + + +*Setup* + + +This rule requires the Elastic network_traffic (Packetbeat) integration capturing DHCP (UDP 67/68) on the broadcast +segment where clients acquire leases, either Packetbeat running on the segment or a SPAN/mirror feeding it. + +Zeek and flow-only firewall sources are intentionally not supported: this rule requires per-DISCOVER DHCP transaction +fields and client hardware address values (`client_mac`) to measure high client MAC cardinality in a short time window. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-network_traffic.dhcpv4-*, packetbeat-* +| eval + Esql.message_type = TO_LOWER(COALESCE(network_traffic.dhcpv4.option.message_type, dhcpv4.option.message_type)), + Esql.client_mac = COALESCE(network_traffic.dhcpv4.client_mac, dhcpv4.client_mac), + Esql.observer_hostname = COALESCE(host.name, observer.hostname) +| where Esql.message_type == "discover" and Esql.client_mac is not null and Esql.observer_hostname is not null +| eval Esql.time_window = DATE_TRUNC(1 minute, @timestamp) +| stats + Esql.dhcpv4_discover_count = COUNT(*), + Esql.dhcpv4_client_mac_count_distinct = COUNT_DISTINCT(Esql.client_mac), + Esql.dhcpv4_client_mac_values = MV_SLICE(VALUES(Esql.client_mac), 0, 10) + by Esql.time_window, Esql.observer_hostname +| where Esql.dhcpv4_discover_count >= 75 and Esql.dhcpv4_client_mac_count_distinct >= 50 +| keep Esql.observer_hostname, Esql.time_window, Esql.dhcpv4_discover_count, Esql.dhcpv4_client_mac_count_distinct, Esql.dhcpv4_client_mac_values + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Network Denial of Service +** ID: T1498 +** Reference URL: https://attack.mitre.org/techniques/T1498/ +* Sub-technique: +** Name: Direct Network Flood +** ID: T1498.001 +** Reference URL: https://attack.mitre.org/techniques/T1498/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-potential-dns-exfiltration-via-excessive-chunked-queries.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-potential-dns-exfiltration-via-excessive-chunked-queries.asciidoc new file mode 100644 index 0000000000..1d309cf86b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-potential-dns-exfiltration-via-excessive-chunked-queries.asciidoc @@ -0,0 +1,165 @@ +[[prebuilt-rule-8-19-27-potential-dns-exfiltration-via-excessive-chunked-queries]] +=== Potential DNS Exfiltration via Excessive Chunked Queries + +Identifies potential DNS exfiltration on Windows hosts by detecting a high volume of DNS queries whose subdomain labels follow a chunked encoding pattern (index-payload.base_domain). Attackers split stolen data across many DNS queries to evade volume-based detection; this rule aggregates queries per process, base domain, and five-minute window and flags sessions with many distinct chunk indices and sufficiently long encoded payloads. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1048/003/ +* https://attack.mitre.org/techniques/T1572/ +* https://unit42.paloaltonetworks.com/dns-tunneling-how-dns-can-be-abused-by-malicious-actors/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Exfiltration +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Crowdstrike +* Data Source: Sysmon + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential DNS Exfiltration via Excessive Chunked Queries* + + +DNS tunneling and exfiltration often encode data in subdomain labels using a chunk index prefix (for example, +`42-.attacker.example`). A large number of distinct chunk indices to the same base domain from +one process within a short window strongly suggests staged data transfer rather than normal resolution behavior. + + +*Possible investigation steps* + + +- Review **Esql.base_domain**, **Esql.unique_chunks**, and **Esql.max_index** on the alert to gauge exfil volume and + whether chunk indices form a contiguous or near-contiguous sequence. +- Identify **process.name** and **process.executable** (from related network events on the same host) and inspect the + process tree for scripting runtimes, LOLBins, or unsigned binaries. +- Pivot on **host.id** for other DNS, network, or exfiltration alerts in the past 48 hours. +- Inspect sample **dns.question.name** values for the session to confirm encoded payload subdomains and estimate data + volume (**Esql.avg_payload_len** × **Esql.unique_chunks**). +- Check whether the base domain is newly observed, lacks business justification, or resolves to infrastructure outside + approved DNS allowlists. + + +*False positive analysis* + + +- Legitimate software that encodes telemetry or session tokens in DNS labels is rare; validate against known vendor + behavior before closing. +- Security scanners or research tools that generate synthetic chunked DNS labels may match; confirm process identity and + organizational ownership. + + +*Response and remediation* + + +- If confirmed malicious: isolate the host, block the **Esql.base_domain** at DNS and egress controls, and preserve + DNS/network logs for scoping. +- Hunt for the same **Esql.base_domain** and process hash across other hosts and users. +- Reset credentials and review data accessible to the involved user or process if exfiltration is confirmed. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/sysmon-event-22-setup[Sysmon Event ID 22 - DNS Query] + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-crowdstrike.fdr*, logs-endpoint.events.network-*, logs-windows.sysmon_operational-* +| WHERE host.os.type == "windows" + AND event.category == "network" + AND event.action IN ("lookup_requested", "DNSEvent (DNS query)", "DnsRequest") + AND process.name != "svchost.exe" + AND dns.question.name RLIKE """[0-9]{1,5}-[A-Za-z0-9+/=]{15,63}\..+""" +| GROK dns.question.name "%{INT:chunk_index}-%{DATA:chunk_payload}\\.%{GREEDYDATA:Esql.base_domain}" +| WHERE chunk_index IS NOT NULL +| EVAL payload_len = LENGTH(chunk_payload) +| STATS + Esql.occurrences = COUNT(*), + Esql.unique_chunks = COUNT_DISTINCT(chunk_index), + Esql.max_index = MAX(TO_INTEGER(chunk_index)), + Esql.avg_payload_len = AVG(payload_len) + BY process.name, Esql.base_domain, user.id, user.name, host.id, host.name, data_stream.namespace, DATE_TRUNC(5 minutes, @timestamp) +| WHERE Esql.occurrences >= 30 + AND Esql.unique_chunks >= 30 + AND Esql.avg_payload_len >= 20 +| SORT Esql.unique_chunks DESC +| LIMIT 20 +| KEEP host.id, host.name, process.name, user.id, user.name, data_stream.namespace, Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Exfiltration Over Alternative Protocol +** ID: T1048 +** Reference URL: https://attack.mitre.org/techniques/T1048/ +* Sub-technique: +** Name: Exfiltration Over Unencrypted Non-C2 Protocol +** ID: T1048.003 +** Reference URL: https://attack.mitre.org/techniques/T1048/003/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Protocol Tunneling +** ID: T1572 +** Reference URL: https://attack.mitre.org/techniques/T1572/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-potential-dns-tunneling-via-nslookup.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-potential-dns-tunneling-via-nslookup.asciidoc new file mode 100644 index 0000000000..328f1b3044 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-potential-dns-tunneling-via-nslookup.asciidoc @@ -0,0 +1,158 @@ +[[prebuilt-rule-8-19-27-potential-dns-tunneling-via-nslookup]] +=== Potential DNS Tunneling via NsLookup + +This rule identifies a large number (15) of nslookup.exe executions with an explicit query type from the same host. This may indicate command and control activity utilizing the DNS protocol. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* logs-crowdstrike.fdr* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://unit42.paloaltonetworks.com/dns-tunneling-in-the-wild-overview-of-oilrigs-dns-tunneling/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Command and Control +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Sysmon +* Data Source: Crowdstrike + +*Version*: 317 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential DNS Tunneling via NsLookup* + + +Attackers can abuse existing network rules that allow DNS communication with external resources to use the protocol as their command and control and/or exfiltration channel. + +DNS queries can be used to infiltrate data such as commands to be run, malicious files, etc., and also for exfiltration, since queries can be used to send data to the attacker-controlled DNS server. This process is commonly known as DNS tunneling. + +More information on how tunneling works and how it can be abused can be found on https://unit42.paloaltonetworks.com/dns-tunneling-how-dns-can-be-abused-by-malicious-actors[Palo Alto Unit42 Research]. + + +*Possible investigation steps* + + +- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Inspect the DNS query and identify the information sent. +- Extract this communication's indicators of compromise (IoCs) and use traffic logs to search for other potentially compromised hosts. + + +*False positive analysis* + + +- This mechanism can be used legitimately. If the parent process is trusted and the data sent is not sensitive nor command and control related, this alert can be closed. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- Immediately block the identified indicators of compromise (IoCs). +- Implement any temporary network rules, procedures, and segmentation required to contain the attack. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Update firewall rules to be more restrictive. +- Reimage the host operating system or restore the compromised files to clean versions. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] +- https://ela.st/crowdstrike-integration[CrowdStrike] + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id with maxspan=5m +[process where host.os.type == "windows" and event.type == "start" and + process.name : "nslookup.exe" and process.args:("-querytype=*", "-qt=*", "-q=*", "-type=*")] with runs = 10 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Sub-technique: +** Name: DNS +** ID: T1071.004 +** Reference URL: https://attack.mitre.org/techniques/T1071/004/ +* Technique: +** Name: Protocol Tunneling +** ID: T1572 +** Reference URL: https://attack.mitre.org/techniques/T1572/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-potential-icmp-tunneling-activity-to-the-internet.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-potential-icmp-tunneling-activity-to-the-internet.asciidoc new file mode 100644 index 0000000000..34d73d2eb7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-potential-icmp-tunneling-activity-to-the-internet.asciidoc @@ -0,0 +1,134 @@ +[[prebuilt-rule-8-19-27-potential-icmp-tunneling-activity-to-the-internet]] +=== Potential ICMP Tunneling Activity to the Internet + +Identifies ICMP Echo traffic from an internal host to an external destination with a larger-than-typical transaction size. Covert channels and ICMP tunneling tools embed data in echo payloads that exceed normal OS ping behavior, which is usually limited to small fixed-size packets. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-network_traffic.icmp-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1572/ +* https://www.rfc-editor.org/rfc/rfc792 +* https://www.levelblue.com/blogs/spiderlabs-blog/backdoor-at-the-end-of-the-icmp-tunnel + +*Tags*: + +* Domain: Network +* Tactic: Command and Control +* Use Case: Threat Detection +* Use Case: Network Security Monitoring +* Data Source: Network Traffic +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential ICMP Tunneling Activity to the Internet* + + +ICMP tunneling encodes C2 or exfiltrated data inside echo request and reply payloads. This rule focuses on internal +hosts sending unusually large echo transactions to external destinations, a pattern that differs from routine +operating-system ping and most availability monitoring. + + +*Possible investigation steps* + + +- Identify the `source.ip` host role. Servers and workstations that rarely initiate ICMP externally are higher concern. +- Review the volume and cadence of echo traffic to the same `destination.ip` for beacon-like regularity. +- Compare `network.bytes` across the conversation for asymmetric or variable payload sizes. +- Correlate with endpoint process telemetry for non-standard ping utilities or custom clients if available. + + +*False positive analysis* + + +- Some network path MTU discovery, diagnostic suites, or vendor appliances generate larger ICMP payloads. Validate and + except known monitoring sources and destinations. +- Cloud health checks occasionally use ICMP with non-default sizes; confirm against provider documentation before + excepting. + + +*Response and remediation* + + +- Block unauthorized outbound ICMP at the perimeter where policy permits, or restrict it to approved monitoring paths. +- Isolate the source host if covert-channel tooling is confirmed. +- Inspect the external destination against threat intelligence and block if malicious. + +==== Setup + + + +*Setup* + + +This rule requires the Elastic network_traffic integration capturing ICMP transactions (`network_traffic.icmp` data +stream). Flow-only telemetry without ICMP payload size is insufficient. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:network_traffic.icmp + and (network_traffic.icmp.request.type:(8 or 128) or icmp.request.type:(8 or 128)) + and network.transport:(icmp or ipv6-icmp) + and source.ip:(10.0.0.0/8 or 172.16.0.0/12 or 192.168.0.0/16 or "FC00::/7") + and network.bytes >= 256 + and not destination.ip:( + 10.0.0.0/8 or 100.64.0.0/10 or 127.0.0.0/8 or 169.254.0.0/16 or 172.16.0.0/12 or 192.168.0.0/16 or + 192.0.0.0/24 or 192.0.0.0/29 or 192.0.0.8/32 or 192.0.0.9/32 or 192.0.0.10/32 or 192.0.0.170/32 or + 192.0.0.171/32 or 192.0.2.0/24 or 192.175.48.0/24 or 192.31.196.0/24 or 192.52.193.0/24 or 192.88.99.0/24 or + 198.18.0.0/15 or 198.51.100.0/24 or 203.0.113.0/24 or 224.0.0.0/4 or 240.0.0.0/4 or "::1" or "FC00::/7" or + "FE80::/10" or "FF00::/8" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Non-Application Layer Protocol +** ID: T1095 +** Reference URL: https://attack.mitre.org/techniques/T1095/ +* Technique: +** Name: Protocol Tunneling +** ID: T1572 +** Reference URL: https://attack.mitre.org/techniques/T1572/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-potential-privilege-escalation-via-a-parent-child-process-sequence.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-potential-privilege-escalation-via-a-parent-child-process-sequence.asciidoc new file mode 100644 index 0000000000..9cfeafdf91 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-potential-privilege-escalation-via-a-parent-child-process-sequence.asciidoc @@ -0,0 +1,118 @@ +[[prebuilt-rule-8-19-27-potential-privilege-escalation-via-a-parent-child-process-sequence]] +=== Potential Privilege Escalation via a Parent/Child Process Sequence + +Detects a potential privilege escalation sequence via a parent/child process relationship. This rule checks for non-root execution of a parent process executable in a user or world-writable directory by a non-root user followed by a UID change event to 0 (root) by the child process. This sequence is indicative of a potential local privilege escalation exploit. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Data Source: Elastic Defend +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Privilege Escalation via a Parent/Child Process Sequence* + + +This rule catches a Linux process chain where a non-root user launches code from a user- or world-writable location and the child process quickly switches to running as root, a strong sign of local privilege escalation. An attacker might drop or compile an exploit in /tmp, execute it from an unprivileged account, and use the spawned child process to obtain a root shell without going through normal administrative tools. + + +*Possible investigation steps* + + +- Retrieve the executable and nearby artifacts from the writable location, then review ownership, permissions, timestamps, hashes, package provenance, and whether the file was recently dropped or compiled on the host. +- Reconstruct the surrounding process ancestry and user activity, including the originating shell, SSH or console session, working directory, and available history, to decide whether the sequence matches expected administration or interactive exploitation. +- Examine the root-context child’s immediate follow-on actions for signs of successful escalation, such as spawning an interactive shell, altering sudoers or setuid permissions, creating persistence, accessing credential stores, or initiating unexpected network connections. +- Correlate the event with evidence of local exploit staging on the host, including use of gcc or make, extracted proof-of-concept files, suspicious downloads, kernel or library versions associated with public LPEs, and related audit, dmesg, or crash messages. +- If the activity cannot be explained, collect volatile evidence and isolate the system while hunting across the environment for the same file hash, command pattern, writable-directory execution, or account activity on other Linux hosts. + + +*False positive analysis* + + +- An administrator or developer may intentionally run a locally built or staged privileged helper from `/tmp`, `/var/tmp`, `/run/user`, or a home directory during testing or maintenance, so verify the file is expected by checking ownership, setuid permissions, recent build or modification times, and whether the user had an approved task on the host. +- A legitimate installation, upgrade, or login-time setup task can unpack a temporary helper into a writable directory and then re-exec into a root context, so confirm benign activity by correlating the event with authorized change windows and local package or maintenance logs and ensuring the executable path and hash match the expected artifact. + + +*Response and remediation* + + +- Isolate the affected Linux host from the network while preserving EDR or console access, terminate the malicious parent and root child processes, and disable the user account, SSH session, or source IP used to launch the executable from the writable directory. +- Remove attacker footholds by deleting the dropped exploit and related files from `/tmp`, `/dev/shm`, `/var/tmp`, `/run/user`, or the user’s home directory, then revert unauthorized changes such as added `authorized_keys`, new sudoers entries, cron jobs, systemd services, modified shell startup files, and unexpected setuid or setgid permissions. +- If the root-level process altered system binaries, shared libraries, PAM files, kernel modules, or package-managed content, treat the host as fully compromised and restore it from a known-good image or backup instead of relying on in-place cleanup. +- Rotate credentials exposed on the host, including local passwords, SSH keys, API tokens, and service account secrets, because a successful root escalation can give the attacker access to authentication material and session data. +- Escalate immediately to incident response if the activity produced an interactive root shell, used a known local privilege escalation exploit, appeared on more than one Linux host, or was followed by lateral movement, credential collection, or data staging behavior. +- Harden the environment by patching the vulnerable kernel and userland packages, enforcing `noexec`, `nosuid`, and `nodev` on temporary writable mounts where practical, limiting who can compile or run untrusted code locally, and adding detections for execution from writable directories and unexpected new setuid files. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id with maxspan=15s + [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and + user.id != "0" and process.parent.user.id != "0" and process.parent.group.id != "0" and + ( + process.executable like (".*", "/tmp/*", "/dev/shm/*", "/var/tmp/*", "/run/user/*", "/var/run/user/*", "/home/*/*") or + process.parent.executable like (".*", "/tmp/*", "/dev/shm/*", "/var/tmp/*", "/home/*/*", "/run/user/*", "/var/run/user/*") + )] by process.entity_id + [process where host.os.type == "linux" and event.type == "change" and event.action == "uid_change" and + user.id == "0" and process.parent.user.id != "0" and process.parent.group.id != "0" and + not process.executable in ("/usr/bin/sudo", "/bin/sudo")] by process.parent.entity_id + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Setuid and Setgid +** ID: T1548.001 +** Reference URL: https://attack.mitre.org/techniques/T1548/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-potential-privilege-escalation-via-a-parent-process-sequence.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-potential-privilege-escalation-via-a-parent-process-sequence.asciidoc new file mode 100644 index 0000000000..c3c2af866e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-potential-privilege-escalation-via-a-parent-process-sequence.asciidoc @@ -0,0 +1,118 @@ +[[prebuilt-rule-8-19-27-potential-privilege-escalation-via-a-parent-process-sequence]] +=== Potential Privilege Escalation via a Parent Process Sequence + +Detects a potential privilege escalation sequence via a parent process relationship. This rule checks for non-root execution of a process executable in a user or world-writable directory followed by a UID change event to 0 (root). This sequence is indicative of a potential local privilege escalation exploit. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Data Source: Elastic Defend +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Privilege Escalation via a Parent Process Sequence* + + +This alert flags a Linux process chain where a non-root program launched from a user- or world-writable location is quickly followed by the same lineage switching to root, a strong sign of local privilege escalation and full host compromise risk. A common pattern is an attacker dropping or compiling an exploit in /tmp or a home directory, executing it as an unprivileged user, and then spawning a root shell or privileged helper within seconds. + + +*Possible investigation steps* + + +- Reconstruct the full process tree around the sequence to identify the originating user session, the exact binary or script launched from the writable location, and any immediate root-level child such as a shell, package tool, or file-modification utility. +- Validate whether the executed file and its parent are expected by reviewing file ownership, permissions, hashes, and recent write or compile times to determine if a malicious binary was dropped, replaced, or staged locally. +- Determine what the elevated process did next by examining follow-on root activity for signs of compromise such as interactive shells, edits to authentication files, SUID or capability changes, new services, cron jobs, or SSH key placement. +- Review nearby host telemetry for exploit preparation or execution indicators, including compiler usage, archive extraction, access to kernel or polkit-related components, suspicious temporary files, or errors and crashes consistent with privilege escalation attempts. +- Scope the incident by searching for the same user account, file hash, writable-path executable, or related lineage on other Linux systems, and contain the host quickly if the activity is not explained by approved administration or software deployment. + + +*False positive analysis* + + +- Administrators or developers may run locally built installers, update scripts, or test binaries from `/tmp`, `/var/tmp`, or a home directory that legitimately invoke a setuid-root helper during maintenance; verify the file is owned by the expected user, matches a known change window, and that the resulting root process only performed the intended configuration or install actions. +- User login or session initialization scripts stored under `/home/*` or `/run/user/*` can legitimately launch privileged built-in utilities such as password-change or mount helpers, creating a brief non-root-to-root process chain; confirm the alert coincides with an interactive user action and that the elevated child process is an expected system binary with benign follow-on activity. + + +*Response and remediation* + + +- Isolate the affected Linux host from the network immediately while keeping EDR and forensic access available so the attacker cannot use the new root context for lateral movement, data theft, or cleanup. +- Terminate the malicious process tree and quarantine or remove the exploit binary, script, or archive from the writable path it launched from, then delete attacker persistence such as new systemd services, cron entries, modified `rc.local`, added `authorized_keys`, altered `sudoers` files, and any unexpected SUID bits or Linux capabilities. +- Restore the host to a known-good state from a trusted image or snapshot instead of relying on in-place cleanup, and verify core system binaries, PAM modules, startup scripts, and package integrity before returning it to service. +- Rotate all credentials and secrets exposed on the host, including local passwords, SSH keys, API tokens, and service account secrets, because a root-level compromise may have allowed the attacker to read `/etc/shadow`, shell histories, application configs, and private keys. +- Escalate to incident response immediately if the root process spawned an interactive shell, modified `/etc/passwd` or `/etc/shadow`, installed a backdoor service, added an SSH key, or if the same user, binary hash, or writable-path execution pattern appears on more than one host. +- Harden the environment by patching the exploited local privilege escalation vector, restricting or removing unnecessary setuid/setcap helpers, mounting temporary and user-writable directories with `noexec,nosuid,nodev` where feasible, and increasing monitoring for executions from writable paths followed by privileged child activity. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id, process.parent.entity_id with maxspan=15s + [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and + user.id != "0" and process.parent.user.id != "0" and process.parent.group.id != "0" and + ( + process.executable like (".*", "/tmp/*", "/dev/shm/*", "/var/tmp/*", "/run/user/*", "/var/run/user/*", "/home/*/*") or + process.parent.executable like (".*", "/tmp/*", "/dev/shm/*", "/var/tmp/*", "/home/*/*", "/run/user/*", "/var/run/user/*") + )] + [process where host.os.type == "linux" and event.type == "change" and event.action == "uid_change" and + user.id == "0" and process.parent.user.id != "0" and process.parent.group.id != "0" and + not process.executable in ("/usr/bin/sudo", "/bin/sudo")] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Setuid and Setgid +** ID: T1548.001 +** Reference URL: https://attack.mitre.org/techniques/T1548/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-potential-privilege-escalation-via-a-suspicious-uid-change.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-potential-privilege-escalation-via-a-suspicious-uid-change.asciidoc new file mode 100644 index 0000000000..e4ceb8ed2a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-potential-privilege-escalation-via-a-suspicious-uid-change.asciidoc @@ -0,0 +1,118 @@ +[[prebuilt-rule-8-19-27-potential-privilege-escalation-via-a-suspicious-uid-change]] +=== Potential Privilege Escalation via a Suspicious UID Change + +Detects a potential privilege escalation sequence via a suspicious UID change sequence. This rule checks for non-root execution of a process executable in a user or world-writable directory followed by a UID change event to 0 (root). This sequence is indicative of a potential local privilege escalation exploit. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Data Source: Elastic Defend +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Privilege Escalation via a Suspicious UID Change* + + +This rule catches a Linux process launched by a non-root user from a user- or world-writable location that soon changes to run as root, a strong sign of local privilege escalation. Attackers often stage an exploit or wrapper in /tmp or /dev/shm, execute it as an ordinary user, and use a vulnerable setuid binary or kernel flaw to flip the process to UID 0 and gain full system control. + + +*Possible investigation steps* + + +- Reconstruct the full process ancestry and execution context around the UID transition to determine whether it originated from a user shell, script interpreter, scheduled task, container runtime, or another trusted administrative workflow. +- Inspect the executed file and nearby artifacts in the writable location for creation and modification times, ownership, permissions, package ownership, hashes, and evidence that the binary or script was recently dropped, replaced, or unpacked. +- Determine how root was obtained by identifying any vulnerable or misconfigured setuid or file-capability helper, writable library or search path abuse, environment variable manipulation, or host exposure to known local privilege escalation vulnerabilities. +- Review the same user’s and host’s surrounding activity for staging behavior such as downloads, compilation, archive extraction, permission changes, and repeated exploit attempts that can distinguish malicious escalation from benign testing or software installation. +- Assess post-escalation behavior by looking for root shells, changes to authentication or sudo configuration, persistence creation, security control tampering, sensitive file access, and new outbound network connections to scope impact and prioritize containment. + + +*False positive analysis* + + +- Developers or administrators may intentionally execute a custom setuid test binary or troubleshooting script from `/home`, `/tmp`, or `/dev/shm` during maintenance, so verify the file owner, creation time, and parent shell session match an authorized user and approved change window. +- A legitimate install, upgrade, or recovery workflow may unpack files into `/tmp`, `/var/tmp`, or `/run/user` and invoke a helper that transitions to UID 0, so confirm the executable and its parent process are expected for the host and coincide with documented software maintenance activity. + + +*Response and remediation* + + +- Isolate the affected Linux host from the network while keeping a controlled management channel, then stop the suspicious root process and any child shell or payload launched from writable paths such as `/tmp`, `/dev/shm`, `/var/tmp`, or a user home directory. +- Remove attacker persistence by deleting the dropped binary or script and reversing malicious changes such as new cron entries, systemd services or timers, modified shell startup files, unauthorized `authorized_keys` entries, unexpected setuid binaries, and altered `/etc/sudoers` or `/etc/passwd`. +- Preserve and review the malicious file and recent privileged changes across `/etc/shadow`, `/etc/sudoers`, `/root/.ssh/`, loaded kernel modules, and package contents, and escalate immediately to the incident response team if you find a new privileged account, outbound command-and-control traffic, or signs of access to other hosts. +- Restore the system to a known-good state by reimaging or replacing the host from a trusted baseline, reinstalling only verified software, and applying fixes for the vulnerable kernel, setuid helper, or misconfigured file capability that allowed the UID change. +- Reset credentials and secrets exposed on the host, including the affected user account, local service accounts, SSH keys, API tokens, and any cached credentials, then review adjacent systems for the same dropped files, persistence artifacts, or root-level changes. +- Harden the environment by removing unnecessary setuid programs and file capabilities, mounting writable directories with `nosuid` and `noexec` where feasible, tightening sudo access, and maintaining detections for execution from world-writable paths followed by a transition to UID 0. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id, process.entity_id with maxspan=30s + [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and + user.id != "0" and process.parent.user.id != "0" and process.parent.group.id != "0" and + ( + process.executable like (".*", "/tmp/*", "/dev/shm/*", "/var/tmp/*", "/home/*/*", "/run/user/*", "/var/run/user/*") or + process.parent.executable like (".*", "/tmp/*", "/dev/shm/*", "/var/tmp/*", "/home/*/*", "/run/user/*", "/var/run/user/*") + )] + [process where host.os.type == "linux" and event.type == "change" and event.action == "uid_change" and + user.id == "0" and process.parent.user.id != "0" and process.parent.group.id != "0" and + not process.executable in ("/usr/bin/sudo", "/bin/sudo")] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Setuid and Setgid +** ID: T1548.001 +** Reference URL: https://attack.mitre.org/techniques/T1548/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-potential-proxy-execution-via-systemd-run.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-potential-proxy-execution-via-systemd-run.asciidoc new file mode 100644 index 0000000000..c1582d7286 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-potential-proxy-execution-via-systemd-run.asciidoc @@ -0,0 +1,212 @@ +[[prebuilt-rule-8-19-27-potential-proxy-execution-via-systemd-run]] +=== Potential Proxy Execution via Systemd-run + +This rule detects the execution of a command or binary through the systemd-run binary. Systemd-run can schedule commands to be executed in the background through systemd. Attackers may use this technique to execute commands while attempting to evade detection. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-auditd_manager.auditd-* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Auditd Manager +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Proxy Execution via Systemd-run* + + +This alert fires when a Linux process launches another command through systemd-run instead of executing it directly, which can hide execution behind a trusted system utility and detach it into a transient service or scope. An attacker might use systemd-run --user or a transient unit to start a shell, downloader, or credential-harvesting script in the background from an interactive session, reducing visibility into the real payload and parent-child chain. + + +*Possible investigation steps* + + +- Reconstruct the full process tree around the event to determine which user, shell, script, service, or remote access session invoked systemd-run and whether the ancestry aligns with normal administrative or automation activity on that host. +- Review the exact command passed through systemd-run, including flags such as --user, --scope, scheduling options, or custom unit names, and classify the spawned payload as expected software management, benign interactive use, or suspicious shell, downloader, or persistence behavior. +- Query systemd and journal artifacts for the transient unit that was created, including unit properties, start time, execution account, service output, and whether the unit remained active, failed, or was configured to run again. +- Correlate the execution with nearby events from the same user or host such as logins, sudo activity, file creation in writable locations, outbound network connections, or follow-on launches of interpreters and admin tools to identify a broader intrusion sequence. +- If the activity is unauthorized or unclear, inspect the referenced binary or script for path reputation, package ownership, hash prevalence, and recent modification history, then stop the transient unit and contain any files or persistence it introduced. + + +*False positive analysis* + + +- A legitimate administrator or maintenance script may use `systemd-run` to launch a transient unit for package updates, cache rebuilds, or controlled service restarts, so verify the initiating user, the parent script or shell history, and nearby package-management or scheduled change activity. +- A normal desktop or user session can invoke `systemd-run --user` or `--scope` to start an application, terminal, or session task in a transient scope, so confirm the parent process belongs to the logged-in user’s graphical session and that the spawned command matches expected interactive activity in systemd or journal logs. + + +*Response and remediation* + + +- Isolate the affected Linux host from the network except for approved management channels, terminate the malicious `systemd-run` transient unit or scope, and kill any child shell, downloader, or script it launched. +- Remove attacker persistence by deleting unauthorized unit files and drop-ins from `/etc/systemd/system/`, `/run/systemd/transient/`, `/var/lib/systemd/`, and affected users’ `~/.config/systemd/user/` directories, then run `systemctl daemon-reload` and disable any malicious timers or services. +- Preserve and quarantine the executed payload, related scripts, and any files created from writable locations such as `/tmp`, `/var/tmp`, `/dev/shm`, or a user home directory, and revoke exposed access by resetting compromised passwords, SSH keys, tokens, and sudo access tied to the initiating account. +- Restore the system to a known-good state by reimaging or rebuilding the host from a trusted baseline if the command ran as `root`, modified security tooling, or executed an unknown binary, and validate that only approved packages, services, and startup entries remain before returning it to production. +- Escalate to incident response immediately if the `systemd-run` activity spawned a reverse shell, downloader, credential access tool, or lateral movement utility, if similar transient units appear on multiple hosts, or if the affected account has privileged or production access. +- Harden the environment by restricting who can invoke `systemd-run` through sudoers and privileged group membership, enforcing MFA and least privilege for administrative access, monitoring for new transient units and unexpected `--user` executions, and blocking execution from world-writable paths where the payload was staged. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Elastic Defend +- Auditbeat +- Auditd Manager +- CrowdStrike + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "executed", "process_started", "start", "ProcessRollup2") and +process.name == "systemd-run" and ?process.parent.executable != null and +not ( + ?process.parent.executable in ( + "/usr/lib/systemd", "/lib/systemd/systemd", "/opt/saltstack/salt/run/run", "/etc/update-motd.d/70-available-updates", + "/tmp/newroot/usr/libexec/ptyxis-agent", "/usr/local/sbin/clamscan.sh", "/opt/sentinelone/bin/sentinelone-agent", + "/usr/local/bin/salt-minion", "/var/vanta/launcher", "/opt/traps/bin/pmd", "/usr/sbin/gdm", "/usr/bin/salt-minion", + "/opt/GC_Ext/GC/gc_linux_service", "/usr/lib/plesk-task-manager", "/opt/forticlient/epctrl", "/usr/lib/snapd/snap-exec", + "/usr/bin/yay", "/usr/local/bin/hexnode_agent", "/opt/halcyon/halcyonar/agent", "/usr/local/bin/qsetup", "/usr/bin/pamac", + "/usr/bin/elephant", "/usr/bin/Hyprland" + ) or + ?process.parent.executable like ( + "/opt/tableau/tableau_server/packages/scripts.*/after-install", "/opt/acronis/bin/acp-update-controller", "/snap/*", + "/var/lib/amagent/*", "/opt/msp-agent/msp-agent-core", "/opt/beyondtrust/*", "/var/lib/rancher/k3s/*/bin/k3s" + ) or + ?process.parent.name like "platform-python*" or + ?process.parent.name in ( + "udevadm", "daemon.start", "snap", "systemd", "ptyxis-agent", "run-slack", "run-firefox", "dbus.service", "k3s-server", + "systemd-udevd", "kubelet", "hyperkube", "kthreadd", "gnome-shell", "xdg-desktop-portal", "firefox", "picus_updater", + "rpm-ostree", "prompt-agent" + ) or + ?process.command_line in ( + "/usr/bin/systemd-run /usr/bin/systemctl start man-db-cache-update", "systemd-run env", + "systemd-run --user dnf-automatic-notifyonly.timer", "systemd-run --user systemctl suspend", "systemd-run /var/lib/aws-replication-agent/uninstall-agent.sh", + "systemd-run --on-active=10 --timer-property=AccuracySec=100ms --slice=system.slice systemctl start gc-agent", + "systemd-run --user --scope --unit=tmux-server -- tmux", "systemd-run bash -c sleep 60 && reboot" + ) or + ?process.command_line like~ ( + "systemd-run --scope -p CPUQuota=10% rpm -qa*", "systemd-run --scope -p CPUQuota=10% dpkg -l*" + ) or + ?process.parent.command_line in ("runc init", "/usr/local/bin/main") or + ?process.parent.command_line like ("*/var/lib/waagent/*", "bash ./run.sh") or + process.args in ( + "--help", "list-timers", "/usr/lib/udev/kdump-udev-throttler", "kubectl", "--unit=ngt_guest_agent_upgrade", "i3-zoom", "google-chrome", + "thunar", "/usr/bin/google-chrome-stable", "snap.lxd.workaround", "--unit=firefox", "--unit=slack", "--slice=zoom.slice", + "autorandr-launcher", "--unit=restart-dbus", "--unit=autorandr-debounce" + ) or + process.args like ("--unit=app-Hyprland-wezterm-*.scope", "--unit=app-Hyprland-swaybg-*.scope", "--unit=rmf_sim_*") or + ?process.working_directory == "/opt/Tychon/Endpoint/bin" or + (process.args in ("rpm", "dpkg") and process.args like~ "CPUQuota=*") or + (process.args == "--slice=app-graphical.slice" and process.args == "--description=xdg-terminal-exec") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-potential-sql-injection-against-microsoft-sql-server.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-potential-sql-injection-against-microsoft-sql-server.asciidoc new file mode 100644 index 0000000000..8917a3bc40 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-potential-sql-injection-against-microsoft-sql-server.asciidoc @@ -0,0 +1,155 @@ +[[prebuilt-rule-8-19-27-potential-sql-injection-against-microsoft-sql-server]] +=== Potential SQL Injection Against Microsoft SQL Server + +Identifies potential SQL injection attempts against Microsoft SQL Server by detecting obfuscated T-SQL patterns in SQL Server Audit events. Attackers use CHAR concatenation, CONVERT-based subqueries, and CASE/UNION constructs to bypass input validation and extract data or execute unauthorized statements. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/sql/relational-databases/security/auditing/sql-server-audit-action-groups-and-actions +* https://owasp.org/www-community/attacks/SQL_Injection + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Initial Access +* Data Source: Windows Application Event Logs +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential SQL Injection Against Microsoft SQL Server* + + +Microsoft SQL Server can write audit records to the Windows Application log as event ID 33205 when SQL Server Audit is +enabled. Adversaries exploit SQL injection vulnerabilities in applications that query SQL Server, often using obfuscated +T-SQL such as CHAR concatenation or UNION-based payloads to evade simple signature checks. + + +*Possible investigation steps* + + +- Review `Esql.original_message` and `message` for the full audited statement, including the application name, client + address, database, and object targeted by the query. +- Identify the source application or service account associated with the audited session and determine whether it should + execute dynamic or user-supplied SQL against the affected database. +- Correlate with web server, application, or proxy logs around `@timestamp` to identify the HTTP request or client that + delivered the malicious input. +- Check for additional SQL Server Audit events (33205) from the same `host.id` or client address before and after the + alert for follow-on statements such as xp_cmdshell, credential access, or data exfiltration. +- Investigate other alerts on `host.id` during the past 48 hours for signs of post-exploitation or lateral movement. + + +*False positive analysis* + + +- Security scanners, penetration tests, or authorized application vulnerability assessments may generate matching audit + events. Confirm the activity aligns with an approved test window, source address, and application before closing as + benign. +- Custom applications that legitimately build dynamic SQL using CHAR concatenation are uncommon but possible. Review the + full statement context and application owner before adding exceptions. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- If exploitation is confirmed, isolate the affected SQL Server or application tier, block the source IP at the + perimeter, and preserve SQL Server Audit and application logs for forensic analysis. +- Patch or remediate the vulnerable application code path that allowed unsanitized input to reach SQL Server. +- Review SQL Server permissions for the compromised application account and restrict access to only required databases + and objects. +- Ensure SQL Server is not directly exposed to the internet and that SQL Server Audit remains enabled with appropriate + retention. + + +==== Setup + + + +*Setup* + + +SQL Server Audit must be configured to write audit events to the Windows Application log so that event ID 33205 is +generated by the MSSQLSERVER provider (or MSSQL$ for named instances). + +Setup instructions: https://learn.microsoft.com/en-us/sql/relational-databases/security/auditing/create-a-server-audit-and-server-audit-specification + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-system.application-*, logs-windows.forwarded*, winlogbeat-* metadata _id, _version, _index +| where host.os.type == "windows" and winlog.provider_name like "MSSQL*" and event.code == "33205" +| EVAL message_upper = TO_UPPER(message) +| where ( + message_upper RLIKE ".*CONVERT\\(INT,\\(SELECT (CHAR\\(\\d{1,3}\\)\\+){3,}.*" or + message_upper RLIKE ".*(CHAR\\(\\d{1,3}\\)\\+){3,}CHAR\\(\\d{1,3}\\).*" or + message_upper RLIKE ".*CASE WHEN \\(\\d+=\\d+\\).*UNION SELECT \\d+.*" or + message_upper RLIKE ".*WAITFOR DELAY \\'0:0:\\d+\\'.*" or + message_upper RLIKE ".*;\\s*(EXEC|EXECUTE)\\s*\\(?\\s*(MASTER\\.)?\\.?XP_CMDSHELL.*" or + message_upper RLIKE ".*UNION SELECT (NULL\\s*,\\s*){2,}NULL.*" or + message_upper RLIKE ".*'\\w*'\\s*\\+\\s*\\(\\(SELECT @@VERSION\\)\\)\\s*\\+\\s*'\\w*'.*" or + message_upper RLIKE ".*(OR|AND)\\s+'?\\d+'?\\s*=\\s*'?\\d+'?\\s*--.*" + ) +| eval Esql.original_message = message +| keep + @timestamp, + host.id, + host.name, + host.ip, + winlog.computer_name, + message, + event.outcome, + Esql.original_message, + _id, + _version, + _index, + data_stream.namespace + +| limit 10 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-potential-ssh-reverse-port-forwarding.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-potential-ssh-reverse-port-forwarding.asciidoc new file mode 100644 index 0000000000..cea0a40af0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-potential-ssh-reverse-port-forwarding.asciidoc @@ -0,0 +1,187 @@ +[[prebuilt-rule-8-19-27-potential-ssh-reverse-port-forwarding]] +=== Potential SSH Reverse Port Forwarding + +Identifies the use of Windows OpenSSH or Plink to create a reverse SSH port forward or reverse dynamic SOCKS proxy. Adversaries may abuse reverse forwarding to expose an internal service or proxy listener through an external SSH server, establishing an outbound tunnel that bypasses direct inbound connectivity controls. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://thedfirreport.com/2025/11/04/from-bing-search-to-ransomware-bumblebee-and-adaptixc2-deliver-akira-2/ +* https://thedfirreport.com/2023/10/30/netsupport-intrusion-results-in-domain-compromise/ +* https://x.com/Securityinbits/status/2067602540209021196 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Command and Control +* Tactic: Lateral Movement +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Windows Security Event Logs +* Data Source: Crowdstrike +* Data Source: Sysmon +* Data Source: Elastic Endgame +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential SSH Reverse Port Forwarding Detected* + + + +*Possible investigation steps* + + +- What reverse-forward command triggered the alert? + - Focus: `@timestamp`, `host.id`, `user.name`, `process.name`, `process.command_line` + - Implication: Confirm via !{investigate{"description":"Recover the process start event and immediate process context for the alerted OpenSSH or Plink reverse-forward command.","label":"Matched process context","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} a process start for `ssh.exe` or `plink.exe`/Plink with the matched `-R` or `RemoteForward` artifact. Suspicious when the command exposes an internal service or SOCKS listener without host/account owner confirmation; close only when command, host, account, parent, and remote-forward values match a recognized recurring tunnel workflow for this account. +- Is the process lineage and executable consistent with the expected workflow? + - Focus: `process.parent.command_line`, `process.executable`, `process.hash.sha256`, `process.working_directory`, `process.Ext.relative_file_creation_time` + - Implication: Via !{investigate{"description":"Recover the process start event and immediate process context for the alerted OpenSSH or Plink reverse-forward command.","label":"Matched process context","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}, compare parent, path, hash, and file age. Escalate when shells, script interpreters, unusual parents, recently created binaries, or a Plink original name under another process name appear; benign requires the same artifact and parent tied to the verified host/account reverse-forward workflow. +- Is the tunnel active or recurring on this host? + - Focus: `host.id`, `process.entity_id`, `process.pid`, `process.uptime`, `process.exit_code` + - Implication: Use !{investigate{"description":"Find other process events with the same alerted process name on the same host for local recurrence and parent/account comparison.","label":"Same host process launches","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.name","queryType":"phrase","value":"{{process.name}}","valueType":"string"}]],"relativeFrom":"now-24h","relativeTo":"now"}} to check whether the SSH/Plink process remained running, exited, or relaunched with reverse-forward arguments. Recurring or long-lived commands outside a confirmed window are suspicious; a single exited process supports closure only with owner confirmation and no unresolved process or network evidence. +- What remote SSH server and exposed service are implied? + - Focus: `process.args`, `process.command_line`, `destination.ip`, `destination.port`, `network.direction` + - Implication: Parse `-R`/`RemoteForward` syntax, then recover same-process connection events if network telemetry exists; `destination.*` and `network.*` are connection-event fields not present on the process alert. Missing network telemetry is unresolved, not benign. Escalate when the remote host, port, or exposed service does not match the confirmed workflow. +- Where else does the same binary or reverse-forward pattern appear? + - Focus: `process.hash.sha256`, `process.name`, `host.name`, `user.name`, `process.command_line` + - Implication: Use !{investigate{"description":"Find other events for the same executable hash to scope repeated use of the matched OpenSSH or Plink binary after local validation.","label":"Executable hash scope","providers":[[{"excluded":false,"field":"process.hash.sha256","queryType":"phrase","value":"{{process.hash.sha256}}","valueType":"string"}]],"relativeFrom":"now-7d","relativeTo":"now"}} to scope the same hash, comparing command lines for `-R`/`RemoteForward` on other hosts/accounts. Absence of matches is not benign; broaden containment when the artifact appears beyond the source host/account. Close recurrence only when each match ties to the same confirmed workflow. + +Disposition: Escalate suspicious or unresolved commands; close only when alert-local and recovered evidence confirm the exact host/account/process/remote-forward scope; preserve and escalate mixed cases. + + +*False positive analysis* + + +- Benign activity is limited to a confirmed reverse SSH forwarding workflow where `process.command_line`, `host.id`, `user.name`, parent process, executable, remote server, and forward port are verified. +- Do not close because the binary is named `ssh.exe`/`plink.exe`, has a familiar path, or a trusted signature — the matched command and owner workflow must explain the `-R`/`RemoteForward` artifact. +- Scope exceptions to `host.id`, `user.name`, `process.executable` or `process.hash.sha256`, `process.parent.executable` or `process.parent.command_line`, and the exact reverse-forward args. Do not suppress all reverse forwarding across hosts or accounts. + + +*Response and remediation* + + +- Scope first by reviewing the exact command, same-process network evidence, same executable hash, same user/host activity, and related alerts for the same remote SSH server or port before cleanup. +- Preserve or export case evidence plus volatile process, memory, executable, and file-system artifacts before isolation, process termination, or other disruptive action. +- After evidence capture, use reversible containment such as isolating the affected host or blocking egress to the confirmed SSH server/port while credential and session review proceeds. +- For confirmed malicious tunneling, terminate the SSH/Plink process, remove persistence or scripts that launched it, rotate exposed credentials, and clean staged binaries only after scoping. +- Record confirmed indicators and logging or detection gaps for the responsible detection or logging owners after containment. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + ( + process.name : ("ssh.exe", "plink.exe") or + ?process.pe.original_file_name : ("Plink", "plink.exe") + ) and + ( + process.args : "-R*" or + process.args : "-oRemoteForward*" or + (process.args : "-o" and process.args : "*RemoteForward*") or + + /* -R can be combined with ~20 no-arg SSH flags (e.g. -NR, -fNR) */ + process.command_line regex """.*\s-[A-Za-z]*R[^A-Za-z].*""" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Proxy +** ID: T1090 +** Reference URL: https://attack.mitre.org/techniques/T1090/ +* Sub-technique: +** Name: External Proxy +** ID: T1090.002 +** Reference URL: https://attack.mitre.org/techniques/T1090/002/ +* Technique: +** Name: Protocol Tunneling +** ID: T1572 +** Reference URL: https://attack.mitre.org/techniques/T1572/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: SSH +** ID: T1021.004 +** Reference URL: https://attack.mitre.org/techniques/T1021/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-privileges-elevation-via-parent-process-pid-spoofing.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-privileges-elevation-via-parent-process-pid-spoofing.asciidoc new file mode 100644 index 0000000000..a51552ce81 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-privileges-elevation-via-parent-process-pid-spoofing.asciidoc @@ -0,0 +1,199 @@ +[[prebuilt-rule-8-19-27-privileges-elevation-via-parent-process-pid-spoofing]] +=== Privileges Elevation via Parent Process PID Spoofing + +Identifies parent process spoofing used to create an elevated child process. Adversaries may spoof the parent process identifier (PPID) of a new process to evade process-monitoring defenses or to elevate privileges. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://gist.github.com/xpn/a057a26ec81e736518ee50848b9c2cd6 +* https://blog.didierstevens.com/2017/03/20/that-is-not-my-child-process/ +* https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-updateprocthreadattribute +* https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1134.002/T1134.002.md + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*Version*: 13 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Privileges Elevation via Parent Process PID Spoofing* + + + +*Possible investigation steps* + + +- Does the alert show a SYSTEM child with a spoofed parent relationship? + - Focus: `user.id`, token integrity, `process.parent.pid`, `process.parent.Ext.real.pid`, and `process.parent.executable`. + - Implication: escalate when a SYSTEM child has a nonzero real-creator PID that differs from the reported parent, especially when that parent gives trusted system, service, or desktop cover; treat a recognized broker or authorized test as only a candidate benign path until creator and child intent are checked. + - Why: PPID spoofing can make process-tree views show the selected parent instead of the process that requested creation. +- Which process actually requested the spoofed launch? + - Focus: recovered creator for `process.parent.Ext.real.pid`: `process.entity_id`, `process.executable`, `process.command_line`, signer, and trust state. + - Implication: escalate when the creator is unsigned, user-writable, a shell or script launcher, or unrelated to the reported parent; lower suspicion only for a stable signed vendor, update, accessibility, audit, or test component tied to the same workflow. + - Why: the Windows parent-process attribute can select a parent handle, so the recovered creator is the actor path the visible parent may hide. + - Hint: search the same `host.id` around `@timestamp` for `process.pid` = `process.parent.Ext.real.pid`; keep PID windows tight because PIDs are reused. !{investigate{"description":"","label":"Real creator process event","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.parent.Ext.real.pid}}","valueType":"string"}]],"relativeFrom":"now-15m","relativeTo":"now"}} +- Does the SYSTEM child identity and command line fit the recovered creator workflow? + - Focus: `process.executable`, `process.command_line`, `process.pe.original_file_name`, signer, and trust state. + - Implication: escalate when the child is a shell, script host, renamed binary, user-writable executable, unsigned or untrusted, or has commands that do not belong to the recovered creator; trusted signing reduces identity concern but does not clear PPID spoofing without launch-context fit. +- Did the spoofed SYSTEM child launch follow-on activity? + - Focus: child process events from `process.entity_id`, reviewing `process.executable`, `process.command_line`, and `user.id`. !{investigate{"description":"","label":"Descendant process events for the spoofed child","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when it spawns shells, scripting, credential, service, or lateral-movement tooling under SYSTEM; no descendants lowers immediate impact but does not clear a suspicious creator or child identity. + - Hint: if `process.entity_id` is unavailable, fall back to `host.id`, `process.pid`, and a tight alert-time window. +- If escalation is likely, what is the immediate scope? + - Focus: prior process alerts for `host.id` and `user.id` with matching child executable or hash, reported parent, and real-creator PID. + - !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: expand containment and scoping when the same child or creator appears on other hosts or unrelated users; keep scope local when the tuple is isolated and no descendant activity contradicts it. Do not use recurrence alone to close. + - Range: use a lookback that fits endpoint retention. + +Disposition: escalate when PPID spoofing to SYSTEM has an unrecognized creator, suspicious child, misleading parent, SYSTEM follow-on activity, or cross-host scope. Close only when alert and recovered telemetry tie the event to one exact recognized broker or authorized test and no descendant evidence contradicts it; preserve evidence and escalate when recovery is incomplete or evidence conflicts. + + +*False positive analysis* + + +- Signed broker cases require the exact telemetry tuple: child path, signer, and command; reported parent path; recovered creator path, signer, and command; and host/user cohort. Authorized PPID-spoofing tests require exact host, time, tester, test binary, parent PID, real creator PID, and child command line. Without that tie to one product or test, treat as suspicious because the rule already filters common Windows Error Reporting, update, accessibility, remote-support, and Netwrix patterns. +- Build exceptions only from the minimum confirmed tuple: `process.hash.sha256` or `process.code_signature.thumbprint_sha256`, `process.executable`, `process.parent.executable`, recovered creator identity, `host.id` or managed host group, and the test or product command pattern. Avoid exceptions on `process.name`, `process.parent.name`, or signer alone. + + +*Response and remediation* + + +- If confirmed benign: document the exact child, reported parent, real creator, signer, command line, host, and user evidence that proved the workflow; reverse any temporary containment and create only a narrow exception for the same tuple. +- If suspicious but unconfirmed: preserve the alert, process event, recovered creator and descendant process records, process entity IDs and PIDs, command lines, hashes, signers, and current process state before containment. Use reversible containment such as host isolation or temporary policy controls based on host criticality; avoid killing the child or creator until evidence is preserved. +- If confirmed malicious: isolate the affected host when identity, lineage, or descendant evidence shows unauthorized SYSTEM execution. Before termination, record `process.entity_id`, `process.parent.Ext.real.pid`, `process.command_line`, and `process.hash.sha256`; then terminate malicious child or descendant processes and remove only the binaries, scripts, services, or persistence found during follow-on investigation. +- Reset or rotate credentials only for accounts, services, or remote-access paths whose misuse is confirmed by additional evidence. Do not treat SYSTEM context alone as proof that a named user credential was compromised. +- Post-incident hardening: restrict administrative paths that can obtain parent-process creation privileges, review who can run PPID-spoofing test tools, and document the confirmed tuple or malicious artifact set so future analysts can separate repeated product behavior from repeated abuse. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +==== Rule query + + +[source, js] +---------------------------------- +/* This rule is compatible with Elastic Endpoint only */ + +process where host.os.type == "windows" and event.action == "start" and + + /* process creation via seclogon */ + process.parent.Ext.real.pid > 0 and process.parent.executable != null and + + /* PrivEsc to SYSTEM */ + user.id : "S-1-5-18" and + + /* Common FPs - evasion via hollowing is possible, should be covered by code injection */ + not process.executable : ("?:\\Windows\\System32\\WerFault.exe", + "?:\\Windows\\SysWOW64\\WerFault.exe", + "?:\\Windows\\System32\\WerFaultSecure.exe", + "?:\\Windows\\SysWOW64\\WerFaultSecure.exe", + "?:\\Windows\\System32\\Wermgr.exe", + "?:\\Windows\\SysWOW64\\Wermgr.exe", + "?:\\Windows\\SoftwareDistribution\\Download\\Install\\securityhealthsetup.exe") and + /* Logon Utilities */ + not (process.parent.executable : "?:\\Windows\\System32\\Utilman.exe" and + process.executable : ("?:\\Windows\\System32\\osk.exe", + "?:\\Windows\\System32\\Narrator.exe", + "?:\\Windows\\System32\\Magnify.exe", + "?:\\Windows\\System32\\VoiceAccess.exe")) and + + not process.parent.executable : "?:\\Windows\\System32\\AtBroker.exe" and + + not (process.code_signature.subject_name in + ("philandro Software GmbH", "Freedom Scientific Inc.", "TeamViewer Germany GmbH", "Projector.is, Inc.", + "TeamViewer GmbH", "Cisco WebEx LLC", "Dell Inc") and process.code_signature.trusted == true) and + + /* AM_Delta_Patch Windows Update */ + not (process.executable : ("?:\\Windows\\System32\\MpSigStub.exe", "?:\\Windows\\SysWOW64\\MpSigStub.exe") and + process.parent.executable : ("?:\\Windows\\System32\\wuauclt.exe", + "?:\\Windows\\SysWOW64\\wuauclt.exe", + "?:\\Windows\\UUS\\Packages\\Preview\\*\\wuaucltcore.exe", + "?:\\Windows\\UUS\\amd64\\wuauclt.exe", + "?:\\Windows\\UUS\\amd64\\wuaucltcore.exe", + "?:\\ProgramData\\Microsoft\\Windows\\UUS\\*\\wuaucltcore.exe")) and + + /* Other third party SW */ + not process.parent.executable : + ("?:\\Program Files (x86)\\HEAT Software\\HEAT Remote\\HEATRemoteServer.exe", + "?:\\Program Files (x86)\\VisualCron\\VisualCronService.exe", + "?:\\Program Files\\BinaryDefense\\Vision\\Agent\\bds-vision-agent-app.exe", + "?:\\Program Files\\Tablet\\Wacom\\WacomHost.exe", + "?:\\Program Files (x86)\\LogMeIn\\x64\\LogMeIn.exe", + "?:\\Program Files (x86)\\EMC Captiva\\Captiva Cloud Runtime\\Emc.Captiva.WebCaptureRunner.exe", + "?:\\Program Files\\Freedom Scientific\\*.exe", + "?:\\Program Files (x86)\\Google\\Chrome Remote Desktop\\*\\remoting_host.exe", + "?:\\Program Files (x86)\\GoToAssist Remote Support Customer\\*\\g2ax_comm_customer.exe") and + not ( + process.code_signature.trusted == true and process.code_signature.subject_name == "Netwrix Corporation" and + process.name : ("adcrcpy.exe", "addumpcaller.exe") and process.parent.name : ( + "Netwrix.ADA.EventCollector.exe", + "Netwrix.ADA.Analyzer.exe" + ) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Access Token Manipulation +** ID: T1134 +** Reference URL: https://attack.mitre.org/techniques/T1134/ +* Sub-technique: +** Name: Create Process with Token +** ID: T1134.002 +** Reference URL: https://attack.mitre.org/techniques/T1134/002/ +* Sub-technique: +** Name: Parent PID Spoofing +** ID: T1134.004 +** Reference URL: https://attack.mitre.org/techniques/T1134/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-protected-storage-service-access-via-smb.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-protected-storage-service-access-via-smb.asciidoc new file mode 100644 index 0000000000..48de0a6d23 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-protected-storage-service-access-via-smb.asciidoc @@ -0,0 +1,146 @@ +[[prebuilt-rule-8-19-27-protected-storage-service-access-via-smb]] +=== Protected Storage Service Access via SMB + +Identifies remote access to the Windows Protected Storage Service through the IPC$ share. Attackers may abuse this named pipe to interact with the Protected Storage Service and extract sensitive credentials, certificates, or DPAPI backup keys. + +*Rule type*: query + +*Rule indices*: + +* logs-system.security* +* logs-windows.forwarded* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://threathunterplaybook.com/hunts/windows/190620-DomainDPAPIBackupKeyExtraction/notebook.html +* https://www.elastic.co/security-labs/detect-credential-access + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Lateral Movement +* Resources: Investigation Guide +* Use Case: Active Directory Monitoring +* Data Source: Active Directory +* Data Source: Windows Security Event Logs + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Protected Storage Service Access via SMB* + + +The Protected Storage Service manages sensitive user data such as passwords, certificates, and private keys. Remote +access to the `protected_storage` named pipe over the IPC$ share is unusual and may indicate an attempt to extract +credentials or abuse DPAPI to retrieve domain backup keys from domain controllers. + + +*Possible investigation steps* + + +- Identify the source system and user account that initiated the access by reviewing `source.ip`, `user.name`, and + `winlog.event_data.SubjectUserName`. +- Determine whether the target host is a domain controller or other high-value system that stores DPAPI backup keys. +- Review authentication events (4624, 4625) around the alert time to identify how the source authenticated to the + target. +- Investigate other alerts associated with the source host or user during the past 48 hours. +- Check for follow-on credential access activity such as registry hive access, LSASS access, or lateral movement. + + +*False positive analysis* + + +- This activity is rarely expected in most environments. If legitimate administrative tooling accesses this pipe, + confirm the source, account, and target system before adding an exception. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the source host if unauthorized access is confirmed. +- Investigate credential exposure and reset passwords for potentially compromised accounts. +- Review domain controller DPAPI backup key exposure if the target is a domain controller. + + +==== Setup + + + +*Setup* + + +Audit Detailed File Share must be enabled to generate the events used by this rule. +Setup instructions: https://ela.st/audit-detailed-file-share + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:windows and event.category:file and event.code:5145 and + winlog.event_data.ShareName:"\\\\*\\IPC$" and + winlog.event_data.RelativeTargetName:"protected_storage" and + not source.ip:("::" or "::1" or "0.0.0.0" or "127.0.0.1") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Credentials from Password Stores +** ID: T1555 +** Reference URL: https://attack.mitre.org/techniques/T1555/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Private Keys +** ID: T1552.004 +** Reference URL: https://attack.mitre.org/techniques/T1552/004/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: SMB/Windows Admin Shares +** ID: T1021.002 +** Reference URL: https://attack.mitre.org/techniques/T1021/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-rdp-remote-desktop-protocol-from-the-internet.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-rdp-remote-desktop-protocol-from-the-internet.asciidoc new file mode 100644 index 0000000000..28020866d1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-rdp-remote-desktop-protocol-from-the-internet.asciidoc @@ -0,0 +1,179 @@ +[[prebuilt-rule-8-19-27-rdp-remote-desktop-protocol-from-the-internet]] +=== RDP (Remote Desktop Protocol) from the Internet + +This rule detects network events that may indicate the use of RDP traffic from the Internet. RDP is commonly used by system administrators to remotely control a system for maintenance or to use shared resources. 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. + +*Rule type*: query + +*Rule indices*: + +* logs-network_traffic.* +* logs-panw.panos* +* logs-pfsense.log-* +* logs-zeek.* +* logs-corelight.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml + +*Tags*: + +* Tactic: Command and Control +* Tactic: Lateral Movement +* Tactic: Initial Access +* Domain: Endpoint +* Use Case: Threat Detection +* Data Source: Corelight +* Data Source: PAN-OS +* Data Source: Network Traffic +* Data Source: pfSense +* Data Source: Zeek +* Resources: Investigation Guide + +*Version*: 112 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating RDP (Remote Desktop Protocol) from the Internet* + + +RDP allows administrators to remotely manage systems, but exposing it to the internet poses security risks. Adversaries exploit RDP for unauthorized access, often using it as an entry point for attacks. The detection rule identifies suspicious RDP traffic by monitoring TCP connections on port 3389 from external IPs, flagging potential threats for further investigation. + + +*Possible investigation steps* + + +- Review the source IP address flagged in the alert to determine if it is known or associated with any previous malicious activity. Check threat intelligence sources for any reported malicious behavior. +- Analyze the destination IP address to confirm it belongs to your internal network (10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16) and identify the specific system targeted by the RDP connection. +- Examine network logs for any unusual or unexpected RDP traffic patterns from the source IP, such as repeated connection attempts or connections at odd hours, which may indicate brute force attempts or unauthorized access. +- Check for any recent changes or updates to firewall rules or security policies that might have inadvertently exposed RDP to the internet. +- Investigate the user accounts involved in the RDP session to ensure they are legitimate and have not been compromised. Look for any signs of unauthorized access or privilege escalation. +- Correlate the RDP traffic with other security events or alerts to identify any potential lateral movement or further malicious activity within the network. + + +*False positive analysis* + + +- Internal testing or maintenance activities may trigger the rule if RDP is temporarily exposed to the internet. To manage this, create exceptions for known internal IP addresses or scheduled maintenance windows. +- Legitimate third-party vendors or partners accessing systems via RDP for support purposes can be mistaken for threats. Establish a list of trusted external IP addresses and exclude them from the rule. +- Misconfigured network devices or security tools might inadvertently expose RDP to the internet, leading to false positives. Regularly audit network configurations and update the rule to exclude known benign sources. +- Cloud-based services or remote work solutions that use RDP over the internet can be flagged. Identify and whitelist these services' IP ranges to prevent unnecessary alerts. + + +*Response and remediation* + + +- Immediately block the external IP address identified in the alert from accessing the network to prevent further unauthorized RDP connections. +- Isolate the affected system from the network to contain any potential compromise and prevent lateral movement by the threat actor. +- Conduct a thorough review of the affected system for signs of compromise, such as unauthorized user accounts, changes in system configurations, or the presence of malware. +- Reset credentials for any accounts that were accessed or potentially compromised during the incident to prevent unauthorized access. +- Apply security patches and updates to the affected system and any other systems with RDP enabled to mitigate known vulnerabilities. +- Implement network segmentation to restrict RDP access to only trusted internal IP addresses and consider using a VPN for secure remote access. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected. + +==== Rule query + + +[source, js] +---------------------------------- +(data_stream.dataset: network_traffic.flow or (event.category: (network or network_traffic))) and + network.transport:tcp and (destination.port:3389 or data_stream.dataset:zeek.rdp) and + not source.ip:( + 10.0.0.0/8 or + 127.0.0.0/8 or + 169.254.0.0/16 or + 172.16.0.0/12 or + 192.0.0.0/24 or + 192.0.0.0/29 or + 192.0.0.8/32 or + 192.0.0.9/32 or + 192.0.0.10/32 or + 192.0.0.170/32 or + 192.0.0.171/32 or + 192.0.2.0/24 or + 192.31.196.0/24 or + 192.52.193.0/24 or + 192.168.0.0/16 or + 192.88.99.0/24 or + 224.0.0.0/4 or + 100.64.0.0/10 or + 192.175.48.0/24 or + 198.18.0.0/15 or + 198.51.100.0/24 or + 203.0.113.0/24 or + 240.0.0.0/4 or + "::1" or + "FE80::/10" or + "FF00::/8" + ) and + destination.ip:( + 10.0.0.0/8 or + 172.16.0.0/12 or + 192.168.0.0/16 + ) and + not ( + data_stream.dataset:"panw.panos" and ( + event.action:("flow_dropped" or "flow_denied") or + network.application:("incomplete" or "insufficient-data" or "not-applicable") + ) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: Remote Desktop Protocol +** ID: T1021.001 +** Reference URL: https://attack.mitre.org/techniques/T1021/001/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: External Remote Services +** ID: T1133 +** Reference URL: https://attack.mitre.org/techniques/T1133/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-shared-object-load-via-lolbin.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-shared-object-load-via-lolbin.asciidoc new file mode 100644 index 0000000000..caa11d81df --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-shared-object-load-via-lolbin.asciidoc @@ -0,0 +1,194 @@ +[[prebuilt-rule-8-19-27-shared-object-load-via-lolbin]] +=== Shared Object Load via LoLBin + +This rule detects when a process not commonly used to load shared objects, is executed with arguments that load a shared object file. This technique can load a malicious shared object into memory while attempting to evade detection. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-auditd_manager.auditd-* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://gtfobins.github.io/#+library%20load + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Auditd Manager +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Shared Object Load via LoLBin* + + +This alert flags a Linux program that normally is not used as a loader but is started with options that pull a shared object into memory, a common way to hide malicious code behind trusted tools. An attacker can launch `openssl -engine /tmp/libcrypto.so` or a short `python -c` snippet that calls `cdll.LoadLibrary("/tmp/libx.so")` to execute a rogue library while blending in with legitimate system activity. + + +*Possible investigation steps* + + +- Review the full command line, ancestor process chain, session context, and executing user to determine whether the shared object load aligns with a legitimate admin task, build workflow, or expected plugin behavior. +- Identify the referenced `.so` file on disk and validate its package ownership, hash reputation, permissions, timestamps, and location, giving extra scrutiny to libraries in temporary, user-writable, hidden, or recently created paths. +- Pivot on the same library path or hash across hosts and users to determine whether it is isolated to one system, newly introduced, or part of a broader sequence involving script execution, file drops, or repeated LoLBin abuse. +- Examine activity immediately before and after the load for suspicious follow-on behavior such as outbound network connections, credential access attempts, unexpected child processes, privilege escalation, or persistence-related file changes. +- If the library is not attributable to approved software, collect the binary and related artifacts for static or sandbox analysis and consider host containment or blocking the file hash and path if corroborating malicious evidence is present. + + +*False positive analysis* + + +- Developers or build jobs may use `python -c`, `ruby -e`, or `openssl -engine` to validate a locally built `.so` during compilation or testing; confirm the parent process and working directory map to an expected build path or `make`-driven workflow and that the library resides in a project or package-managed location. +- Administrators may intentionally load a legitimate shell builtin or application plugin through `bash -c`, `gdb`, or `vim` while troubleshooting or enabling features; verify the session is interactive and attributable to the user, then check that the referenced `.so` is package-owned or stored in a standard system library or plugin directory rather than a writable temporary path. + + +*Response and remediation* + + +- Isolate the affected Linux host from the network, terminate the abusing LoLBin and any spawned processes, and quarantine the referenced `.so` and any copies found in writable locations such as `/tmp`, `/dev/shm`, user home directories, or hidden folders. +- Remove attacker persistence by deleting unauthorized entries from `/etc/ld.so.preload`, shell startup files, cron jobs, systemd services or timers, and any wrapper scripts that relaunch `openssl -engine`, `python -c`, `ruby -e`, or shell commands to load the malicious library. +- Reset credentials and revoke secrets used on the host, including SSH keys, API tokens, and service-account passwords, if the library executed under a privileged account or accessed authentication material, browser data, or configuration files with embedded secrets. +- Restore the host to a known-good state by rebuilding from a trusted image or reinstalling verified packages, then validate that no unapproved libraries, altered loader settings, or attacker-added binaries remain on disk before returning the system to production. +- Escalate to incident response immediately if the same library hash or path is present on multiple hosts, the load occurred as `root`, or the host showed follow-on behavior such as new persistence, remote command execution, or suspicious outbound network connections. +- Harden the environment by restricting plugin and engine loads to approved library directories, enforcing package integrity checks, monitoring for changes to preload files and service definitions, and applying SELinux or AppArmor policies that prevent scripts and LoLBins from loading shared objects from user-writable paths. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Elastic Defend +- Auditbeat +- Auditd Manager +- CrowdStrike + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "executed", "process_started", "start", "ProcessRollup2") and +?process.parent.executable != null and +( + (process.name == "bash" and process.args == "-c" and process.args like "* enable *-f*.so*") or + (process.name == "openssl" and process.args == "-engine" and process.args like "*.so*") or + (process.name like "python*" and process.args == "-c" and process.args like "*cdll.LoadLibrary*.so*") or + (process.name like "ruby*" and process.args == "-e" and process.args like "*Fiddle.dlopen*.so*") or + (process.name in ("gdb", "gimp", "rview", "rvim", "view", "vim", "vimdiff") and + process.args like "*cdll.LoadLibrary*.so*") or + (process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and + process.args == "-c" and process.args like ("*cdll.LoadLibrary*.so*", "*ruby*-e**Fiddle.dlopen*.so*") + ) +) and +not ( + ?process.parent.executable like ( + "/root/.cache/bazel/_bazel_root/install/*", "/opt/Xilinx/PetaLinux/*", "/usr/bin/find", "/bin/find", + "/opt/nessus_agent/sbin/nessus-agent-module", "/sw/eb/sw/Python/*/bin/python*" + ) or + ?process.parent.name in ("make", "process-wrapper", "bwrap") or + (process.name like "python*" and ?process.command_line like~ "*import torch*torchinductor*") or + ?process.command_line like "*https://github.com/community-scripts/ProxmoxVE/raw/main/LICENSE*" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-shell-execution-via-elastic-endpoint.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-shell-execution-via-elastic-endpoint.asciidoc new file mode 100644 index 0000000000..50f6b7d21e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-shell-execution-via-elastic-endpoint.asciidoc @@ -0,0 +1,123 @@ +[[prebuilt-rule-8-19-27-shell-execution-via-elastic-endpoint]] +=== Shell Execution via Elastic Endpoint + +This rule detects shell executions via Elastic Endpoint. Elastic Endpoint has a built-in response action console that can be used to execute shell commands on compromised systems. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Command and Control +* Tactic: Defense Evasion +* Tactic: Execution +* Data Source: Elastic Defend +* Data Source: SentinelOne + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start") and +process.parent.executable == "/opt/Elastic/Endpoint/elastic-endpoint" and +process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and +process.args in ("-c", "-cl", "-lc", "--command") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Remote Access Tools +** ID: T1219 +** Reference URL: https://attack.mitre.org/techniques/T1219/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-smb-windows-file-sharing-activity-from-the-internet.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-smb-windows-file-sharing-activity-from-the-internet.asciidoc new file mode 100644 index 0000000000..a9bc01f7f3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-smb-windows-file-sharing-activity-from-the-internet.asciidoc @@ -0,0 +1,168 @@ +[[prebuilt-rule-8-19-27-smb-windows-file-sharing-activity-from-the-internet]] +=== SMB (Windows File Sharing) Activity from the Internet + +This rule detects network events that may indicate inbound Windows file sharing (SMB or CIFS) traffic originating from the Internet. SMB should never be directly reachable from the Internet, as it is a primary target for exploitation by threat actors seeking initial access. Inbound SMB from a public IP is a direct precondition for attacks such as EternalBlue (MS17-010) and related SMB remote code execution vulnerabilities. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-corelight.* +* logs-network_traffic.* +* logs-panw.panos* +* logs-pfsense.log-* +* logs-zeek.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml +* https://msrc.microsoft.com/update-guide/vulnerability/CVE-2017-0144 + +*Tags*: + +* Tactic: Initial Access +* Domain: Network +* Use Case: Threat Detection +* Data Source: Corelight +* Data Source: PAN-OS +* Data Source: Network Traffic +* Data Source: pfSense +* Data Source: Zeek +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating SMB (Windows File Sharing) Activity from the Internet* + + +Inbound SMB from a public IP is one of the highest-signal perimeter events observable at a network boundary. SMB (ports 139/445) should never be reachable from the Internet. When it is, it is almost always either a deliberate exposure (misconfiguration) or active exploitation, both of which warrant investigation. Classic attacks in this category include EternalBlue (MS17-010), WannaCry, NotPetya, and subsequent SMB RCE chains. + +This rule uses `new_terms` to suppress repeat scans from the same source, surfacing only the first time each external IP reaches an internal host on SMB ports. + + +*Possible investigation steps* + + +- Identify the destination IP. Determine whether this host has a legitimate reason to expose SMB to the Internet (nearly always: no). Check whether the port was reachable externally due to a misconfigured NAT rule or security group. +- Review firewall allow/deny context alongside the alert. If the session was blocked, the immediate risk is lower, but the exposure is still worth addressing. +- Check the source IP against threat intelligence. Mass-Internet SMB scanning is common and source IPs are frequently tracked in public feeds. +- Correlate with endpoint telemetry on the destination host: look for process creation events, new services, or lateral movement activity that might indicate exploitation succeeded. +- Review patch status of the destination host for MS17-010 and subsequent SMB vulnerabilities. +- Check whether this external IP has been seen targeting other internal hosts or ports in the same timeframe, which would indicate a broader scan or intrusion campaign. + + +*False positive analysis* + + +- Hosts with public IPs that explicitly expose SMB (rare, but occurs in some lab or legacy setups): this is the intended detection; the exposure is itself the finding. Add a per-host exception only after confirming the exposure is authorized and risk-accepted. +- Site-to-site VPN or MPLS setups where a remote office segment routes through a public IP and appears as an external source: confirm with network architecture and add the IP range to the exclusion list if legitimate. + + +*Response and remediation* + + +- If the destination host is reachable from the Internet on port 139 or 445, immediately close the exposure at the firewall or security group level. This is the single most impactful remediation step. +- Isolate the destination host if any signs of compromise exist (unexpected processes, new scheduled tasks, lateral movement alerts). +- Patch the host for MS17-010 and related SMB vulnerabilities if not already current. +- Audit NAT and firewall rules to ensure no other hosts have inadvertent Internet-facing SMB exposure. +- Review the pfSense / network perimeter ruleset to confirm that inbound TCP 139/445 is explicitly denied at the border. + +This rule requires network flow or firewall log data that captures inbound TCP connections with 5-tuple information (source IP, destination IP, destination port). Compatible data sources include: + +- **Elastic Network Traffic** integration (Packetbeat) +- **Corelight** integration (network and SMB telemetry) +- **PAN-OS** integration (Palo Alto Networks firewall logs) +- **pfSense** integration (syslog-based firewall flow logs; requires pfSense syslog forwarding enabled) +- **Zeek** integration (SMB-specific log types: `smb_cmd`, `smb_files`, `smb_mapping`) + +For pfSense, ensure the firewall logging rules are configured to log connection events and that the Elastic pfSense integration is forwarding logs to the `logs-pfsense.log-*` data stream. + +==== Setup + + +This rule requires network flow or firewall log data that captures inbound TCP connections with 5-tuple information (source IP, destination IP, destination port). Compatible data sources include: + +Elastic Network Traffic integration (Packetbeat)Corelight integration (network and SMB telemetry)PAN-OS integration (Palo Alto Networks firewall logs)pfSense integration (syslog-based firewall flow logs; requires pfSense syslog forwarding enabled)Zeek integration (SMB-specific log types: `smb_cmd`, `smb_files`, `smb_mapping`) +For pfSense, ensure the firewall logging rules are configured to log connection events and that the Elastic pfSense integration is forwarding logs to the `logs-pfsense.log-*` data stream. + +==== Rule query + + +[source, js] +---------------------------------- +(data_stream.dataset:(network_traffic.flow or zeek.smb_cmd or zeek.smb_files or zeek.smb_mapping or pfsense.log) or event.category:(network or network_traffic)) + and network.transport:tcp and destination.port:(139 or 445) + and destination.ip:(10.0.0.0/8 or 172.16.0.0/12 or 192.168.0.0/16) + and not source.ip:( + 10.0.0.0/8 + or 100.64.0.0/10 + or 127.0.0.0/8 + or 169.254.0.0/16 + or 172.16.0.0/12 + or 192.0.0.0/24 + or 192.0.0.0/29 + or 192.0.0.10/32 + or 192.0.0.170/32 + or 192.0.0.171/32 + or 192.0.0.8/32 + or 192.0.0.9/32 + or 192.0.2.0/24 + or 192.168.0.0/16 + or 192.175.48.0/24 + or 192.31.196.0/24 + or 192.52.193.0/24 + or 192.88.99.0/24 + or 198.18.0.0/15 + or 198.51.100.0/24 + or 203.0.113.0/24 + or 224.0.0.0/4 + or 240.0.0.0/4 + or "::1" + or "FE80::/10" + or "FF00::/8" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: External Remote Services +** ID: T1133 +** Reference URL: https://attack.mitre.org/techniques/T1133/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-smtp-to-the-internet-on-port-26-tcp.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-smtp-to-the-internet-on-port-26-tcp.asciidoc new file mode 100644 index 0000000000..207144d039 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-smtp-to-the-internet-on-port-26-tcp.asciidoc @@ -0,0 +1,163 @@ +[[prebuilt-rule-8-19-27-smtp-to-the-internet-on-port-26-tcp]] +=== SMTP to the Internet on Port 26/TCP + +This rule detects events that may indicate use of SMTP on TCP port 26 from an internal host to an external destination. This port is commonly used by several popular mail transfer agents to deconflict with the default SMTP port 25. This port has also been used by a malware family called BadPatch for command and control of Windows systems. The rule is scoped to outbound traffic (internal source to external destination) to focus on the command and control and exfiltration use cases, rather than benign internal mail relays or unrelated transit traffic observed by the sensor. + +*Rule type*: query + +*Rule indices*: + +* logs-network_traffic.* +* logs-panw.panos* +* logs-pfsense.log-* +* logs-zeek.* +* logs-corelight.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://unit42.paloaltonetworks.com/unit42-badpatch/ +* https://isc.sans.edu/forums/diary/Next+up+whats+up+with+TCP+port+26/25564/ + +*Tags*: + +* Tactic: Command and Control +* Tactic: Exfiltration +* Domain: Endpoint +* Use Case: Threat Detection +* Data Source: Corelight +* Data Source: PAN-OS +* Data Source: Network Traffic +* Data Source: pfSense +* Data Source: Zeek +* Resources: Investigation Guide + +*Version*: 113 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating SMTP to the Internet on Port 26/TCP* + + +SMTP, typically operating on port 25, is crucial for email transmission. However, port 26 is often used to avoid conflicts or restrictions on port 25. Adversaries exploit this by using port 26 for covert command and control, as seen with the BadPatch malware. The detection rule identifies suspicious SMTP activity on port 26 originating from an internal host to an external destination, helping to uncover potential command and control or exfiltration while suppressing benign internal mail traffic. + + +*Possible investigation steps* + + +- Review the network traffic logs to identify any unusual patterns or anomalies associated with TCP port 26, focusing on the event.dataset fields such as network_traffic.flow or zeek.smtp. +- Analyze the source and destination IP addresses involved in the alert to determine if they are known or associated with any previous suspicious activities. +- Check for any additional alerts or logs related to the same source or destination IP addresses to identify potential patterns or repeated attempts of communication on port 26. +- Investigate the context of the communication by examining the payload data, if available, to identify any indicators of compromise or malicious content. +- Correlate the findings with threat intelligence sources to determine if the IP addresses or domains are associated with known threat actors or malware, such as BadPatch. +- Assess the risk and impact on the affected systems by determining if any sensitive data or critical systems are involved in the communication on port 26. + + +*False positive analysis* + + +- Legitimate mail transfer agents may use port 26 to avoid conflicts with port 25. Identify these agents and create exceptions in the detection rule to prevent unnecessary alerts. +- Some network configurations might reroute SMTP traffic to port 26 for load balancing or security reasons. Verify these configurations and whitelist known IP addresses or domains to reduce false positives. +- Internal testing or development environments might use port 26 for non-malicious purposes. Document these environments and exclude their traffic from triggering alerts. +- Certain email service providers may use port 26 as an alternative to port 25. Confirm these providers and adjust the rule to recognize their traffic as benign. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further command and control communication via port 26. +- Conduct a thorough scan of the isolated system using updated antivirus and anti-malware tools to identify and remove the BadPatch malware or any other malicious software. +- Review and analyze network logs to identify any other systems that may have communicated with the same command and control server, and isolate those systems as well. +- Change all passwords and credentials that may have been compromised or accessed by the affected system to prevent unauthorized access. +- Apply security patches and updates to the affected system and any other vulnerable systems to mitigate exploitation by similar threats. +- Monitor network traffic for any further suspicious activity on port 26 and other non-standard ports, adjusting firewall rules to block unauthorized SMTP traffic. +- Escalate the incident to the security operations center (SOC) or relevant cybersecurity team for further investigation and to ensure comprehensive threat eradication. + +==== Rule query + + +[source, js] +---------------------------------- +(data_stream.dataset: (network_traffic.flow or zeek.smtp) or event.category:(network or network_traffic)) and + network.transport:tcp and destination.port:26 and + source.ip:(10.0.0.0/8 or 172.16.0.0/12 or 192.168.0.0/16) and + not destination.ip:(10.0.0.0/8 + or 100.64.0.0/10 + or 127.0.0.0/8 + or 169.254.0.0/16 + or 172.16.0.0/12 + or 192.0.0.0/24 + or 192.0.0.0/29 + or 192.0.0.10/32 + or 192.0.0.170/32 + or 192.0.0.171/32 + or 192.0.0.8/32 + or 192.0.0.9/32 + or 192.0.2.0/24 + or 192.168.0.0/16 + or 192.175.48.0/24 + or 192.31.196.0/24 + or 192.52.193.0/24 + or 192.88.99.0/24 + or 198.18.0.0/15 + or 198.51.100.0/24 + or 203.0.113.0/24 + or 224.0.0.0/4 + or 240.0.0.0/4 + or "::1" + or "FE80::/10" + or "FF00::/8") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Sub-technique: +** Name: Mail Protocols +** ID: T1071.003 +** Reference URL: https://attack.mitre.org/techniques/T1071/003/ +* Technique: +** Name: Non-Standard Port +** ID: T1571 +** Reference URL: https://attack.mitre.org/techniques/T1571/ +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Exfiltration Over Alternative Protocol +** ID: T1048 +** Reference URL: https://attack.mitre.org/techniques/T1048/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-splunk-enterprise-postgresql-backup-to-restore-potential-rce-sequence.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-splunk-enterprise-postgresql-backup-to-restore-potential-rce-sequence.asciidoc new file mode 100644 index 0000000000..5819973bd7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-splunk-enterprise-postgresql-backup-to-restore-potential-rce-sequence.asciidoc @@ -0,0 +1,178 @@ +[[prebuilt-rule-8-19-27-splunk-enterprise-postgresql-backup-to-restore-potential-rce-sequence]] +=== Splunk Enterprise PostgreSQL Backup-to-Restore Potential RCE Sequence + +Detects a POST to the Splunk Enterprise PostgreSQL backup endpoint followed by a POST to the restore endpoint from the same client to the same host within a 15-minute window. This sequence is unusual and can align with the public CVE-2026-20253 pre-authentication RCE chain, where an attacker stages a database dump via the backup path and executes attacker-controlled SQL via the restore path. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-19m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 5 + +*References*: + +* https://nvd.nist.gov/vuln/detail/CVE-2026-20253 +* https://advisory.splunk.com/advisories/SVD-2026-0603 +* https://labs.watchtowr.com/why-use-app-level-auth-when-every-database-has-auth-splunk-enterprise-cve-2026-20253-pre-auth-rce/ +* https://attack.mitre.org/techniques/T1190/ + +*Tags*: + +* Domain: Network +* Use Case: Threat Detection +* Use Case: Vulnerability +* Use Case: Network Security Monitoring +* Tactic: Initial Access +* Data Source: Network Packet Capture +* Data Source: Network Traffic +* Data Source: Zeek +* Data Source: Suricata +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Splunk Enterprise PostgreSQL Backup-to-Restore Potential RCE Sequence* + + +This rule fires when the same source IP sends a POST to both the `/backup` and `/restore` recovery +endpoints on the same Splunk host within 15 minutes. This two-step sequence is unusual and aligns with +the watchTowr CVE-2026-20253 RCE chain: the backup request can place an attacker-controlled +PostgreSQL dump on the Splunk filesystem (using `backupFile` path traversal or absolute path +injection), and the restore request can load that dump and execute attacker-controlled SQL through the +local PostgreSQL instance. A backup-plus-restore pair from an unrecognized source IP on a production +Splunk host should be investigated as potential exploitation. + + +*Possible investigation steps* + + +- Review `http.response.status_code` for both requests. A `400` on the backup step indicates the + sidecar handler was reached (the request parsed but failed), consistent with a vulnerable host. +- Check whether the backup request body (if captured by a WAF or proxy) contains `hostaddr=`, + `host=`, or `passfile=` in the `database` field, or path traversal (`../`) or absolute paths + in the `backupFile` field. These are the connection-string injection and file-placement artifacts + specific to this exploit chain. +- Correlate with host telemetry on the Splunk server: look for new or modified files under + `/opt/splunk/etc/apps/`, `/opt/splunk/var/packages/`, or `/tmp/` around the time of the requests. +- Check for Splunk process execution of `pg_dump` or `pg_restore` with unusual arguments, + particularly connection strings containing external hostnames or IP addresses. +- Check for outbound network connections from the Splunk host to external PostgreSQL services + (port 5432 or similar) following the backup request — this indicates successful connection-string + injection causing the server to pivot to an attacker-controlled database. +- Verify whether the target Splunk host is running an affected version (10.0.0–10.0.6 or + 10.2.0–10.2.3). Splunk Enterprise 10.4 and Splunk Cloud are not affected. + + +*False positive analysis* + + +- Authorized administrative recovery operations using the sidecar API. These should originate from + known management IPs; create exceptions for approved management network ranges. +- Red-team or vulnerability management tooling that runs a full backup-to-restore probe as part of + a CVE-2026-20253 exposure check. + + +*Response and remediation* + + +- Treat a confirmed backup-and-restore sequence from an unrecognized source as active exploitation. + Isolate the Splunk host from the network immediately and preserve forensic state. +- Examine the Splunk host for new or modified files, scheduled tasks, and PostgreSQL extension + objects that may have been placed by the restore step. +- Patch Splunk Enterprise to an unaffected version (SVD-2026-0603). There is no vendor-provided + workaround; patching is the only mitigation. +- Block Splunk Web port (default 8000) at the perimeter and restrict access to management networks + while patching is in progress. + + +==== Setup + + + +*Setup* + + +This rule requires HTTP request metadata with `url.path` and `http.request.method` populated from +one of the following sources visible to the sensor without TLS decryption: +- Zeek (`logs-zeek.http*`) where Splunk Web traffic is cleartext or the sensor is downstream of TLS + termination. +- Suricata (`logs-suricata.eve*`) in the same deployment conditions +- Elastic Agent `network_traffic` integration (`logs-network_traffic.http*`) with HTTP parsing enabled + +Splunk Web listens on TCP port 8000 by default (`web.conf` `httpport`), which is included in the +default Network Packet Capture/Packetbeat HTTP port list. Add any custom Splunk Web `httpport` value +to the HTTP protocol configuration. Splunk's management service defaults to TCP port 8089 +(`mgmtHostPort`) and commonly uses TLS; add 8089 only if management/API traffic is directly exposed or +visible to the sensor after decryption. If the PostgreSQL sidecar is directly exposed or monitored +locally on TCP port 5435, add port 5435 as an HTTP port as well. Zeek and Suricata can identify +plaintext HTTP on non-standard ports through protocol detection when their HTTP analyzers are enabled. +For TLS deployments, the sensor must observe decrypted HTTP, sit downstream of TLS termination, or use +proxy or load balancer logs that expose the HTTP path, method, and status code. + +The rule uses a 19-minute lookback and verifies that the first and last matching recovery events are +no more than 15 minutes apart. Ensure `event.ingested` is populated and `timestamp_override` is set. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-network_traffic.http*, logs-zeek.http*, logs-suricata.eve* +| where http.request.method == "POST" + and ( + url.path like "*splunkd/__raw/v1/postgres/recovery/*" or + url.path like "/v1/postgres/recovery/*" + ) +| eval Esql.is_backup = case(url.path like "*/backup", 1, 0) +| eval Esql.is_restore = case(url.path like "*/restore", 1, 0) +| stats + Esql.backup_count = SUM(Esql.is_backup), + Esql.restore_count = SUM(Esql.is_restore), + Esql.first_seen = MIN(@timestamp), + Esql.last_seen = MAX(@timestamp), + Esql.statuses = VALUES(http.response.status_code) + by source.ip, destination.ip +| eval Esql.duration_minutes = DATE_DIFF("minute", Esql.first_seen, Esql.last_seen) +| where Esql.backup_count >= 1 and Esql.restore_count >= 1 + and Esql.duration_minutes <= 15 +| keep source.ip, destination.ip, Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-splunk-enterprise-postgresql-recovery-endpoint-injection-artifacts.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-splunk-enterprise-postgresql-recovery-endpoint-injection-artifacts.asciidoc new file mode 100644 index 0000000000..89aa377d31 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-splunk-enterprise-postgresql-recovery-endpoint-injection-artifacts.asciidoc @@ -0,0 +1,232 @@ +[[prebuilt-rule-8-19-27-splunk-enterprise-postgresql-recovery-endpoint-injection-artifacts]] +=== Splunk Enterprise PostgreSQL Recovery Endpoint Injection Artifacts + +Detects CVE-2026-20253 exploit artifacts against the Splunk Enterprise PostgreSQL sidecar recovery endpoints via complementary signals. Where endpoint or Network Packet Capture request-body logging is available, the rule matches PostgreSQL connection-string injection keywords, suspicious `backupFile` destinations, and known filesystem artifacts used to pivot from backup/restore primitives to file write or RCE. It also detects vulnerable recovery endpoint probing and empty-password Basic auth credentials observed in public exploit tooling. + +*Rule type*: query + +*Rule indices*: + +* logs-endpoint.events.network* +* logs-network_traffic.http* +* logs-zeek.http* +* logs-suricata.eve* +* logs-azure.application_gateway* +* logs-gcp.loadbalancing_logs* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://nvd.nist.gov/vuln/detail/CVE-2026-20253 +* https://advisory.splunk.com/advisories/SVD-2026-0603 +* https://labs.watchtowr.com/why-use-app-level-auth-when-every-database-has-auth-splunk-enterprise-cve-2026-20253-pre-auth-rce/ +* https://attack.mitre.org/techniques/T1190/ + +*Tags*: + +* Domain: Network +* Use Case: Threat Detection +* Use Case: Vulnerability +* Use Case: Network Security Monitoring +* Tactic: Initial Access +* Data Source: Azure +* Data Source: Elastic Defend +* Data Source: GCP +* Data Source: Google Cloud Platform +* Data Source: Network Packet Capture +* Data Source: Network Traffic +* Data Source: Zeek +* Data Source: Suricata +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Splunk Enterprise PostgreSQL Recovery Endpoint Injection Artifacts* + + +This rule fires on distinct signals from the CVE-2026-20253 exploit chain and closely related recovery endpoint abuse: + +**Body injection** (endpoint/WAF/proxy sources): A POST to the recovery endpoints with a body +containing PostgreSQL connection-string keywords (`hostaddr=`, `host=`, `port=`, `passfile=`, +`dbname=`, `user=`, `password=`, `sslmode=`, or `service=`), `backupFile` path traversal, suspicious +absolute destinations (`/tmp/`, `/var/tmp/`, `/dev/shm/`, `/opt/splunk/etc/apps/`, cron paths, or SSH +authorized keys), or known filesystem artifacts (`.pgpass`, `/opt/splunk/etc/apps/`). The `database` +JSON field is passed directly to `pg_dump` or `pg_restore` as a connection string, so +attacker-supplied keywords override the hardcoded local configuration. The `backupFile` parameter +controls the dump file path, enabling arbitrary file placement. + +**Auth credential artifact** (Zeek sources): A POST to the recovery endpoints with an empty password +in the HTTP Basic auth header (`url.password : ""`). The exploit passes the Basic auth username +directly to `pg_dump` or `pg_restore` as a PostgreSQL username — any value works, so this branch does +not filter on specific usernames. + +**Vulnerable endpoint probing**: A POST to `/v1/postgres/recovery/backup` or +`/v1/postgres/recovery/restore` returning HTTP 400. Public probes use this response distinction because +vulnerable handlers parse the request and return 400, while patched or protected paths return 401. + + +*Possible investigation steps* + + +- Check `http.response.status_code`. A `400` indicates the request reached the vulnerable sidecar + handler; a `401` indicates access was blocked or the host is patched. A `400` on the backup or + restore path is consistent with probing, and a `400` with injection content in the body is a + high-confidence indicator of active exploitation. +- Identify which injection artifact triggered the rule: + - `hostaddr=` or `host=` in `database` → server-side database pivot; check for outbound connections + from the Splunk host to port 5432 or the attacker-supplied `port=` value. + - `port=`, `user=`, `password=`, `sslmode=`, or `service=` in `database` → generic libpq connection + string smuggling; review the full body for remote database or credential manipulation. + - `passfile=/opt/splunk/var/packages/data/postgres/.pgpass` → local PostgreSQL credential reuse; + this exact string is the public restore-chain artifact from watchTowr. + - `backupFile` with `../` traversal or suspicious absolute paths (`/tmp/`, `/var/tmp/`, `/dev/shm/`, + `/opt/splunk/etc/apps/`, cron paths, or SSH authorized keys) → arbitrary file placement; check for + new or modified files at those paths. + - `dbname=template1` with `passfile=` → the published two-stage restore payload. +- Correlate with host telemetry: new files under `/opt/splunk/etc/apps/`, `/opt/splunk/var/packages/`, + or `/tmp/` created around the request time. +- Check for outbound PostgreSQL connections from the Splunk host following any `hostaddr=` or `host=` + injection (see companion rule "Splunk Enterprise PostgreSQL Backup-to-Restore Potential RCE Sequence"). +- Verify whether the target Splunk host is running an affected version (10.0.0-10.0.6 or + 10.2.0-10.2.3). Splunk Enterprise 10.4 and Splunk Cloud are not affected. + + +*False positive analysis* + + +- No legitimate Splunk user workflow sends PostgreSQL connection-string keywords or filesystem paths + to these recovery endpoints. This rule has very low false positive potential when the path filter + is in scope. + + +*Response and remediation* + + +- Any confirmed body injection on the recovery endpoints should be treated as active exploitation. + Isolate the Splunk host immediately and preserve forensic state. +- Check for files placed by `backupFile` traversal and SQL objects loaded by the restore step. +- Patch Splunk Enterprise to an unaffected version. There is no vendor-provided workaround for + CVE-2026-20253. + + +==== Setup + + + +*Setup* + + +This rule covers two detection paths with different telemetry requirements: + +**Body injection branch** (`http.request.body.content`): Populated by: +- Elastic Defend (`logs-endpoint.events.network*`) on the Splunk host, capturing HTTP network + events at the endpoint level +- Network Packet Capture (`logs-network_traffic.http*`) with HTTP body capture enabled for the + Splunk recovery paths + +Avoid enabling broad request-body logging without masking or filtering — bodies can contain +credentials and PII. Scope capture to specific URL paths (e.g., `*/splunkd/*`) where possible. + +**Auth artifact branch** (`url.password`, `url.username`): Populated by: +- Zeek (`logs-zeek.http*`) - parses HTTP Basic auth headers natively, no additional configuration + +**Vulnerable endpoint probing branch** (`http.response.status_code`): Populated by Network Packet +Capture, Zeek, Suricata, Azure Application Gateway, and GCP Load Balancing where HTTP response +metadata is visible to the sensor. + +Splunk Web listens on TCP port 8000 by default (`web.conf` `httpport`), which is included in the +default Network Packet Capture/Packetbeat HTTP port list. Add any custom Splunk Web `httpport` value +to the HTTP protocol configuration. Splunk's management service defaults to TCP port 8089 +(`mgmtHostPort`) and commonly uses TLS; add 8089 only if management/API traffic is directly exposed or +visible to the sensor after decryption. If the PostgreSQL sidecar is directly exposed or monitored +locally on TCP port 5435, add port 5435 as an HTTP port as well. Zeek and Suricata can identify +plaintext HTTP on non-standard ports through protocol detection when their HTTP analyzers are enabled. +For TLS deployments, the sensor must observe decrypted HTTP, sit downstream of TLS termination, or use +proxy or load balancer logs that expose the HTTP path, method, and status code. Body-content detection +still requires request-body capture for the Splunk recovery paths. + +Use the companion rule "Splunk Enterprise PostgreSQL Backup-to-Restore Potential RCE Sequence" for detections that work without +request-body capture or auth header logging. + + +==== Rule query + + +[source, js] +---------------------------------- +http.request.method:POST and +url.path:("*splunkd/__raw/v1/postgres/recovery/*" or "/v1/postgres/recovery/*") and +( + http.request.body.content:( + "*\"backupFile\"*../*" or + "*\"backupFile\"*/dev/shm/*" or + "*\"backupFile\"*/etc/cron*" or + "*\"backupFile\"*/home/*/.ssh/*" or + "*\"backupFile\"*/opt/splunk/bin/scripts/*" or + "*\"backupFile\"*/opt/splunk/etc/apps/*" or + "*\"backupFile\"*/root/*" or + "*\"backupFile\"*/tmp/*" or + "*\"backupFile\"*/var/tmp/*" or + "*\"backupFile\"*authorized_keys*" or + "*\"database\"*dbname=*" or + "*\"database\"*host=*" or + "*\"database\"*hostaddr=*" or + "*\"database\"*passfile=*" or + "*\"database\"*password=*" or + "*\"database\"*port=*" or + "*\"database\"*service=*" or + "*\"database\"*sslmode=*" or + "*\"database\"*user=*" or + "*/opt/splunk/etc/apps/*" or + "*/opt/splunk/var/packages/data/postgres/.pgpass*" + ) or + data_stream.dataset:zeek.http and url.password:"" or + data_stream.dataset:(azure.application_gateway or gcp.loadbalancing_logs or network_traffic.http or suricata.eve or zeek.http) and + url.path:( + "*splunkd/__raw/v1/postgres/recovery/backup" or + "*splunkd/__raw/v1/postgres/recovery/restore" or + /v1/postgres/recovery/backup or + /v1/postgres/recovery/restore + ) and + http.response.status_code:400 +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-suspicious-child-execution-via-web-server.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-suspicious-child-execution-via-web-server.asciidoc new file mode 100644 index 0000000000..11b621dcf9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-suspicious-child-execution-via-web-server.asciidoc @@ -0,0 +1,328 @@ +[[prebuilt-rule-8-19-27-suspicious-child-execution-via-web-server]] +=== Suspicious Child Execution via Web Server + +Identifies suspicious child processes executed via a web server, which may suggest a vulnerability and remote shell access. Attackers may exploit a vulnerability in a web application to execute commands via a web server, or place a backdoor file that can be abused to gain code execution as a mechanism for persistence. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://pentestlab.blog/tag/web-shell/ +* https://www.elastic.co/security-labs/elastic-response-to-the-the-spring4shell-vulnerability-cve-2022-22965 + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Initial Access +* Use Case: Vulnerability +* Resources: Investigation Guide +* Data Source: Elastic Defend + +*Version*: 116 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suspicious Child Execution via Web Server* + + +Adversaries may backdoor web servers with web shells to establish persistent access to systems. A web shell is a malicious script, often embedded into a compromised web server, that grants an attacker remote access and control over the server. This enables the execution of arbitrary commands, data exfiltration, and further exploitation of the target network. + +This rule detects a web server process spawning script and command line interface programs, potentially indicating attackers executing commands using the web shell. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. + + +*Possible investigation steps* + + +- Investigate abnormal behaviors by the subject process such as network connections, file modifications, and any other spawned child processes. + - Investigate listening ports and open sockets to look for potential reverse shells or data exfiltration. + - !{osquery{"label":"Osquery - Retrieve Listening Ports","query":"SELECT pid, address, port, socket, protocol, path FROM listening_ports"}} + - !{osquery{"label":"Osquery - Retrieve Open Sockets","query":"SELECT pid, family, remote_address, remote_port, socket, state FROM process_open_sockets"}} + - Investigate the process information for malicious or uncommon processes/process trees. + - !{osquery{"label":"Osquery - Retrieve Process Info","query":"SELECT name, cmdline, parent, path, uid FROM processes"}} + - Investigate the process tree spawned from the user that is used to run the web application service. A user that is running a web application should not spawn other child processes. + - !{osquery{"label":"Osquery - Retrieve Process Info for Webapp User","query":"SELECT name, cmdline, parent, path, uid FROM processes WHERE uid = {{process.user.id}}"}} +- Examine the command line to determine which commands or scripts were executed. +- Investigate other alerts associated with the user/host during the past 48 hours. +- If scripts or executables were dropped, retrieve the files and determine if they are malicious: + - Use a private sandboxed malware analysis system to perform analysis. + - Observe and collect information about the following activities: + - Attempts to contact external domains and addresses. + - Check if the domain is newly registered or unexpected. + - Check the reputation of the domain or IP address. + - File access, modification, and creation activities. + - Cron jobs, services and other persistence mechanisms. + - !{osquery{"label":"Osquery - Retrieve Crontab Information","query":"SELECT * FROM crontab"}} + + +*False positive analysis* + + +- This activity is unlikely to happen legitimately. Any activity that triggered the alert and is not inherently malicious must be monitored by the security team. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and ( + process.parent.name in ( + "nginx", "apache2", "httpd", "caddy", "mongrel_rails", "uwsgi", "daphne", "httpd.worker", "flask", + "php-cgi", "php-fcgi", "php-cgi.cagefs", "lswsctrl", "varnishd", "uvicorn", "waitress-serve", "starman", + "frankenphp", "zabbix_server", "asterisk", "sw-engine-fpm" + ) or + process.parent.name like ("php-fpm*", "gunicorn*", "*.cgi", "*.fcgi") or + ( + process.parent.name like "ruby*" and + process.parent.command_line like~ ("*puma*", "*rails*", "*passenger*") + ) or + ( + process.parent.name like "python*" and + process.parent.command_line like~ ( + "*hypercorn*", "*flask*", "*uvicorn*", "*django*", "*app.py*", "*server.py*", "*wsgi.py*", "*asgi.py*" + ) + ) or + (process.parent.name like "perl*" and process.parent.command_line like~ "*plackup*") or + ( + process.parent.name == "java" and ( + process.parent.args like~ ( + /* Tomcat */ + "org.apache.catalina.startup.Bootstrap", "-Dcatalina.base=*", + + /* Jetty */ + "org.eclipse.jetty.start.Main", "-Djetty.home=*", + + /* WildFly / JBoss */ + "org.jboss.modules.Main", "-Djboss.home.dir=*", + + /* WebLogic */ + "weblogic.Server", "-Dweblogic.Name=*", "*weblogic-launcher.jar*", + + /* WebSphere traditional + Liberty */ + "com.ibm.ws.runtime.WsServer", "com.ibm.ws.kernel.boot.cmdline.Bootstrap", + + /* GlassFish */ + "com.sun.enterprise.glassfish.bootstrap.ASMain", + + /* Resin */ + "com.caucho.server.resin.Resin", + + /* Spring Boot */ + "org.springframework.boot.loader.*", + + /* Quarkus */ + "*quarkus-run.jar*", "io.quarkus.runner.GeneratedMain", + + /* Micronaut */ + "io.micronaut.runtime.Micronaut", + + /* Dropwizard */ + "io.dropwizard.cli.ServerCommand", + + /* Play */ + "play.core.server.ProdServerStart", + + /* Helidon */ + "io.helidon.microprofile.server.Main", "io.helidon.webserver*", + + /* Vert.x */ + "io.vertx.core.Launcher", + + /* Keycloak */ + "org.keycloak*", + + /* Apereo CAS */ + "org.apereo.cas*", + + /* Elasticsearch */ + "org.elasticsearch.bootstrap.Elasticsearch", + + /* Atlassian / Gerrit */ + "com.atlassian.jira.startup.Launcher", "*BitbucketServerLauncher*", "com.google.gerrit.pgm.Daemon", + + /* Solr */ + "*-Dsolr.solr.home=*", + + /* Jenkins */ + "*jenkins.war*" + ) or + ?process.working_directory like "/u0?/*" + ) + ) +) and ( + process.executable like ( + "/tmp/*", "/var/tmp/*", "/dev/shm/*", "./*", "/run/*", "/var/run/*", "/boot/*", "/sys/*", "/lost+found/*", + "/proc/*", "/var/mail/*", "/var/www/*", "/home/*/*", "/root/*" + ) or + process.name like~ ( + // Hidden processes + ".*", + + // Suspicious file formats + "*.elf", "*.sh", "*.py", "*.rb", "*.pl", "*.lua*", "*.php*", ".js", "*.bin", "*.jar", "*.mjs", + + // Network utilities often used for reverse shells + "nc", "netcat", "ncat", "telnet", "socat", "openssl", "nc.openbsd", "ngrok", "nc.traditional", + + // Cloud CLI + "az", "gcloud", "aws", "kubectl", "helm", "docker", "ctr", "crictl", + + // Misc. tools + "whoami", "ifconfig", "ip", "ss", "top", "htop", "du", "lsblk", "lsof", "tcpdump", + "strace", "ltrace", "curl", "wget", "dig", "nslookup", "host", "nmap", "arp", "traceroute", + "cat", "touch", "mv", "rm", "mkdir", "ln", "chmod", "sudo", "xxd", "base64", "basez", + "base64plain", "base64url", "base64mime", "base64pem", "basenc", "base32", "base16", "chpasswd", + "passwd" + ) +) and +not ( + ( + process.parent.name == "java" and + process.executable like ("/tmp/CVU_19_resource_*/exectask*", "/u01/app/*/grid/bin/crsctl.bin", "/u01/app/*/grid/bin/olsnodes.bin") + ) or + process.working_directory like ("/u01/app/*/sysman/emd", "/run/systemd/mount-rootfs") or + ( + process.parent.executable == "/opt/morpheus/embedded/java/jre/bin/java" and + process.command_line like ( + "chmod -R g+w /var/opt/morpheus/morpheus-local/repo/git/*", + "sudo -S -u morpheus-local*" + ) + ) or + ( + process.parent.command_line == "/bin/sh /etc/init.d/nginx rotate" and + process.name == "cat" + ) or + ( + process.parent.name == "asterisk" and + process.executable like ( + "/var/www/html/dialapplet-web/agi/*.php", "/var/lib/asterisk/bin/faxnotify.php" + ) + ) or + ( + process.parent.executable == "/home/jiraContractor/jira.install/jre/bin/java" and + process.executable == "/home/jiraContractor/jira.install/jre/lib/jspawnhelper" + ) or + process.parent.args like "/home/agent/Claude/*" or + (process.parent.executable == "/usr/lib/jvm/java-21-openjdk/bin/java" and process.name == "ln") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Server Software Component +** ID: T1505 +** Reference URL: https://attack.mitre.org/techniques/T1505/ +* Sub-technique: +** Name: Web Shell +** ID: T1505.003 +** Reference URL: https://attack.mitre.org/techniques/T1505/003/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-suspicious-command-execution-via-busybox-proxy.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-suspicious-command-execution-via-busybox-proxy.asciidoc new file mode 100644 index 0000000000..9bf2b1d7b4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-suspicious-command-execution-via-busybox-proxy.asciidoc @@ -0,0 +1,185 @@ +[[prebuilt-rule-8-19-27-suspicious-command-execution-via-busybox-proxy]] +=== Suspicious Command Execution via Busybox Proxy + +This rule detects the execution of command line arguments capable of spawning shells or establishing network connections through Busybox. This technique can be used to execute commands while attempting to evade detection. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Command and Control +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious Command Execution via Busybox Proxy* + + +This rule flags Busybox being used as a proxy to launch shells or make outbound connections on Linux, a common way to hide command execution behind a trusted multi-call binary and slip past simple detections. An intruder can drop a script or binary in /tmp or /dev/shm, then run Busybox sh with /dev/tcp, nc, or openssl to establish a reverse shell and execute follow-on commands. + + +*Possible investigation steps* + + +- Reconstruct the full execution chain around the Busybox invocation to identify the initiating script or binary, the user or service account involved, and whether the parent came from a writable or ephemeral location such as /tmp, /dev/shm, or a hidden working directory. +- Retrieve and analyze any files or command artifacts referenced in the invocation, including shell scripts, dropped binaries, or inline payloads, and compare their hashes and prevalence against internal baselines and external reputation sources. +- Review adjacent host activity for follow-on behavior consistent with staging or hands-on-keyboard access, such as additional shell launches, curl or wget downloads, permission changes, archive extraction, credential access attempts, or persistence creation via cron, systemd, or startup scripts. +- Pivot to network telemetry from the same host and time window to determine whether Busybox or its descendants established outbound sessions, then validate the destination IPs, domains, ports, and protocols against expected business use and known benign infrastructure. +- Confirm whether the behavior is expected for the asset type, container image, or embedded tooling in use, and if the activity is not readily explained, isolate the host and collect volatile evidence such as active connections, running processes, loaded modules, and recent shell history. + + +*False positive analysis* + + +- Container or host startup scripts may invoke `busybox sh` with `nc`, `openssl`, or `/dev/tcp` from a temporary path to wait for a local dependency or perform a health check; verify the parent script is part of the expected image or boot workflow and that the destination is a known internal service. +- An administrator or automation task may stage a temporary script under `/tmp`, `/var/tmp`, or a user home directory that uses `busybox sh` to test port reachability or TLS negotiation during troubleshooting; confirm the initiating account and script contents against approved maintenance activity and check that no suspicious follow-on processes or outbound connections occurred. + + +*Response and remediation* + + +- Isolate the affected Linux host from the network, terminate the malicious `busybox` process and any spawned shells, and block the destination IPs, domains, and ports used by the outbound session or reverse shell. +- Preserve copies of the parent script or binary from locations such as `/tmp`, `/var/tmp`, or `/dev/shm`, then remove attacker persistence including cron jobs, `systemd` service files, `rc.local` changes, startup scripts, and unauthorized `authorized_keys` entries tied to the same activity. +- Reset passwords, revoke tokens, and rotate SSH keys or application secrets for any user or service account that launched Busybox or was exposed on the host, especially when shell history, environment files, or config files contained credentials. +- Reimage the host or restore it from a known-good baseline, verify trusted package integrity for replaced binaries and scripts, and return the system to service only after confirming no unexpected executables remain in writable or temporary directories. +- Escalate to incident response immediately if the Busybox session ran as `root`, reached an external address, created persistence beyond a single host, or if other systems show the same dropped script, destination, or follow-on shell activity. +- Harden the environment by restricting Busybox execution to approved administrative use, mounting temporary directories with `noexec` where feasible, limiting unnecessary outbound egress, and adding detections for shell-capable Busybox usage launched from temporary, hidden, or user-writable paths. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Elastic Defend + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start") and +process.name == "busybox" and ( + process.args in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and + process.command_line like ( + "*nc *", "*netcat*", "*openssl*", "*telnet*", "*exec*", "*import*pty*spawn*", "*import*subprocess*call*", "*socket*", + "*system*", "*io.popen*", "*os.execute*", "*fsockopen*", "*/inet/tcp/*", "*/dev/tcp/*", "*/dev/udp/*", "*nohup*", + "*setsid*", "*/dev/shm/*", "*ld-linux*.so*", "*/tmp/*", "*/var/tmp/*", "*rm*-rf*" + ) +) and ( + process.parent.executable like ( + "/tmp/*", "/var/tmp/*", "/dev/shm/*", "./*", "/run/*", "/var/run/*", "/boot/*", "/sys/*", "/lost+found/*", + "/proc/*", "/var/mail/*", "/var/www/*", "/home/*", "/root/*" + ) or + process.parent.name like ".*" +) and not ( + process.parent.command_line in ("runc init", "/usr/local/bin/runc init") or + process.parent.executable == "./runc" or + process.parent.executable like ("/run/containerd/io.containerd.runtime.v2.task/k8s.io/*/bin/php", "/tmp/go-build*.test") or + process.command_line == "sh -c echo EXEC" or + process.parent.name in ("ninja_test", "ocamlrun", "ocamlopt.opt", "make", "process-wrapper") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-suspicious-kerberos-authentication-ticket-request.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-suspicious-kerberos-authentication-ticket-request.asciidoc new file mode 100644 index 0000000000..93b29b7a44 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-suspicious-kerberos-authentication-ticket-request.asciidoc @@ -0,0 +1,208 @@ +[[prebuilt-rule-8-19-27-suspicious-kerberos-authentication-ticket-request]] +=== Suspicious Kerberos Authentication Ticket Request + +Correlates network connections to the standard Kerberos port by an unusual process from the source machine with a Kerberos authentication ticket request from the target domain controller. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.network-* +* logs-windows.sysmon_operational-* +* logs-system.security* +* logs-windows.forwarded* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/its-a-feature/bifrost +* https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4768 +* https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4769 + +*Tags*: + +* Domain: Endpoint +* Domain: Identity +* OS: Windows +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Use Case: Active Directory Monitoring +* Data Source: Active Directory +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Windows Security Event Logs +* Resources: Investigation Guide + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suspicious Kerberos Authentication Ticket Request* + + + +*Possible investigation steps* + + +- Which Timeline member events define this Kerberos sequence? + - Focus: Timeline members keyed by alert `source.ip` and `source.port`; recover source `process.executable`, Kerberos `destination.ip`, and auth `event.code`. + - Hint: record `host.id` and `process.entity_id`; verify auth `winlog.computer_name` is the DC. + - Implication: escalate when one non-"lsass.exe" source process maps to a DC "4768" or "4769" event in the sequence window; lower concern for socket reuse, a different process, or non-DC destination. + +- Is the recovered source process a recognized Kerberos-capable client? + - Focus: `process.executable`, `process.hash.sha256`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.code_signature.trusted`. + - Hint: open process start with recovered `host.id` and `process.entity_id`; if absent, use `host.id`, `process.pid`, and sequence window. + - Implication: escalate when the binary is unsigned, renamed, user-writable, signer-mismatched, or outside known AD audit, Kerberos diagnostic, or security-test tooling; lower concern only when path, signer, hash history, command, and parent converge on one known tool. + +- Does command-line and parentage show ticket-tool intent? + - Focus: recovered `process.command_line`, `process.parent.executable`, `process.parent.command_line`, and broader process lineage when needed. + - Implication: escalate on Bifrost-like verbs or flags such as asktgt, asktgs, s4u, ptt, kerberoast, service/SPN targets, hashes, keytabs, RC4, or base64 tickets, especially from shell or script parents; bounded diagnostics from a recognized admin tool reduce but do not clear concern. + +- Which ticket path and target account did the DC member event show? + - Focus: recovered auth `event.code`, `winlog.event_data.TargetUserName`, and `winlog.event_data.TargetDomainName`. + - Implication: escalate when "4769" shows service-ticket activity or "4768" shows TGT handling for privileged, service, machine, or delegation-sensitive targets from the unusual process; fan-out increases concern. + +- Does the source user and session context fit one bounded admin or audit source? + - Focus: recovered `user.id`, `user.name`, `user.domain`, and `winlog.event_data.TargetUserName`. + - Implication: escalate when privileged, service, or user-account tickets originate from a workstation, user session, or non-management tool; lower concern only when source host, user, process identity, command/parent, and target account recur as one bounded Kerberos diagnostic or audit pattern. + +- Do surrounding Kerberos events show repetition or account fan-out? + - Focus: same-source Kerberos network and authentication events, checking additional "4768"/"4769" events and `winlog.event_data.TargetUserName`. + - !{investigate{"description":"","label":"Kerberos network events from the same source IP","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"source.ip","queryType":"phrase","value":"{{source.ip}}","valueType":"string"},{"excluded":false,"field":"destination.port","queryType":"phrase","value":"88","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - !{investigate{"description":"","label":"Authentication events for the same source IP","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"authentication","valueType":"string"},{"excluded":false,"field":"source.ip","queryType":"phrase","value":"{{source.ip}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when requests repeat or fan out across accounts; a single bounded request narrows scope but does not close if process identity or command intent remains suspicious. Missing network or authentication telemetry is unresolved, not benign. + +- Do later logon or explicit-credential events suggest ticket use? + - Focus: same-source authentication results, checking later `event.code` "4624"/"4648", `winlog.event_data.TargetUserName`, and 4648 `winlog.event_data.TargetServerName`. + - Implication: escalate when post-ticket logon or explicit-credential activity reaches sensitive accounts or servers from the same source; absence narrows impact but does not close if the ticket request remains suspicious. Missing same-source authentication telemetry leaves ticket use unresolved, not benign. + +- If local evidence remains suspicious or unresolved, does the same source show related alerts? + - Focus: related alerts for `source.ip`; manually pivot on recovered `process.hash.sha256` or `winlog.event_data.TargetUserName` when locally suspicious. !{investigate{"description":"","label":"Alerts associated with the same source IP","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"source.ip","queryType":"phrase","value":"{{source.ip}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden scope when credential-access, Kerberoasting, relay, or lateral-movement alerts share the source, process, or target account; keep local only when related alerts are absent and recovered evidence resolves cleanly. + +- Escalate when sequence recovery, source-process identity, command intent, DC ticket target, account context, or surrounding ticket/logon activity show unauthorized direct Kerberos; close only when telemetry binds one recognized tool, source host, user, and target account and outside confirmation verifies exact activity when telemetry cannot; preserve and escalate when visibility is incomplete or evidence conflicts. + + +*False positive analysis* + + +- AD audit tools, Kerberos diagnostics, interoperability testing, or security testing can request tickets directly instead of through "lsass.exe". Confirm only when process path, signer/hash, parent, command line, `source.ip`, `user.id`, `event.code`, and target account align with the same recognized tool on a dedicated admin, lab, or audit source; without outside records, require the same process identity, source host/user, target account, and bounded ticket pattern across prior alerts from this rule. +- Treat partial matches as unresolved when process identity fits but the command targets unusual SPNs, privileged accounts, RC4/kerberoast behavior, or follow-on "4624"/"4648" activity. Do not close on signer, source IP, or event code alone when ticket target or command intent contradicts benign workflow. +- Before creating an exception, anchor it to the minimum stable workflow: dedicated `source.ip` or source host, process signer/hash/path, parent workflow, `user.id`, target account, and bounded `event.code` pattern. Avoid exceptions on `source.port`, `event.code`, process name, or broad account patterns alone. + + +*Response and remediation* + + +- If confirmed benign, reverse temporary containment and document the recovered source host/IP, process identity, command line, source user, DC ticket event, and target account that proved the recognized workflow. Create an exception only after the same dedicated source and process pattern recurs consistently. +- If suspicious but unconfirmed, preserve the alert, Timeline member events, suspicious process binary and command line, source socket, DC authentication record, and any follow-on "4624" or "4648" evidence before containment or process action. +- Apply reversible containment next: restrict the recovered source host's Kerberos/DC access or isolate the host when its role tolerates isolation, and suspend the recovered process only after process and authentication artifacts are captured. +- If confirmed malicious, isolate the recovered source host, terminate or suspend the recovered process after recording its `process.entity_id`, expire exposed Kerberos tickets where operationally appropriate, and reset or rotate impacted credentials, prioritizing privileged, service, machine, and delegation-capable accounts. +- Before cleanup, search for the same source IP, recovered process hash, target account, and related credential-access, Kerberoasting, relay, or lateral-movement activity so scope is not limited to the first sequence. +- After containment, retain DC "4768"/"4769" auditing and endpoint network telemetry, restrict direct Kerberos tooling to controlled admin/testing hosts, and document the recovered tool pattern and any logging gaps in the case record. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sysmon-event-3-setup[Sysmon Event ID 3 - Network Connection] +- https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/audit-kerberos-authentication-service[Audit Kerberos Authentication Service] +- https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/audit-kerberos-service-ticket-operations[Audit Kerberos Service Ticket Operations] + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by source.port, source.ip with maxspan=3s + [network where host.os.type == "windows" and destination.port == 88 and + process.executable != null and process.pid != 4 and + not process.executable : ( + "?:\\Windows\\system32\\lsass.exe", + "\\device\\harddiskvolume*\\windows\\system32\\lsass.exe", + "\\device\\harddiskvolume*\\windows\\system32\\svchost.exe" + ) and + not ( + process.executable : ( + "C:\\Windows\\System32\\svchost.exe", + "C:\\Program Files\\VMware\\VMware View\\Server\\bin\\ws_TomcatService.exe", + "C:\\Program Files\\Omnissa\\Horizon\\Server\\bin\\ws_TomcatService.exe", + "C:\\Program Files\\SysAidServer\\root\\WEB-INF\\domains\\NetworkDiscovery.exe", + "C:\\Program Files (x86)\\IGEL\\RemoteManager\\*\\bin\\tomcat10.exe", + "F:\\IGEL\\RemoteManager\\*\\bin\\tomcat10.exe" + ) and + user.id in ("S-1-5-20", "S-1-5-18") + ) and + source.ip != "127.0.0.1" and destination.ip != "::1" and destination.ip != "127.0.0.1"] + [authentication where host.os.type == "windows" and event.code in ("4768", "4769")] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Pass the Ticket +** ID: T1550.003 +** Reference URL: https://attack.mitre.org/techniques/T1550/003/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal or Forge Kerberos Tickets +** ID: T1558 +** Reference URL: https://attack.mitre.org/techniques/T1558/ +* Sub-technique: +** Name: Kerberoasting +** ID: T1558.003 +** Reference URL: https://attack.mitre.org/techniques/T1558/003/ +* Sub-technique: +** Name: AS-REP Roasting +** ID: T1558.004 +** Reference URL: https://attack.mitre.org/techniques/T1558/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-suspicious-screenconnect-client-child-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-suspicious-screenconnect-client-child-process.asciidoc new file mode 100644 index 0000000000..14f8b9a80e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-suspicious-screenconnect-client-child-process.asciidoc @@ -0,0 +1,234 @@ +[[prebuilt-rule-8-19-27-suspicious-screenconnect-client-child-process]] +=== Suspicious ScreenConnect Client Child Process + +Identifies suspicious processes being spawned by the ScreenConnect client processes. This activity may indicate execution abusing unauthorized access to the ScreenConnect remote access software. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.huntress.com/blog/slashandgrab-screen-connect-post-exploitation-in-the-wild-cve-2024-1709-cve-2024-1708 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Command and Control +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Windows Security Event Logs +* Data Source: Crowdstrike + +*Version*: 316 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious ScreenConnect Client Child Process* + + +ScreenConnect, a remote access tool, facilitates legitimate remote support but can be exploited by adversaries to execute unauthorized commands. Malicious actors may spawn processes like PowerShell or cmd.exe via ScreenConnect to perform harmful activities. The detection rule identifies such suspicious child processes, focusing on unusual arguments and process names, indicating potential abuse of remote access capabilities. + + +*Possible investigation steps* + + +- Review the parent process name to confirm it is one of the ScreenConnect client processes listed in the query, such as ScreenConnect.ClientService.exe or ScreenConnect.WindowsClient.exe, to verify the source of the suspicious activity. +- Examine the child process name and arguments, such as powershell.exe with encoded commands or cmd.exe with /c, to identify potentially malicious actions or commands being executed. +- Check the network activity associated with the suspicious process, especially if the process arguments include network-related terms like *http* or *downloadstring*, to determine if there is any unauthorized data exfiltration or command and control communication. +- Investigate the user account under which the suspicious process was executed to assess if the account has been compromised or is being misused. +- Correlate the event with other security alerts or logs from data sources like Elastic Defend or Microsoft Defender XDR to gather additional context and identify any related malicious activities. +- Review the system's recent activity and changes, such as new scheduled tasks or services created by schtasks.exe or sc.exe, to identify any persistence mechanisms that may have been established by the attacker. + + +*False positive analysis* + + +- Legitimate IT support activities using ScreenConnect may trigger the rule when executing scripts or commands for maintenance. To manage this, identify and whitelist specific IT support accounts or IP addresses that regularly perform these actions. +- Automated scripts or scheduled tasks that use ScreenConnect for routine operations might be flagged. Review and document these scripts, then create exceptions for known benign processes and arguments. +- Software updates or installations initiated through ScreenConnect can appear suspicious. Maintain a list of approved software and update processes, and exclude these from the rule. +- Internal security tools or monitoring solutions that leverage ScreenConnect for legitimate purposes may be detected. Verify these tools and add them to an exclusion list to prevent false positives. +- Training sessions or demonstrations using ScreenConnect to showcase command-line tools could be misinterpreted as threats. Ensure these sessions are logged and recognized as non-threatening, and adjust the rule to accommodate these scenarios. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the attacker. +- Terminate any suspicious processes identified in the alert, such as PowerShell, cmd.exe, or other flagged executables, to halt any ongoing malicious activity. +- Review and revoke any unauthorized user accounts or privileges that may have been created or modified using tools like net.exe or schtasks.exe. +- Conduct a thorough scan of the affected system using endpoint protection tools to identify and remove any malware or unauthorized software installed by the attacker. +- Restore the system from a known good backup if any critical system files or configurations have been altered or compromised. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring and logging for ScreenConnect and other remote access tools to detect similar activities in the future, ensuring that alerts are promptly reviewed and acted upon. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.parent.name : + ("ScreenConnect.ClientService.exe", + "ScreenConnect.WindowsClient.exe", + "ScreenConnect.WindowsBackstageShell.exe", + "ScreenConnect.WindowsFileManager.exe") and + ( + (process.name : "powershell.exe" and + process.args : ("-enc", "-ec", "-e", "*downloadstring*", "*Reflection.Assembly*", "*http*")) or + (process.name : "cmd.exe" and process.args : "/c") or + (process.name : "net.exe" and process.args : "/add") or + (process.name : "schtasks.exe" and process.args : ("/create", "-create")) or + (process.name : "sc.exe" and process.args : "create") or + (process.name : "rundll32.exe" and not process.args : "url.dll,FileProtocolHandler") or + (process.name : "msiexec.exe" and process.args : ("/i", "-i") and + process.args : ("/q", "/quiet", "/qn", "-q", "-quiet", "-qn", "-Q+")) or + process.name : ("mshta.exe", "certutil.exe", "bitsadmin.exe", "certreq.exe", "wscript.exe", "cscript.exe", "curl.exe", + "ssh.exe", "scp.exe", "wevtutil.exe", "wget.exe", "wmic.exe") + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ +* Technique: +** Name: Remote Access Tools +** ID: T1219 +** Reference URL: https://attack.mitre.org/techniques/T1219/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Sub-technique: +** Name: Mshta +** ID: T1218.005 +** Reference URL: https://attack.mitre.org/techniques/T1218/005/ +* Sub-technique: +** Name: Msiexec +** ID: T1218.007 +** Reference URL: https://attack.mitre.org/techniques/T1218/007/ +* Sub-technique: +** Name: Rundll32 +** ID: T1218.011 +** Reference URL: https://attack.mitre.org/techniques/T1218/011/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Windows Management Instrumentation +** ID: T1047 +** Reference URL: https://attack.mitre.org/techniques/T1047/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Sub-technique: +** Name: Windows Command Shell +** ID: T1059.003 +** Reference URL: https://attack.mitre.org/techniques/T1059/003/ +* Sub-technique: +** Name: Visual Basic +** ID: T1059.005 +** Reference URL: https://attack.mitre.org/techniques/T1059/005/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Scheduled Task/Job +** ID: T1053 +** Reference URL: https://attack.mitre.org/techniques/T1053/ +* Sub-technique: +** Name: Scheduled Task +** ID: T1053.005 +** Reference URL: https://attack.mitre.org/techniques/T1053/005/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Sub-technique: +** Name: Windows Service +** ID: T1543.003 +** Reference URL: https://attack.mitre.org/techniques/T1543/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-systemd-service-override-configuration-file-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-systemd-service-override-configuration-file-created.asciidoc new file mode 100644 index 0000000000..32e1402dd5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-systemd-service-override-configuration-file-created.asciidoc @@ -0,0 +1,174 @@ +[[prebuilt-rule-8-19-27-systemd-service-override-configuration-file-created]] +=== Systemd Service Override Configuration File Created + +This rule detects the creation or renaming of a new Systemd override configuration file in any of the Systemd service locations for both root and regular users. Systemd override configuration files are configuration files in Linux systems used to override the default Systemd service configuration for a specific service. Malicious actors can leverage systemd override configuration files to achieve persistence by creating or modifying services to execute malicious commands or payloads during system startup or at a predefined interval by adding a systemd timer. This allows them to maintain unauthorized access, execute additional malicious activities, or evade detection. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Privilege Escalation +* Data Source: Elastic Defend +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Systemd Service Override Configuration File Created* + + +This alert fires when a new systemd service override file appears in standard system or user service directories, which can silently change how a service starts and make malicious behavior survive reboots or user logins. An attacker might drop an override for sshd.service or a common daemon to add an ExecStartPre or timer-triggered command that launches a backdoor every boot while leaving the original unit intact. + + +*Possible investigation steps* + + +- Open the new override and compare it with the base unit and any recent approved change, focusing on directives like ExecStart, ExecStartPre, ExecStartPost, Environment, User, WorkingDirectory, OnCalendar, and WantedBy that could introduce persistence or alter privileges. +- Trace the creation back to the initiating binary, parent process chain, account, and session context to determine whether it originated from expected package management or configuration automation versus an interactive shell, script, or unknown tool. +- Review nearby host activity for `systemctl daemon-reload`, `enable`, `start`, `restart`, or timer operations, then verify whether the affected service or timer loaded the override and launched any newly referenced command. +- Examine any scripts, binaries, environment files, sockets, or network destinations referenced by the override for newly dropped or suspicious content, and hunt for similar override files on the same host and peer systems to assess spread. + + +*False positive analysis* + + +- A system administrator may legitimately create `/etc/systemd/system/.d/override.conf` during maintenance to change startup order, resource limits, or environment settings for a supported service, so verify a corresponding approved change and confirm the creating process and user session map to expected administrative activity. +- A user or root account may create a user-level `override.conf` under `~/.config/systemd/user/` or `~/.local/share/systemd/user/` to customize a legitimate per-user service, so confirm the file owner matches the affected account and that any `Exec*` or `Environment` entries reference the expected application path and business use. + + +*Response and remediation* + + +- Isolate the affected Linux host from the network while keeping it powered on, preserve the malicious `override.conf`, the base unit file, any referenced scripts or binaries, and the output of `systemctl cat ` and `systemctl status ` for evidence and scoping. +- Remove attacker persistence by disabling and stopping the altered service or timer, deleting the malicious drop-in directory or `override.conf`, reversing any added `Exec*`, `Environment`, or `OnCalendar` directives, and running `systemctl daemon-reload` before confirming the unit now matches the approved baseline. +- Search the host and peer systems for additional drop-ins under `/etc/systemd/system`, `/usr/lib/systemd/system`, and user service paths, then quarantine any newly referenced payloads, kill related processes, and block their hashes or paths in endpoint controls. +- Restore the system to a known-good state by reinstalling or replacing any modified unit files, scripts, and binaries from trusted packages or backups, rotating credentials and secrets used by the affected service account, and rebuilding the host if integrity cannot be confidently verified. +- Escalate to incident response immediately if the override modified a high-value service such as `sshd`, a security agent, or a network-facing daemon, if root-level user service paths were abused, or if the same persistence appears on multiple hosts, because these signs indicate broader compromise. +- Harden the environment by restricting write access to systemd service directories, tightening sudo and configuration-management permissions, enforcing file integrity monitoring on `*.service.d/override.conf`, and alerting on unauthorized `systemctl enable`, `daemon-reload`, and service or timer changes. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "linux" and event.action in ("rename", "creation") and +file.extension == "conf" and file.path like ( + "/etc/systemd/system/*.d/*.conf", "/etc/systemd/user/*.d/*.conf", "/usr/local/lib/systemd/system/*.d/*.conf", + "/lib/systemd/system/*.d/*.conf", "/usr/lib/systemd/system/*.d/*.conf", "/usr/lib/systemd/user/*.d/*.conf", + "/home/*/.config/systemd/user/*.d/*.conf", "/home/*/.local/share/systemd/user/*.d/*.conf", + "/root/.config/systemd/user/*.d/*.conf", "/root/.local/share/systemd/user/*.d/*.conf", + "/run/systemd/system/*.d/*.conf", "/var/run/systemd/system/*.d/*.conf" +) and +not process.executable in ( + "/bin/dpkg", "/usr/bin/dpkg", "/bin/dockerd", "/usr/bin/dockerd", "/usr/sbin/dockerd", "/bin/microdnf", + "/usr/bin/microdnf", "/bin/rpm", "/usr/bin/rpm", "/bin/snapd", "/usr/bin/snapd", "/bin/yum", "/usr/bin/yum", + "/bin/dnf", "/usr/bin/dnf", "/bin/podman", "/usr/bin/podman", "/bin/dnf-automatic", "/usr/bin/dnf-automatic", + "/usr/bin/dpkg-divert", "/bin/dpkg-divert", "/sbin/apk", "/usr/sbin/apk", "/usr/local/sbin/apk", "/usr/bin/dnf5", + "/usr/bin/apt", "/usr/bin/puppet", "/bin/puppet", "/opt/puppetlabs/puppet/bin/puppet", "/usr/bin/pacman", + "/usr/bin/chef-client", "/bin/chef-client", "/usr/bin/pamac-daemon", "/bin/pamac-daemon", "/usr/local/bin/dockerd", + "/usr/bin/crio", "/usr/bin/podman", "/usr/bin/tdnf", "/usr/bin/apk" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Sub-technique: +** Name: Systemd Service +** ID: T1543.002 +** Reference URL: https://attack.mitre.org/techniques/T1543/002/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Sub-technique: +** Name: Systemd Service +** ID: T1543.002 +** Reference URL: https://attack.mitre.org/techniques/T1543/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-untrusted-driver-loaded.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-untrusted-driver-loaded.asciidoc new file mode 100644 index 0000000000..b2a3533b7d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-untrusted-driver-loaded.asciidoc @@ -0,0 +1,166 @@ +[[prebuilt-rule-8-19-27-untrusted-driver-loaded]] +=== Untrusted Driver Loaded + +Identifies an untrusted driver loaded by the Windows kernel. Adversaries may modify code signing policies to enable execution of unsigned or self-signed kernel code. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.library-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/hfiref0x/TDL +* https://docs.microsoft.com/en-us/previous-versions/windows/hardware/design/dn653559(v=vs.85)?redirectedfrom=MSDN + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Elastic Defend + +*Version*: 15 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Untrusted Driver Loaded* + + + +*Possible investigation steps* + + +- What exact kernel driver loaded, and what trust failure made it alert? + - Focus: `process.pid`, `dll.path`, `dll.code_signature.exists`, `dll.code_signature.trusted`, and `dll.code_signature.status`. + - Implication: escalate when System loaded an unsigned or untrusted driver from a non-vendor, user-writable, temp, or renamed path; lower concern only when the trust failure fits a controlled driver-development or hardware-validation host class. + +- Does the driver identity map to a known vulnerable driver, BYOVD chain, or offensive loader? + - Why: TDL-style and BYOVD activity may be easier to recognize by stable hash, original PE name, or signer than current file name. + - Focus: `dll.hash.sha256`, `dll.pe.original_file_name`, `dll.code_signature.subject_name`, and `dll.code_signature.thumbprint_sha256`. + - Implication: escalate when hash, original name, or signer maps to a vulnerable-driver blocklist, signature-bypass loader, or malicious kernel tooling; lower concern only when the same artifact is tied to a controlled lab or validation cohort. + +- Does recency or rename timing show the driver was staged for this load? + - Focus: `dll.Ext.relative_file_creation_time`, `dll.Ext.relative_file_name_modify_time`, and `dll.path`; if file-event telemetry is available, use the same `host.id` and path to identify who wrote or renamed it. !{investigate{"description":"","label":"File events for the loaded driver path","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"file.path","queryType":"phrase","value":"{{dll.path}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when the driver appeared just before load, was recently renamed, or was written by an unrelated staging process. Missing file-event telemetry leaves provenance unresolved, not benign. + +- What resident service or device identity is tied to the loaded image? + - Focus: compare `dll.path`, `dll.hash.sha256`, and `dll.code_signature.subject_name` with current Osquery driver inventory and service output. + - Hint: For non-Microsoft drivers by `image`, `service`, `signed`, `subject_name`, and `VtLink`; use it as current-state context, and keep the alert as the historical load record if no matching image exists. + - !{osquery{"label":"Osquery - Retrieve All Non-Microsoft Drivers with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, class, description, directory, image,\nissuer_name, manufacturer, service, signed, subject_name FROM drivers JOIN authenticode ON drivers.image =\nauthenticode.path JOIN hash ON drivers.image = hash.path WHERE NOT (provider == \"Microsoft\" AND signed == \"1\")\n"}} + - Hint: For unsigned current drivers when the alert shows missing or untrusted signature metadata; current signed or service values do not prove what existed at `@timestamp`. + - !{osquery{"label":"Osquery - Retrieve All Unsigned Drivers with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, class, description, directory, image,\nissuer_name, manufacturer, service, signed, subject_name FROM drivers JOIN authenticode ON drivers.image =\nauthenticode.path JOIN hash ON drivers.image = hash.path WHERE signed == \"0\"\n"}} + - Implication: escalate when current inventory lacks a coherent image or service entry, the service is unexpected for the host, or other unsigned drivers do not fit the host role. Treat osquery as corroboration; do not delay escalation when alert-local identity, trust, or recency evidence is decisive. + +- Did signing or code-integrity control activity make this load possible? + - Why: 64-bit Windows normally enforces kernel-mode driver signing, while test-signing, DSE tampering, or vulnerable-driver loaders can open a path for untrusted kernel code. + - Focus: same-host process events around the load using `host.id`, `process.name`, `process.executable`, and `process.command_line` for bcdedit test-signing/nointegritychecks changes or known vulnerable-driver loader activity. !{investigate{"description":"","label":"Process events on the driver host","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when surrounding process evidence shows test-signing changes, code-integrity bypass tooling, or vulnerable-driver loader execution; absent process evidence weakens this corroborator but does not clear an unexplained untrusted driver load. + +- Does the host cohort and prevalence fit a controlled driver workflow? + - Focus: `host.id`, `host.name`, and the smallest stable indicator, usually `dll.hash.sha256`, `dll.path`, or `dll.code_signature.subject_name`. + - Hint: broaden only when identity, recency, inventory, or tampering evidence remains suspicious or unresolved. !{investigate{"description":"","label":"Alerts associated with the driver identity","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"dll.hash.sha256","queryType":"phrase","value":"{{dll.hash.sha256}}","valueType":"string"}],[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"dll.path","queryType":"phrase","value":"{{dll.path}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: escalate when the driver appears on production systems, user-writable paths, unrelated hosts, or outside the expected lab cohort; lower concern only when artifact, path pattern, signer, and host cohort consistently match a controlled validation workflow. + +- Using identity, trust failure, staging/provenance, osquery inventory, signing-control evidence, and host-cohort spread: escalate unauthorized kernel code, BYOVD, or signature-bypass evidence; close only when telemetry binds the load to one controlled driver workflow; preserve artifacts and escalate mixed or incomplete cases. + + +*False positive analysis* + + +- Controlled driver-development, OEM hardware validation, and authorized security or EDR compatibility testing can load test-signed or unsigned drivers on isolated lab hosts. Confirm first with telemetry: `dll.hash.sha256`, `dll.path`, `dll.code_signature.status` or `dll.code_signature.subject_name`, current osquery image and service output, and `host.id` cohort must align with one workflow. Use build, test, or change records only after telemetry binds the exact artifact and cohort; if unavailable, require prior alerts for the same driver artifact and host cohort before exceptioning. If any evidence dimension contradicts the workflow, do not close as benign. +- Build exceptions only from the minimum confirmed pattern, such as `dll.hash.sha256` plus `dll.path` plus bounded `host.id` cohort or service identity. Avoid exceptions on `dll.name`, signer, or generic unsigned-driver conditions alone. + + +*Response and remediation* + + +- If confirmed benign: + - Reverse temporary containment and document the driver artifact, host cohort, current osquery image and service values, and any corroborating external record. Keep exceptions narrow to the confirmed hash, path, host cohort, or service identity. +- If suspicious but unconfirmed: + - Preserve the driver file if accessible, the alert event export, osquery driver inventory results, surrounding signing-control process events, and the case timeline before containment or cleanup. + - Apply reversible containment first, such as temporary network restriction or heightened monitoring, while scoping the same `dll.hash.sha256` or `dll.path` across other hosts. + - Escalate to host isolation before reboot, uninstall, or cleanup only if evidence shows code-integrity tampering, vulnerable-driver loader activity, post-load abuse, or spread outside the expected lab cohort. +- If confirmed malicious: + - Isolate the host after preserving the driver artifact, service or boot-start context, signing-control evidence, and affected `host.id` or `host.name`. If endpoint response is unavailable, hand off that evidence set to the team that can contain the system. + - Scope other hosts for the same `dll.hash.sha256`, `dll.path`, or `dll.code_signature.subject_name` before uninstalling the driver, deleting the file, removing the backing service, or rebooting. + - Remove the malicious driver, related service or boot-start entry, and code-signing or DSE changes identified during investigation, then remediate the loader or vulnerable-driver path that introduced it. +- Post-incident hardening: + - Re-enable or enforce driver-signing and code-integrity controls on the affected host class, block confirmed malicious or vulnerable `dll.hash.sha256` values and `dll.path` locations, and restrict test-signing to isolated lab systems. + - Document any BYOVD family, loader service name, or host-cohort pattern uncovered during triage for future response cases. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +==== Rule query + + +[source, js] +---------------------------------- +driver where host.os.type == "windows" and process.pid == 4 and + (dll.code_signature.trusted == false or dll.code_signature.exists == false) and + /* errorExpired and errorRevoked are handled by d12bac54-ab2a-4159-933f-d7bcefa7b61d */ + not dll.code_signature.status : ("errorExpired", "errorRevoked", "errorCode_endpoint:*") and + + not dll.hash.sha256 : ( + /* HP DOT4 printer driver family FPs (Dot4.sys, Dot4Prt.sys, Dot4usb.sys, Dot4Scan.sys) */ + "f21c1d478180bc5e932bb2c2e4618e3ed463ca87acedeb139682d218435f82f1", + "7e2f2a139e897eae56038b920bda9381094bc0ae9e626f6634e6b444b8b0c91f", + "12ffdf5f48a79b1b4adbb88ba2cb6c59dd6719554e8ea6beefe99b3e3c66f1ac", + "dbc6afaf80141e2480e19878f581edfe9c2b018da2ec527c4025ff04d5587afd", + /* (dc3d.sys, test-signed) */ + "ca8f9564733ded4c3895cf7150bb254995d66889e6be08d6654e4f897e4ff7a4" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Sub-technique: +** Name: Invalid Code Signature +** ID: T1036.001 +** Reference URL: https://attack.mitre.org/techniques/T1036/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-unusual-parent-child-relationship.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-unusual-parent-child-relationship.asciidoc new file mode 100644 index 0000000000..1f07adb86f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-unusual-parent-child-relationship.asciidoc @@ -0,0 +1,220 @@ +[[prebuilt-rule-8-19-27-unusual-parent-child-relationship]] +=== Unusual Parent-Child Relationship + +Identifies Windows programs run from unexpected parent processes. This could indicate masquerading or other strange activity on a system. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/sbousseaden/Slides/blob/master/Hunting%20MindMaps/PNG/Windows%20Processes%20TH.map.png +* https://www.andreafortuna.org/2017/06/15/standard-windows-processes-a-brief-reference/ +* https://www.elastic.co/security-labs/elastic-security-labs-steps-through-the-r77-rootkit + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike + +*Version*: 323 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Unusual Parent-Child Relationship* + + +Windows internal/system processes have some characteristics that can be used to spot suspicious activities. One of these characteristics is parent-child relationships. These relationships can be used to baseline the typical behavior of the system and then alert on occurrences that don't comply with the baseline. + +This rule uses this information to spot suspicious parent and child processes. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Investigate any abnormal behavior by the subject process such as network connections, registry or file modifications, and any spawned child processes. +- Examine the host for derived artifacts that indicate suspicious activities: + - Analyze the process executable using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. +- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the target host after the registry modification. + + + +*False positive analysis* + + +- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and +process.parent.name != null and process.parent.executable like ("?:\\*", "\\Device\\*") and + ( + /* suspicious parent processes */ + (process.name:"autochk.exe" and not process.parent.name:"smss.exe") or + (process.name:("fontdrvhost.exe", "dwm.exe") and not process.parent.name:("wininit.exe", "winlogon.exe", "dwm.exe")) or + (process.name:("consent.exe", "RuntimeBroker.exe", "TiWorker.exe") and not process.parent.name:("svchost.exe", "Workplace Container Helper.exe")) or + (process.name:"SearchIndexer.exe" and not process.parent.name:"services.exe") or + (process.name:"SearchProtocolHost.exe" and not process.parent.name:("SearchIndexer.exe", "dllhost.exe")) or + (process.name:"dllhost.exe" and not process.parent.name:("services.exe", "svchost.exe")) or + (process.name:"smss.exe" and not process.parent.name:("System", "smss.exe")) or + (process.name:"csrss.exe" and not process.parent.name:("smss.exe", "svchost.exe")) or + (process.name:"wininit.exe" and not process.parent.name:"smss.exe") or + (process.name:"winlogon.exe" and not process.parent.name:"smss.exe") or + (process.name:("lsass.exe", "LsaIso.exe") and not process.parent.name:"wininit.exe") or + (process.name:"LogonUI.exe" and not process.parent.name:("wininit.exe", "winlogon.exe")) or + (process.name:"services.exe" and not process.parent.name:"wininit.exe") or + (process.name:"svchost.exe" and not process.parent.name:("MsMpEng.exe", "services.exe", "svchost.exe")) or + (process.name:"spoolsv.exe" and not process.parent.name:("services.exe", "Workplace Starter.exe")) or + (process.name:"taskhost.exe" and not process.parent.name:("services.exe", "svchost.exe", "ngentask.exe")) or + (process.name:"taskhostw.exe" and not process.parent.name:("services.exe", "svchost.exe")) or + (process.name:"userinit.exe" and not process.parent.name:("dwm.exe", "winlogon.exe", "KUsrInit.exe")) or + (process.name:("wmiprvse.exe", "wsmprovhost.exe", "winrshost.exe") and not process.parent.name:"svchost.exe") or + /* suspicious child processes */ + (process.parent.name:("SearchProtocolHost.exe", "taskhost.exe", "csrss.exe") and not process.name:("werfault.exe", "wermgr.exe", "WerFaultSecure.exe", "conhost.exe", "ngentask.exe", "SearchProtocolHost.exe")) or + (process.parent.name:"autochk.exe" and not process.name:("chkdsk.exe", "doskey.exe", "WerFault.exe")) or + (process.parent.name:"smss.exe" and not process.name:("autochk.exe", "smss.exe", "csrss.exe", "wininit.exe", "winlogon.exe", "setupcl.exe", "WerFault.exe", "wpbbin.exe", "PvsVmBoot.exe", "SophosNA.exe", "omnissa-ic-nga.exe", "icarus_rvrt.exe", "poqexec.exe")) or + (process.parent.name:"wermgr.exe" and not process.name:("WerFaultSecure.exe", "wermgr.exe", "WerFault.exe") and + not (process.name:"rundll32.exe" and process.command_line : "*WerConCpl.dll*LaunchErcApp*")) or + (process.parent.name:"conhost.exe" and not process.name:("mscorsvw.exe", "wermgr.exe", "WerFault.exe", "WerFaultSecure.exe", "conhost.exe")) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Process Injection +** ID: T1055 +** Reference URL: https://attack.mitre.org/techniques/T1055/ +* Sub-technique: +** Name: Process Hollowing +** ID: T1055.012 +** Reference URL: https://attack.mitre.org/techniques/T1055/012/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Sub-technique: +** Name: Break Process Trees +** ID: T1036.009 +** Reference URL: https://attack.mitre.org/techniques/T1036/009/ +* Technique: +** Name: Access Token Manipulation +** ID: T1134 +** Reference URL: https://attack.mitre.org/techniques/T1134/ +* Sub-technique: +** Name: Parent PID Spoofing +** ID: T1134.004 +** Reference URL: https://attack.mitre.org/techniques/T1134/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-unusual-process-modifying-genai-configuration-file.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-unusual-process-modifying-genai-configuration-file.asciidoc new file mode 100644 index 0000000000..3e6aff143c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-unusual-process-modifying-genai-configuration-file.asciidoc @@ -0,0 +1,184 @@ +[[prebuilt-rule-8-19-27-unusual-process-modifying-genai-configuration-file]] +=== Unusual Process Modifying GenAI Configuration File + +Detects unusual modification of GenAI tool configuration files. Adversaries may inject malicious MCP server configurations to hijack AI agents for persistence, C2, or data exfiltration. Attack vectors include malware or scripts directly poisoning config files, supply chain attacks via compromised dependencies, and prompt injection attacks that abuse the GenAI tool itself to modify its own configuration. Unauthorized MCP servers added to these configs execute arbitrary commands when the AI tool is next invoked. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.file* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://modelcontextprotocol.io/ +* https://www.cybereason.com/blog/security-research/weaponized-ai-how-cybercriminals-exploit-mcp-for-account-takeover +* https://glama.ai/blog/2025-11-11-the-lethal-trifecta-securing-model-context-protocol-against-data-flow-attacks +* https://www.elastic.co/security-labs/elastic-advances-llm-security + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Persistence +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Domain: LLM + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Unusual Process Modifying GenAI Configuration File* + + +Configuration files for GenAI tools like Cursor, Claude, Copilot, and Ollama control which MCP servers, plugins, and extensions are loaded. Attackers target these files to inject malicious MCP servers that execute arbitrary commands, exfiltrate data, or establish persistence. Threats include external processes (malware, compromised scripts, supply chain attacks) directly modifying configs, as well as prompt injection attacks that abuse the AI tool's own file access capabilities. + + +*Possible investigation steps* + + +- Identify the process that modified the configuration file and determine if it's expected (GenAI tool, installer, user action) or suspicious (unknown script, malware). +- If the modifying process is NOT a GenAI tool, investigate its origin, parent process tree, and whether it was downloaded or executed from a suspicious location. +- If a GenAI tool made the modification, check recent user prompts or agent activity that may have triggered the config change via prompt injection. +- Review the contents of the modified configuration file for suspicious MCP server URLs, unauthorized plugins, or unusual agent permissions. +- Examine the process command line and parent process tree to identify how the modifying process was invoked. +- Check for other file modifications by the same process around the same time, particularly to other GenAI configs or startup scripts. +- Investigate whether the GenAI tool subsequently connected to unknown domains or spawned unusual child processes after the config change. + + +*False positive analysis* + + +- Novel but legitimate configuration changes will trigger this rule when the process hasn't been seen modifying these files within the configured history window. Review the modified file content to determine legitimacy. +- GenAI tool updates may modify config files in new ways; correlate with recent software updates. +- IDE extensions integrating with GenAI tools may modify configs as part of initial setup. +- Developer tools (git, go, npm) checking out or downloading projects containing `.gemini/` or `.claude/` directories may trigger alerts. These are project-level configs, not user configs - verify by checking if the path is within a project directory. + + +*Response and remediation* + + +- Review the modified configuration file and revert any unauthorized changes to MCP servers, plugins, or agent settings. +- If malicious MCP servers were added, block the associated domains at the network level. +- Review and rotate any API keys or credentials that may have been exposed through the compromised GenAI configuration. + + +==== Rule query + + +[source, js] +---------------------------------- +event.category : "file" and event.action : ("modification" or "overwrite") and +file.path : ( + */.cursor/mcp.json or */.cursor/settings.json or */AppData/Roaming/Cursor/*mcp* or + */.claude/* or */claude_desktop_config.json or */AppData/Roaming/Claude/* or + */.config/github-copilot/* or */AppData/Local/GitHub?Copilot/* or + */.ollama/config* or */AppData/Local/Ollama/* or + */.codex/* or */AppData/Roaming/Codex/* or + */.gemini/* or */AppData/Roaming/gemini-cli/* or + */.grok/* or */AppData/Roaming/Grok/* or + */.windsurf/* or */AppData/Roaming/Windsurf/* or + */.vscode/extensions/*mcp* or + */.openclaw/* or */AppData/Roaming/OpenClaw/* or + */.moltbot/* or */AppData/Roaming/Moltbot/* or + */.config/openclaw/* +) and not ( + file.extension : (lck or lock or log or png or marker or shm or wal or sqlite or sqlite-shm or sqlite-wal or jsonl or journal or xcuserstate) or + file.name : ( + .DS_Store or .last-cleanup or mcp-needs-auth-cache.json or policy-limits.json or + .claude.json.backup* or + *.tmp* + ) or + file.path : ( + */.claude/cache/* or + */.claude/statsig/* or + */.claude/sessions/* or + */.claude/shell-snapshots/* or + */.claude/plugins/* or + */.claude/worktrees/* or + */.gemini/antigravity-browser-profile/* or + */.gemini/tmp/* or + */.codex/.tmp/* or + */.codex/tmp/* or + */.codex/log/* or + */.codex/sessions/* or + */.cursor/extensions/* or + */.vscode/extensions/* or + */.vscode-oss/extensions/* or + */opt/homebrew/.claude/* or + */opt/homebrew/.cursor/* or + */opt/homebrew/.codex/* or + */node_modules/* or + */cargo/registry/* or + */go/pkg/mod/* + ) or + ( + file.path : (*/.codex/* or */.claude/* or */.gemini/*) and + file.extension : sqlite + ) or + ( + file.path : */.config/github-copilot/* and + file.name : (apps.json or versions.json or copilot*nitrite.db) + ) or + process.name : build-script-build or + ( + file.path : (*/.codex/.tmp/* or */.claude/plugins/* or */.claude/worktrees/* or */node_modules/* or */cargo/registry/* or */go/pkg/mod/*) and + file.extension : (h or out or part or rs or toml) + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Technique: +** Name: Compromise Host Software Binary +** ID: T1554 +** Reference URL: https://attack.mitre.org/techniques/T1554/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-web-server-cloud-metadata-ssrf-request.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-web-server-cloud-metadata-ssrf-request.asciidoc new file mode 100644 index 0000000000..ed01768d26 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-web-server-cloud-metadata-ssrf-request.asciidoc @@ -0,0 +1,159 @@ +[[prebuilt-rule-8-19-27-web-server-cloud-metadata-ssrf-request]] +=== Web Server Cloud Metadata SSRF Request + +Detects HTTP requests to web servers whose URL or query string references cloud instance metadata endpoints or equivalent encoded variants. Attackers exploit server-side request forgery (SSRF) vulnerabilities in web applications to reach link-local metadata services on AWS, GCP, Azure, and similar cloud providers and harvest temporary credentials, tokens, or instance details. + +*Rule type*: eql + +*Rule indices*: + +* logs-nginx.access-* +* logs-apache.access-* +* logs-apache_tomcat.access-* +* logs-iis.access-* +* logs-traefik.access-* +* logs-zeek.http-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://hackingthe.cloud/aws/general-knowledge/intro_metadata_service/ +* https://owasp.org/www-community/attacks/Server_Side_Request_Forgery + +*Tags*: + +* Domain: Web +* Domain: Cloud +* Domain: Network +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Initial Access +* Data Source: Nginx +* Data Source: Apache +* Data Source: Apache Tomcat +* Data Source: IIS +* Data Source: Traefik +* Data Source: Zeek +* Resources: Investigation Guide + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Web Server Cloud Metadata SSRF Request* + + +This alert flags inbound HTTP requests to a web server whose `url.original` or `url.query` contains cloud instance +metadata addresses, hostnames, or credential paths. A common attacker pattern is exploiting an SSRF vulnerability so +the application fetches `http://169.254.169.254/latest/meta-data/iam/security-credentials/` or equivalent GCP and Azure +metadata routes, then reuses the returned role credentials against cloud APIs. + + +*Possible investigation steps* + + +- Review `url.original`, `url.query`, `http.request.method`, `http.response.status_code`, and `source.ip` to identify + the injected metadata target, affected route, and whether the server returned a successful response. +- URL-decode the request repeatedly and inspect parameters for nested encodings, redirect chains, or wrapper URLs that + hide the metadata destination. +- Map the targeted endpoint to the backend handler and determine whether user-controlled input can influence outbound + HTTP requests from the application. +- Correlate with application, proxy, and outbound network logs around `@timestamp` for connections from the web server + process to `169.254.169.254`, `100.100.100.200`, `metadata.google.internal`, or Azure metadata hosts. +- Check cloud audit, sign-in, or token-issuance telemetry for use of instance role or managed identity credentials + shortly after the request. +- Pivot on `source.ip` and `user_agent.original` for related SSRF, scanning, or exploitation attempts across other web + hosts. + + +*False positive analysis* + + +- Security scanners, authorized penetration tests, or WAF validation may send metadata URLs in test payloads. Confirm the + activity aligns with an approved assessment window and source before closing as benign. +- Internal documentation, error pages, or security training content that echoes metadata URLs in query strings can + trigger the rule without an exploitable SSRF path. Verify the application does not perform outbound fetches based on + the matched input. + + +*Response and remediation* + + +- Block the offending `source.ip` at the WAF or reverse proxy and add virtual patches to reject requests containing + metadata addresses or credential paths. +- If exploitation is confirmed, isolate the affected application host, preserve access logs, and rotate any cloud role + or managed identity credentials that may have been exposed. +- Patch or remediate the SSRF vulnerability by enforcing strict outbound allowlists, blocking link-local and metadata + destinations, and validating user-supplied URLs. +- Enforce IMDSv2, hop limits, and least-privilege instance roles to reduce impact if metadata access succeeds. + + +==== Rule query + + +[source, js] +---------------------------------- +web where ( + url.original : ( + "*169.254.169.254*", "*169%2e254%2e169%2e254*", "*0xa9fea9fe*", "*0xa9.0xfe.0xa9.0xfe*", + "*2852039166*", "*0251.0376.0251.0376*", "*::ffff:169.254.169.254*", "*::ffff:a9fe:a9fe*", "*fd00:ec2::254*", + "*100.100.100.200*", "*169.254.170.2*", "*metadata.google.internal*", "*metadata.goog*", "*computeMetadata/v1*", + "*meta-data/iam/security-credentials*", "*meta-data%2Fiam%2Fsecurity-credentials*", + "*latest/meta-data*", "*latest/api/token*" + ) + or + url.query : ( + "*169.254.169.254*", "*169%2e254%2e169%2e254*", "*0xa9fea9fe*", "*0xa9.0xfe.0xa9.0xfe*", + "*2852039166*", "*0251.0376.0251.0376*", "*::ffff:169.254.169.254*", "*::ffff:a9fe:a9fe*", "*fd00:ec2::254*", + "*100.100.100.200*", "*169.254.170.2*", "*metadata.google.internal*", "*metadata.goog*", "*computeMetadata/v1*", + "*meta-data/iam/security-credentials*", "*meta-data%2Fiam%2Fsecurity-credentials*", + "*latest/meta-data*", "*latest/api/token*" + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Cloud Instance Metadata API +** ID: T1552.005 +** Reference URL: https://attack.mitre.org/techniques/T1552/005/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-web-server-potential-sql-injection-request.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-web-server-potential-sql-injection-request.asciidoc new file mode 100644 index 0000000000..14d0b0e5c7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-web-server-potential-sql-injection-request.asciidoc @@ -0,0 +1,238 @@ +[[prebuilt-rule-8-19-27-web-server-potential-sql-injection-request]] +=== Web Server Potential SQL Injection Request + +This rule detects potential SQL injection attempts in web server requests by identifying common SQL injection patterns in URLs. Such activity may indicate reconnaissance or exploitation attempts by attackers trying to manipulate backend databases or extract sensitive information. + +*Rule type*: eql + +*Rule indices*: + +* logs-nginx.access-* +* logs-apache.access-* +* logs-apache_tomcat.access-* +* logs-iis.access-* +* logs-traefik.access-* +* logs-zeek.http-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Web +* Domain: Network +* Use Case: Threat Detection +* Tactic: Reconnaissance +* Tactic: Credential Access +* Tactic: Persistence +* Tactic: Execution +* Tactic: Command and Control +* Data Source: Nginx +* Data Source: Apache +* Data Source: Apache Tomcat +* Data Source: IIS +* Data Source: Traefik +* Data Source: Zeek +* Resources: Investigation Guide + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Web Server Potential SQL Injection Request* + + +SQL injection (SQLi) attempts to manipulate backend database queries via unsanitized +input passed through web request parameters. This rule flags requests whose URL or +query string contains structural patterns characteristic of automated SQLi tooling +(sqlmap and similar) or manual exploitation techniques, spanning boolean-blind, +time-based, error-based, and UNION-based extraction methods across MySQL, MSSQL, +PostgreSQL, and Oracle syntax. + + +*Possible investigation steps* + + +- Identify the full request and response context: + - `url.original` / `url.query` — full injected payload + - `http.request.method`, `http.response.status_code` — was the request accepted (2xx) or rejected (4xx/5xx/WAF block)? + - `source.ip`, `source.as.organization.name`, `source.geo.*` — is this a known scanner IP, hosting/VPS ASN, or unexpected geography for this application's userbase? + - `user_agent.original` — check for tool signatures (`sqlmap`, `Assetnote`, `Nessus`, `Nuclei`, etc.) vs. a spoofed browser UA +- Determine which SQLi technique is present, since it changes the likely intent and next steps: + - **Boolean-blind** (`AND 1=1--`, `CASE WHEN...THEN...ELSE`) — attacker inferring true/false conditions one bit/char at a time; usually high request volume against the same parameter + - **Time-based blind** (`SLEEP`, `BENCHMARK`, `WAITFOR DELAY`, `pg_sleep`) — look for abnormal response latency on matching requests to confirm exploitation succeeded vs. was blocked + - **Error-based** (`EXTRACTVALUE`, `UPDATEXML`, `GTID_SUBSET`, `CONVERT(INT,...)`) — check `http.response.status_code`/body for a 500 or a reflected DB error message; if present, the attacker likely received leaked data directly + - **UNION-based** (`UNION SELECT NULL,...`, `UNION ALL SELECT...CONCAT(MD5(...`) — attacker is enumerating column count or confirming a reflection point to pull data directly into the page body + - **Stacked queries** (`;SELECT...`, `;EXEC xp_cmdshell`) — most severe; if the DB driver allows multiple statements, this can lead to command execution (`xp_cmdshell`) rather than just data disclosure +- Pivot on the target parameter and endpoint (e.g. `url.path`, the specific query-string key such as `id=`, `sort=`, `column=`) to see: + - How many distinct payloads/techniques were tried against the same parameter (suggests automated technique-fuzzing by a single tool run) + - Whether the same `source.ip` hit multiple endpoints/parameters (broader scan) or repeatedly refined one payload (targeted exploitation attempt) +- Check for a correlated spike in requests from the same IP/ASN in a tight time window — sqlmap and similar tools generate many rapid, near-identical requests when fuzzing technique/column count/character position. +- If the backend database technology is known, cross-check the payload's SQL dialect (MySQL vs. MSSQL vs. PostgreSQL functions) against what the application actually runs — a payload using the wrong dialect's functions will simply error out and fail, lowering severity. +- If available, correlate with database-side audit logs (e.g. MSSQL Audit `event.code: 33205`, slow query logs) for the same timeframe/client IP to confirm whether the payload actually reached and executed against the database. + + +*False positive analysis* + + +- **Vulnerability scanners and security tooling** are the most common source of noise: Assetnote, Burp Suite, Qualys, Nessus, Acunetix, and similar tools intentionally send these exact payloads as part of authorized scanning. Check `user_agent.original` for scanner signatures and cross-reference `source.ip`/ASN against your organization's known scanning infrastructure or third-party ASM vendor. +- Legitimate application traffic containing SQL-like keywords is rare given the specificity of these patterns (chained `CHAR()` calls, `ELT(n=n,1)` self-comparisons, hex-delimited `CONCAT`), but verify against applications that accept raw SQL fragments as legitimate input (e.g., internal admin/reporting tools with a "custom query" field) if any exist in your environment. +- Consider adding a suppression/exception for confirmed, recurring authorized scanning sources rather than tuning the query patterns themselves, to avoid reducing detection coverage against real attackers using the same tools. + + +*Response and remediation* + + +- If the request reached the application layer unblocked (`event.outcome: success` / 2xx response) and the payload matches an error-based or UNION-based technique, treat as a potential confirmed data exposure — check application/database logs for evidence of returned sensitive data. +- If a stacked-query or `xp_cmdshell` payload succeeded, escalate immediately — this can lead to OS-level command execution, not just data disclosure. +- Validate that the affected endpoint uses parameterized queries/prepared statements; SQL injection at this scale of tooling almost always indicates raw string concatenation in the query layer. +- If exploitation is confirmed, review the database account's privileges used by the web application (least privilege should prevent `xp_cmdshell`, `INFORMATION_SCHEMA` enumeration, or cross-database access even if injection succeeds). +- Block or rate-limit the source IP/ASN at the WAF or reverse proxy if not already filtered, and consider a virtual-patch WAF rule for the specific vulnerable parameter while the application fix is developed. +- Review other requests from the same source IP across the retention window for prior reconnaissance (e.g., directory enumeration, parameter fuzzing) that may have preceded the injection attempt. + + +==== Rule query + + +[source, js] +---------------------------------- +any where ( +url.original like~ ( + "*dbms_pipe.receive_message%28chr%*", + "*waitfor%20delay%20%270%3a0%3a*", + "*%28select%28sleep%285*", "*%28select%20*from%20pg_sleep%285*", "*%3bselect%20pg_sleep%285*", + "*and%20sleep%28*%29*", "*or%20sleep%28*%29*", "*case%20when*then%20sleep%28*", "*if%28sleep%28*%29*", + "*benchmark%28*%2c*md5%28*", + "*convert%28int%2c%28select%20char%28*", + "*char%28*char%28*char%28*char%28*", + "*concat%28concat%28char%28*", + "*case%20when%20%28*%3d*%29%20then*else*end*", + "*elt%28*%3d*%2c1%29%29*", + "*union%20select%20null%2cnull*", "*union%20all%20select%20null*", + "*union%20all%20select%20*concat%28md5%28*", + "*extractvalue%28*concat%280x*", "*updatexml%28*concat%280x*", + "*procedure%2f%2a%2a%2fanalyse%28extractvalue%28*", + "*gtid_subset%28concat%280x*", "*gtid_subtract%28concat%280x*", + "*mid%28ifnull%28session_user%28%29*", + "*'qq'%2b%28%28select%20@@version%29%29%2b'qq'*", + "*%27%20or%20%271%27%3d%271*", "*%22%20or%20%221%22%3d%221*", "*%27%20or%20%27a%27%3d%27a*", + "*and%201%3d1--*", "*and%201%3d2--*", + "*%29%3bselect*if%28%28ord%28mid%28*", + "*xp_cmdshell*", + "*select%20*into%20outfile*", "*select%20*into%20dumpfile*", + "*load_file%28*", "*load%5ffile%28*", + "*select%20*from%20information_schema.tables*", "*from%20information_schema.columns%20where%20table_schema*", + "*dbms_pipe%2ereceive_message*", "*dbms_lock%2esleep*", + "*select%20@@version*", "*select%20user%28%29*", "*select%20current_user%28%29*", "*select%20database%28%29*", + "*sp_executesql%20*exec%20*", "*xp_dirtree*" + ) + or + url.query like~ ( + "*dbms_pipe.receive_message(chr*", + "*waitfor delay '0:0:*", + "*(select(sleep(5*", "*(select*from pg_sleep(5*", "*;select pg_sleep(5*", + "*and sleep(*)*", "*or sleep(*)*", "*case when*then sleep(*", "*if(sleep(*)*", + "*benchmark(*,*md5(*", + "*convert(int,(select char(*", + "*char(*char(*char(*char(*", + "*concat(concat(char(*", + "*case when (*=*) then*else*end*", + "*elt(*=*,1))*", + "*union select null,null*", "*union all select null*", + "*union all select*concat(md5(*", + "*extractvalue(*concat(0x*", "*updatexml(*concat(0x*", + "*procedure/**/analyse(extractvalue(*", + "*gtid_subset(concat(0x*", "*gtid_subtract(concat(0x*", + "*mid(ifnull(session_user()*", + "*'qq'+((select @@version))+'qq'*", + "*' or '1'='1*", "*\" or \"1\"=\"1*", "*' or 'a'='a*", + "*and 1=1--*", "*and 1=2--*", + "*);select*if((ord(mid(*", + "*xp_cmdshell*", + "*select*into outfile*", "*select*into dumpfile*", + "*load_file(*", + "*select*from information_schema.tables*", "*from information_schema.columns where table_schema*", + "*dbms_pipe.receive_message*", "*dbms_lock.sleep*", + "*select @@version*", "*select user()*", "*select current_user()*", "*select database()*", + "*sp_executesql*exec*", "*xp_dirtree*" + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Server Software Component +** ID: T1505 +** Reference URL: https://attack.mitre.org/techniques/T1505/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Tactic: +** Name: Reconnaissance +** ID: TA0043 +** Reference URL: https://attack.mitre.org/tactics/TA0043/ +* Technique: +** Name: Active Scanning +** ID: T1595 +** Reference URL: https://attack.mitre.org/techniques/T1595/ +* Sub-technique: +** Name: Vulnerability Scanning +** ID: T1595.002 +** Reference URL: https://attack.mitre.org/techniques/T1595/002/ +* Sub-technique: +** Name: Wordlist Scanning +** ID: T1595.003 +** Reference URL: https://attack.mitre.org/techniques/T1595/003/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-xdg-open-command-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-xdg-open-command-execution.asciidoc new file mode 100644 index 0000000000..e1441ccb8f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rule-8-19-27-xdg-open-command-execution.asciidoc @@ -0,0 +1,120 @@ +[[prebuilt-rule-8-19-27-xdg-open-command-execution]] +=== XDG-Open Command Execution + +This rule monitors for the execution of the xdg-open process that is typically used to open documents and URLs in the user's preferred desktop application. Attackers may use this command to trick users into opening malicious documents or URLs to gain access to the target system. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* +* logs-auditd_manager.auditd-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Data Source: Auditd Manager + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "executed", "process_started", "ProcessRollup2") and ( + process.name == "xdg-open" or + process.args in ("/bin/xdg-open", "/usr/bin/xdg-open", "/usr/local/bin/xdg-open", "xdg-open") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: User Execution +** ID: T1204 +** Reference URL: https://attack.mitre.org/techniques/T1204/ +* Sub-technique: +** Name: Malicious Link +** ID: T1204.001 +** Reference URL: https://attack.mitre.org/techniques/T1204/001/ +* Sub-technique: +** Name: Malicious File +** ID: T1204.002 +** Reference URL: https://attack.mitre.org/techniques/T1204/002/ +* Sub-technique: +** Name: Malicious Copy and Paste +** ID: T1204.004 +** Reference URL: https://attack.mitre.org/techniques/T1204/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rules-8-19-27-appendix.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rules-8-19-27-appendix.asciidoc new file mode 100644 index 0000000000..9c51c92944 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rules-8-19-27-appendix.asciidoc @@ -0,0 +1,83 @@ +["appendix",role="exclude",id="prebuilt-rule-8-19-27-prebuilt-rules-8-19-27-appendix"] += Downloadable rule update v8.19.27 + +This section lists all updates associated with version 8.19.27 of the Fleet integration *Prebuilt Security Detection Rules*. + + +include::prebuilt-rule-8-19-27-web-server-cloud-metadata-ssrf-request.asciidoc[] +include::prebuilt-rule-8-19-27-genai-cli-started-with-unsafe-permission-bypass.asciidoc[] +include::prebuilt-rule-8-19-27-web-server-potential-sql-injection-request.asciidoc[] +include::prebuilt-rule-8-19-27-aws-iam-account-password-policy-deleted.asciidoc[] +include::prebuilt-rule-8-19-27-aws-lambda-function-invoked-by-an-unusual-principal.asciidoc[] +include::prebuilt-rule-8-19-27-aws-lambda-function-invoked-cross-account.asciidoc[] +include::prebuilt-rule-8-19-27-aws-lambda-function-invoked-from-an-unusual-source-asn.asciidoc[] +include::prebuilt-rule-8-19-27-aws-ecr-repository-or-registry-policy-granted-public-access.asciidoc[] +include::prebuilt-rule-8-19-27-aws-backup-recovery-point-deleted.asciidoc[] +include::prebuilt-rule-8-19-27-aws-backup-vault-deleted-or-vault-lock-removed.asciidoc[] +include::prebuilt-rule-8-19-27-aws-kms-imported-key-material-deleted.asciidoc[] +include::prebuilt-rule-8-19-27-aws-lambda-function-high-frequency-invocation-by-a-single-principal.asciidoc[] +include::prebuilt-rule-8-19-27-aws-iam-user-console-login-from-multiple-geolocations.asciidoc[] +include::prebuilt-rule-8-19-27-aws-iam-login-profile-created-or-modified-for-an-iam-user.asciidoc[] +include::prebuilt-rule-8-19-27-aws-sagemaker-notebook-lifecycle-configuration-with-suspicious-script-content.asciidoc[] +include::prebuilt-rule-8-19-27-aws-iam-inline-policy-added-to-a-group.asciidoc[] +include::prebuilt-rule-8-19-27-aws-iam-permissions-boundary-modified-or-removed.asciidoc[] +include::prebuilt-rule-8-19-27-azure-ad-graph-access-with-unusual-user-and-asn.asciidoc[] +include::prebuilt-rule-8-19-27-gke-secret-get-or-list-with-suspicious-user-agent.asciidoc[] +include::prebuilt-rule-8-19-27-gke-secrets-list-from-unusual-source-as-organization.asciidoc[] +include::prebuilt-rule-8-19-27-gke-api-request-failure-burst-by-user.asciidoc[] +include::prebuilt-rule-8-19-27-gke-suspicious-self-subject-review-via-service-account.asciidoc[] +include::prebuilt-rule-8-19-27-gke-user-exec-into-pod.asciidoc[] +include::prebuilt-rule-8-19-27-gke-admission-webhook-created-or-modified.asciidoc[] +include::prebuilt-rule-8-19-27-gke-cluster-admin-role-binding-created-or-modified.asciidoc[] +include::prebuilt-rule-8-19-27-gke-container-created-with-excessive-linux-capabilities.asciidoc[] +include::prebuilt-rule-8-19-27-gke-pod-created-with-hostipc.asciidoc[] +include::prebuilt-rule-8-19-27-gke-pod-created-with-hostnetwork.asciidoc[] +include::prebuilt-rule-8-19-27-gke-pod-created-with-hostpid.asciidoc[] +include::prebuilt-rule-8-19-27-gke-privileged-pod-created.asciidoc[] +include::prebuilt-rule-8-19-27-gke-pod-created-with-a-sensitive-hostpath-volume.asciidoc[] +include::prebuilt-rule-8-19-27-shell-execution-via-elastic-endpoint.asciidoc[] +include::prebuilt-rule-8-19-27-network-connection-followed-by-file-creation.asciidoc[] +include::prebuilt-rule-8-19-27-shared-object-load-via-lolbin.asciidoc[] +include::prebuilt-rule-8-19-27-potential-proxy-execution-via-systemd-run.asciidoc[] +include::prebuilt-rule-8-19-27-linux-external-ip-address-discovery-via-curl.asciidoc[] +include::prebuilt-rule-8-19-27-suspicious-command-execution-via-busybox-proxy.asciidoc[] +include::prebuilt-rule-8-19-27-payload-downloaded-by-interpreter-and-piped-to-interpreter.asciidoc[] +include::prebuilt-rule-8-19-27-xdg-open-command-execution.asciidoc[] +include::prebuilt-rule-8-19-27-systemd-service-override-configuration-file-created.asciidoc[] +include::prebuilt-rule-8-19-27-potential-privilege-escalation-via-a-suspicious-uid-change.asciidoc[] +include::prebuilt-rule-8-19-27-potential-privilege-escalation-via-a-parent-process-sequence.asciidoc[] +include::prebuilt-rule-8-19-27-potential-privilege-escalation-via-a-parent-child-process-sequence.asciidoc[] +include::prebuilt-rule-8-19-27-potential-icmp-tunneling-activity-to-the-internet.asciidoc[] +include::prebuilt-rule-8-19-27-icmp-redirect-message-from-internal-host.asciidoc[] +include::prebuilt-rule-8-19-27-deprecated-tls-version-or-weak-cipher-negotiated-externally.asciidoc[] +include::prebuilt-rule-8-19-27-icmp-timestamp-or-information-request-from-the-internet.asciidoc[] +include::prebuilt-rule-8-19-27-potential-dhcp-starvation-via-high-client-mac-cardinality.asciidoc[] +include::prebuilt-rule-8-19-27-smb-windows-file-sharing-activity-from-the-internet.asciidoc[] +include::prebuilt-rule-8-19-27-splunk-enterprise-postgresql-backup-to-restore-potential-rce-sequence.asciidoc[] +include::prebuilt-rule-8-19-27-splunk-enterprise-postgresql-recovery-endpoint-injection-artifacts.asciidoc[] +include::prebuilt-rule-8-19-27-potential-ssh-reverse-port-forwarding.asciidoc[] +include::prebuilt-rule-8-19-27-protected-storage-service-access-via-smb.asciidoc[] +include::prebuilt-rule-8-19-27-potential-dns-exfiltration-via-excessive-chunked-queries.asciidoc[] +include::prebuilt-rule-8-19-27-potential-sql-injection-against-microsoft-sql-server.asciidoc[] +include::prebuilt-rule-8-19-27-genai-process-accessing-sensitive-files.asciidoc[] +include::prebuilt-rule-8-19-27-unusual-process-modifying-genai-configuration-file.asciidoc[] +include::prebuilt-rule-8-19-27-multiple-alerts-in-different-att-ck-tactics-on-a-single-host.asciidoc[] +include::prebuilt-rule-8-19-27-microsoft-graph-request-email-access-by-unusual-user-and-client.asciidoc[] +include::prebuilt-rule-8-19-27-entra-id-oauth-device-code-phishing-via-aitm.asciidoc[] +include::prebuilt-rule-8-19-27-kubernetes-secret-get-or-list-from-node-or-pod-service-account.asciidoc[] +include::prebuilt-rule-8-19-27-base64-decoded-payload-piped-to-interpreter.asciidoc[] +include::prebuilt-rule-8-19-27-suspicious-child-execution-via-web-server.asciidoc[] +include::prebuilt-rule-8-19-27-persistence-via-suspicious-launch-agent-or-launch-daemon.asciidoc[] +include::prebuilt-rule-8-19-27-ipsec-nat-traversal-port-activity.asciidoc[] +include::prebuilt-rule-8-19-27-rdp-remote-desktop-protocol-from-the-internet.asciidoc[] +include::prebuilt-rule-8-19-27-smtp-to-the-internet-on-port-26-tcp.asciidoc[] +include::prebuilt-rule-8-19-27-first-time-seen-dns-query-to-rmm-domain.asciidoc[] +include::prebuilt-rule-8-19-27-potential-dns-tunneling-via-nslookup.asciidoc[] +include::prebuilt-rule-8-19-27-multiple-remote-management-tool-vendors-on-same-host.asciidoc[] +include::prebuilt-rule-8-19-27-first-time-seen-remote-monitoring-and-management-tool.asciidoc[] +include::prebuilt-rule-8-19-27-suspicious-screenconnect-client-child-process.asciidoc[] +include::prebuilt-rule-8-19-27-credential-acquisition-via-registry-hive-dumping.asciidoc[] +include::prebuilt-rule-8-19-27-untrusted-driver-loaded.asciidoc[] +include::prebuilt-rule-8-19-27-suspicious-kerberos-authentication-ticket-request.asciidoc[] +include::prebuilt-rule-8-19-27-unusual-parent-child-relationship.asciidoc[] +include::prebuilt-rule-8-19-27-privileges-elevation-via-parent-process-pid-spoofing.asciidoc[] diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rules-8-19-27-summary.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rules-8-19-27-summary.asciidoc new file mode 100644 index 0000000000..b51f8d94fd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-27/prebuilt-rules-8-19-27-summary.asciidoc @@ -0,0 +1,166 @@ +[[prebuilt-rule-8-19-27-prebuilt-rules-8-19-27-summary]] +[role="xpack"] +== Update v8.19.27 + +This section lists all updates associated with version 8.19.27 of the Fleet integration *Prebuilt Security Detection Rules*. + + +[width="100%",options="header"] +|============================================== +|Rule |Description |Status |Version + +|<> | Detects HTTP requests to web servers whose URL or query string references cloud instance metadata endpoints or equivalent encoded variants. Attackers exploit server-side request forgery (SSRF) vulnerabilities in web applications to reach link-local metadata services on AWS, GCP, Azure, and similar cloud providers and harvest temporary credentials, tokens, or instance details. | new | 1 + +|<> | Identifies GenAI agent CLIs started with permission-bypass or auto-approval flags that disable human-in-the-loop guardrails. These modes are intended for isolated sandboxes but are frequently misused on internet-connected developer workstations, allowing prompt injection, compromised dependencies, or malicious skills to execute commands, modify files, or reach sensitive paths without confirmation. | new | 1 + +|<> | This rule detects potential SQL injection attempts in web server requests by identifying common SQL injection patterns in URLs. Such activity may indicate reconnaissance or exploitation attempts by attackers trying to manipulate backend databases or extract sensitive information. | new | 4 + +|<> | Identifies deletion of the AWS account password policy via DeleteAccountPasswordPolicy. The account password policy enforces minimum password requirements (length, complexity, rotation, and reuse) for all IAM users in the account. Deleting it removes those requirements account-wide, weakening authentication and easing follow-on credential-based attacks. This is an account-level change that legitimately occurs only during deliberate administration, so its deletion by an unexpected principal warrants review. | new | 1 + +|<> | Identifies the first time within the prior 14 days that a principal directly invokes an AWS Lambda function in an account, excluding invocations made on behalf of AWS services (normal event-source triggers). Adversaries who compromise credentials or move laterally may directly invoke functions to execute code, retrieve data returned by a function, or abuse an over-permissioned execution role. Direct, ad hoc invocation by a principal that does not normally call Lambda deviates from the usual event-driven invocation pattern and is worth reviewing. This rule relies on AWS Lambda data event logging, which is not enabled by default. | new | 1 + +|<> | Identifies an AWS Lambda function invoked by a principal whose AWS account differs from the account that owns the function (a cross-account invocation). The caller's account is parsed from the invoking principal's ARN and compared to the function account. Adversaries who have been granted invoke permission on a function from an external account, or who operate from a separate attacker-controlled account, can use cross-account invocation to execute functions or retrieve the data they return. This is the data-plane counterpart to detecting the cross-account grant itself, and relies on AWS Lambda data event logging, which is not enabled by default. | new | 2 + +|<> | Identifies an AWS Lambda function invoked directly by a principal from a source network (ASN) not seen for that principal in the prior 10 days, excluding common cloud provider networks. Direct invocation from an unfamiliar external network can indicate use of stolen execution-role or user credentials from attacker-controlled infrastructure to execute functions or retrieve the data they return. This rule relies on AWS Lambda data event logging, which is not enabled by default. | new | 1 + +|<> | Detects when an Amazon ECR repository or registry policy is modified to grant public access using a wildcard principal (Principal:"*") statement. This rule analyzes SetRepositoryPolicy and PutRegistryPolicy events whose policy document grants an Allow effect to a wildcard ("*") principal, indicating that pull (and potentially push) permissions were extended to all identities, including unauthenticated users. A public container registry can expose proprietary images and any secrets baked into their layers, and, if push is allowed, enables supply-chain implantation. Public ECR access is sometimes intentional for image distribution, so the granting principal and the permissions should be validated. | new | 1 + +|<> | Identifies deletion of an AWS Backup recovery point via DeleteRecoveryPoint. A recovery point is a stored backup of a protected resource (EBS, RDS, DynamoDB, EFS, S3, and others). Deleting recovery points removes the ability to restore the associated data and is a core anti-recovery technique used in ransomware and data-destruction attacks to ensure victims cannot recover without paying or rebuilding. Routine lifecycle expirations are performed by the AWS Backup service itself; deletion by a non-service principal is rare and should be reviewed. | new | 1 + +|<> | Identifies deletion of an AWS Backup vault or removal of its Vault Lock configuration via DeleteBackupVault or DeleteBackupVaultLockConfiguration. A backup vault stores recovery points, and Vault Lock enforces WORM (write-once, read-many) immutability that prevents recovery points from being deleted before their retention expires. Removing the lock defeats the primary control designed to stop ransomware from destroying backups, and deleting the vault removes the backup container entirely. Both actions are strong anti-recovery signals and are rare in normal operations. | new | 1 + +|<> | Identifies deletion of imported key material from an AWS KMS customer managed key via DeleteImportedKeyMaterial. Keys created with an external key material origin (BYOK) rely on key material that the customer imports. Deleting that material immediately makes the key unusable and renders all data encrypted under it inaccessible, with no recovery window. Unlike ScheduleKeyDeletion, which enforces a pending deletion period of 7 to 30 days, this action takes effect instantly, making it an attractive primitive for cloud ransomware and data-destruction attacks. Because this operation only applies to external-origin keys and is rare in normal operations, its use by an unexpected principal warrants prompt review. | new | 1 + +|<> | Identifies a single principal directly invoking AWS Lambda functions at a high volume within a one-hour window. Adversaries may drive excessive invocations to abuse functions for resource hijacking or cryptomining, to inflate costs in a denial-of-wallet attack, or to enumerate function behavior. This is a volumetric heuristic: the threshold is environment-dependent and high-throughput applications can exceed it, so tune it to the deployment. This rule relies on AWS Lambda data event logging, which is not enabled by default. | new | 2 + +|<> | Identifies an IAM user that successfully signs in to the AWS Management Console from two or more distinct countries within a short window. A single user authenticating from multiple geographic locations in a brief period is physically implausible and indicates that the account's credentials or console session are being used from more than one place at once. This is a hallmark of adversary-in-the-middle (AiTM) phishing and session theft, where the legitimate user signs in from their location while the attacker replays the captured session or credentials from their own infrastructure. Because the attacker logs in from a different network, the divergent sign-in geolocations are the detectable signal even when MFA appears satisfied (AiTM relays the live MFA challenge). This is the CloudTrail-native analog of identity-provider impossible-travel sign-in detections. | new | 2 + +|<> | Identifies creation or modification of a console login profile for an AWS IAM user via CreateLoginProfile or UpdateLoginProfile. A login profile enables password-based console sign-in for an IAM user. Adversaries who obtain programmatic credentials may create a login profile to add persistent interactive console access, or update an existing profile to reset another user's password and take over the account, even after the original access keys are rotated. Because console access for IAM users is increasingly provisioned through federation or IAM Identity Center, direct use of these APIs by an unexpected principal warrants review. This rule targets IAM users (the userName parameter is present); creation of a login profile for the account root user is covered by a separate rule. | new | 1 + +|<> | Identifies an Amazon SageMaker notebook lifecycle configuration whose OnStart or OnCreate script, after base64 decoding, contains patterns associated with malicious activity such as reverse shells, EC2 instance metadata (IMDS) credential access, or download-and-execute commands. A lifecycle configuration runs as root on the notebook instance, so a script with these patterns is a strong indicator of an attempt to backdoor the notebook, steal the execution role's credentials, or establish persistent code execution. This rule decodes the script in the request and matches high-signal indicators; it is a higher-fidelity companion to the rule that alerts on any lifecycle configuration change. | new | 1 + +|<> | Identifies an inline policy added to an IAM group via PutGroupPolicy. An inline policy attached to a group grants its permissions to every current and future member of that group. Adversaries can abuse this to escalate privileges (grant elevated permissions to a group they belong to, or will add themselves to) and to establish persistence through a durable, membership-based grant that is easy to overlook. Group inline policies are uncommon compared to managed-policy attachments, so their creation by an unexpected principal warrants review. | new | 1 + +|<> | Identifies the modification or removal of an IAM permissions boundary on an IAM user or role. A permissions boundary caps the maximum permissions an identity can have, regardless of its attached identity policies. An adversary who can delete a boundary ("DeleteUserPermissionsBoundary", "DeleteRolePermissionsBoundary") or replace it with a more permissive one ("PutUserPermissionsBoundary", "PutRolePermissionsBoundary") can lift that cap and unlock permissions the identity's policies already grant, enabling privilege escalation. Boundary changes are infrequent and usually performed by a small set of administrators or infrastructure-as-code pipelines, so changes by unexpected principals warrant review. | new | 1 + +|<> | Identifies Azure AD Graph (graph.windows.net) requests originating from network sources outside the major public-cloud and Microsoft ASNs that legitimate first-party callers normally come from. Adversary tooling typically rides on commodity hosting (residential ISPs, VPS providers, anonymisers) which produces an ASN distribution very different from the Microsoft / AWS / GCP / Akamai / Cloudflare ranges that dominate legitimate AAD Graph traffic. | new | 1 + +|<> | Detects successful GKE secret get or list operations where the user agent matches scripting runtimes, minimal HTTP clients, or offensive-distribution fingerprints rather than typical kubectl or controller traffic. | new | 1 + +|<> | Detects the first time a human GKE caller lists secrets cluster-wide or in default or kube-system from a source autonomous system that is not attributed to common cloud provider organizations. This can indicate remote secret enumeration using stolen credentials from an unusual network. | new | 1 + +|<> | Detects bursts of failed GKE API requests from a single user identity within a five-minute window. Repeated authorization failures across multiple actions can indicate credential stuffing, RBAC probing, or reconnaissance with stolen tokens. | new | 1 + +|<> | Detects GKE service account or node identities invoking self-subject access or rules review APIs. Non-human identities rarely enumerate their own permissions outside known controllers; this can indicate stolen tokens probing effective RBAC. | new | 1 + +|<> | Detects the first occurrence of a non-system GKE identity establishing an exec session into a pod. kubectl exec enables interactive command execution inside workloads and is a common post-compromise technique to access secrets and expand access. | new | 1 + +|<> | Detects creation or modification of GKE mutating or validating admission webhook configurations by non-system identities. Malicious webhooks can inject workloads, block security tooling, or intercept API traffic for persistence and defense evasion. | new | 1 + +|<> | Detects creation or modification of a GKE ClusterRoleBinding that grants the cluster-admin ClusterRole, providing unrestricted cluster access and enabling rapid privilege escalation or persistence. | new | 1 + +|<> | Detects GKE pod creation with dangerous Linux capabilities that are commonly abused in container escape techniques. Standalone pods are included; controller-owned ReplicaSet, DaemonSet, and StatefulSet workloads are excluded. | new | 1 + +|<> | Detects GKE pod create, update, or patch events that enable host IPC namespace sharing. This exposes host inter-process communication mechanisms and can support privilege escalation. Controller-owned workloads are excluded. | new | 1 + +|<> | Detects GKE pod create, update, or patch events that enable host network namespace sharing. HostNetwork grants access to the node network stack and can bypass namespace network policies. System identities and controller-owned workloads are excluded. | new | 1 + +|<> | Detects GKE pod create, update, or patch events that enable host PID namespace sharing. HostPID exposes host processes and can support privilege escalation, especially with ptrace or privileged containers. System identities and controller-owned workloads are excluded. | new | 1 + +|<> | Detects successful GKE audit events where a pod is created with allowPrivilegeEscalation enabled. This weakens container isolation and can help an attacker escalate toward host access. Standalone pods are included; workloads owned by ReplicaSet, DaemonSet, or StatefulSet controllers are excluded. | new | 1 + +|<> | Detects GKE pod create, update, or patch events that mount sensitive hostPath volumes such as the root filesystem, kubelet paths, or container runtime sockets. This can enable container escape and credential theft. System identities and controller-owned workloads are excluded. | new | 1 + +|<> | This rule detects shell executions via Elastic Endpoint. Elastic Endpoint has a built-in response action console that can be used to execute shell commands on compromised systems. | new | 1 + +|<> | Detects network connections originating from a binary located in a potentially suspicious location, followed by a file creation event. This behavior is consistent with C2 agents such as Poseidon and Athena, connecting to a C2 framework such as Mythic. The agent polls the C2 for commands through a web request, after which the command gets executed. | new | 1 + +|<> | This rule detects when a process not commonly used to load shared objects, is executed with arguments that load a shared object file. This technique can load a malicious shared object into memory while attempting to evade detection. | new | 1 + +|<> | This rule detects the execution of a command or binary through the systemd-run binary. Systemd-run can schedule commands to be executed in the background through systemd. Attackers may use this technique to execute commands while attempting to evade detection. | new | 1 + +|<> | Detects applications making a curl request to a known public IP address lookup web service. Malware tends to perform this action to assess potential targets. | new | 1 + +|<> | This rule detects the execution of command line arguments capable of spawning shells or establishing network connections through Busybox. This technique can be used to execute commands while attempting to evade detection. | new | 1 + +|<> | This rule detects when a payload is downloaded by an interpreter, and piped to an interpreter. Attackers may use this technique to download and execute payloads for various malicious purposes, such as establishing persistence or exfiltrating data. | new | 1 + +|<> | This rule monitors for the execution of the xdg-open process that is typically used to open documents and URLs in the user's preferred desktop application. Attackers may use this command to trick users into opening malicious documents or URLs to gain access to the target system. | new | 1 + +|<> | This rule detects the creation or renaming of a new Systemd override configuration file in any of the Systemd service locations for both root and regular users. Systemd override configuration files are configuration files in Linux systems used to override the default Systemd service configuration for a specific service. Malicious actors can leverage systemd override configuration files to achieve persistence by creating or modifying services to execute malicious commands or payloads during system startup or at a predefined interval by adding a systemd timer. This allows them to maintain unauthorized access, execute additional malicious activities, or evade detection. | new | 1 + +|<> | Detects a potential privilege escalation sequence via a suspicious UID change sequence. This rule checks for non-root execution of a process executable in a user or world-writable directory followed by a UID change event to 0 (root). This sequence is indicative of a potential local privilege escalation exploit. | new | 1 + +|<> | Detects a potential privilege escalation sequence via a parent process relationship. This rule checks for non-root execution of a process executable in a user or world-writable directory followed by a UID change event to 0 (root). This sequence is indicative of a potential local privilege escalation exploit. | new | 1 + +|<> | Detects a potential privilege escalation sequence via a parent/child process relationship. This rule checks for non-root execution of a parent process executable in a user or world-writable directory by a non-root user followed by a UID change event to 0 (root) by the child process. This sequence is indicative of a potential local privilege escalation exploit. | new | 1 + +|<> | Identifies ICMP Echo traffic from an internal host to an external destination with a larger-than-typical transaction size. Covert channels and ICMP tunneling tools embed data in echo payloads that exceed normal OS ping behavior, which is usually limited to small fixed-size packets. | new | 1 + +|<> | Identifies ICMP Redirect messages (type 5 for IPv4, type 137 for IPv6) sourced from an internal IPv4 or IPv6 address. Legitimate redirects are normally sent only by on-path routers. A workstation or server emitting redirects can indicate route manipulation for adversary-in-the-middle activity. | new | 1 + +|<> | Identifies successful outbound TLS sessions that negotiate deprecated protocol versions (SSLv3, TLS 1.0, or TLS 1.1) or weak cipher suites such as RC4, 3DES, NULL, EXPORT, or anonymous Diffie-Hellman. Adversaries-in-the-middle and legacy malware often force these negotiations to decrypt or intercept traffic. Modern clients and services should negotiate TLS 1.2 or 1.3 with strong ciphers on internet-bound connections. | new | 1 + +|<> | Identifies inbound ICMP Timestamp (type 13) or Information (type 15) requests from external addresses to internal RFC1918 destinations. These message types are rarely used in modern networks and are commonly associated with host and path fingerprinting during reconnaissance. | new | 1 + +|<> | Identifies a burst of DHCP DISCOVER messages with an unusually high number of distinct client hardware addresses observed on the same capture segment within a short window. Attackers flood DISCOVER requests with spoofed or random MAC addresses to exhaust the DHCP lease pool, often as a precursor to deploying a rogue DHCP server. | new | 1 + +|<> | This rule detects network events that may indicate inbound Windows file sharing (SMB or CIFS) traffic originating from the Internet. SMB should never be directly reachable from the Internet, as it is a primary target for exploitation by threat actors seeking initial access. Inbound SMB from a public IP is a direct precondition for attacks such as EternalBlue (MS17-010) and related SMB remote code execution vulnerabilities. | new | 1 + +|<> | Detects a POST to the Splunk Enterprise PostgreSQL backup endpoint followed by a POST to the restore endpoint from the same client to the same host within a 15-minute window. This sequence is unusual and can align with the public CVE-2026-20253 pre-authentication RCE chain, where an attacker stages a database dump via the backup path and executes attacker-controlled SQL via the restore path. | new | 1 + +|<> | Detects CVE-2026-20253 exploit artifacts against the Splunk Enterprise PostgreSQL sidecar recovery endpoints via complementary signals. Where endpoint or Network Packet Capture request-body logging is available, the rule matches PostgreSQL connection-string injection keywords, suspicious `backupFile` destinations, and known filesystem artifacts used to pivot from backup/restore primitives to file write or RCE. It also detects vulnerable recovery endpoint probing and empty-password Basic auth credentials observed in public exploit tooling. | new | 1 + +|<> | Identifies the use of Windows OpenSSH or Plink to create a reverse SSH port forward or reverse dynamic SOCKS proxy. Adversaries may abuse reverse forwarding to expose an internal service or proxy listener through an external SSH server, establishing an outbound tunnel that bypasses direct inbound connectivity controls. | new | 1 + +|<> | Identifies remote access to the Windows Protected Storage Service through the IPC$ share. Attackers may abuse this named pipe to interact with the Protected Storage Service and extract sensitive credentials, certificates, or DPAPI backup keys. | new | 1 + +|<> | Identifies potential DNS exfiltration on Windows hosts by detecting a high volume of DNS queries whose subdomain labels follow a chunked encoding pattern (index-payload.base_domain). Attackers split stolen data across many DNS queries to evade volume-based detection; this rule aggregates queries per process, base domain, and five-minute window and flags sessions with many distinct chunk indices and sufficiently long encoded payloads. | new | 1 + +|<> | Identifies potential SQL injection attempts against Microsoft SQL Server by detecting obfuscated T-SQL patterns in SQL Server Audit events. Attackers use CHAR concatenation, CONVERT-based subqueries, and CASE/UNION constructs to bypass input validation and extract data or execute unauthorized statements. | new | 2 + +|<> | Detects when GenAI tools access sensitive files such as cloud credentials, SSH keys, browser password databases, or shell configurations. Attackers leverage GenAI agents to systematically locate and exfiltrate credentials, API keys, and tokens. Access to credential stores (.aws/credentials, .ssh/id_*) suggests harvesting, while writes to shell configs (.bashrc, .zshrc) indicate persistence attempts. Note: On linux only creation events are available. Access events are not yet implemented. | update | 8 + +|<> | Detects unusual modification of GenAI tool configuration files. Adversaries may inject malicious MCP server configurations to hijack AI agents for persistence, C2, or data exfiltration. Attack vectors include malware or scripts directly poisoning config files, supply chain attacks via compromised dependencies, and prompt injection attacks that abuse the GenAI tool itself to modify its own configuration. Unauthorized MCP servers added to these configs execute arbitrary commands when the AI tool is next invoked. | update | 7 + +|<> | This rule uses alert data to determine when multiple alerts in different phases of an attack involving the same host are triggered. Analysts can use this to prioritize triage and response, as these hosts are more likely to be compromised. | update | 7 + +|<> | Identifies access to email resources via Microsoft Graph API using an first-party application on behalf of a user principal. This behavior may indicate an adversary using a phished OAuth refresh token or a Primary Refresh Token (PRT) to access email resources. The pattern includes requests to Microsoft Graph API endpoints related to email, such as /me/mailFolders/inbox/messages or /users/{user_id}/messages, using a public client application ID and a user principal object ID. This is a New Terms rule that only signals if the application ID and user principal object ID have not been seen doing this activity in the last 14 days. | update | 7 + +|<> | Detects successful Microsoft Entra ID sign-ins that use the OAuth device code authentication protocol with the Microsoft Authentication Broker client requesting first-party Office API resources (Exchange Online, Microsoft Graph, or SharePoint) while flagged as interactive. This pattern is associated with adversary-in-the-middle (AiTM) phishing kits such as Tycoon 2FA, where victims complete device code flows that ultimately broker tokens for mail and collaboration APIs. | update | 2 + +|<> | Kubernetes audit identities for kubelet (`system:node:*`) and workloads (`system:serviceaccount:*`) are meant to operate with tight, predictable API usage. Direct `get` or `list` on the Secrets API from those principals is often a sign of credential access. Attackers who stole a pod service-account token or node credentials sweep Secret objects for tokens, registry credentials, TLS keys, or application configuration. Even denied attempts still reveal intent to reach sensitive material. Legitimate controllers do read secrets they mount or manage, so this signal is most valuable when paired with triage (namespace scope, user agent, RBAC, and whether the identity should touch those secret names at all). | update | 3 + +|<> | This rule detects when a base64 decoded payload is piped to an interpreter on Linux systems. Adversaries may use base64 encoding to obfuscate data and pipe it to an interpreter to execute malicious code. This technique may be used to evade detection by host- or network-based security controls. | update | 8 + +|<> | Identifies suspicious child processes executed via a web server, which may suggest a vulnerability and remote shell access. Attackers may exploit a vulnerability in a web application to execute commands via a web server, or place a backdoor file that can be abused to gain code execution as a mechanism for persistence. | update | 116 + +|<> | Identifies the creation of a launch agent or daemon property list file containing abnormal or suspicious values. An adversary may establish persistence by installing a new launch agent or daemon which executes at login. This rule looks for plist files created in LaunchAgents/LaunchDaemons directories with paths commonly used by malware. | update | 2 + +|<> | This rule detects outbound IPSEC NAT Traversal (NAT-T) tunnels established from an internal host to an external destination. IPSEC is a VPN technology that allows one system to talk to another using encrypted tunnels. NAT Traversal encapsulates IPSEC ESP traffic in UDP and, once a NAT device is detected, both peers float to UDP port 4500 for the tunnel data channel. The rule keys on this NAT-T signature, UDP traffic where both the source and destination port are 4500, from an internal source to an external destination, rather than on any UDP traffic to port 4500. This may be common on your network, but this technique is also used by threat actors to tunnel command and control or exfiltration traffic over the Internet to avoid detection. | update | 112 + +|<> | This rule detects network events that may indicate the use of RDP traffic from the Internet. RDP is commonly used by system administrators to remotely control a system for maintenance or to use shared resources. 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. | update | 112 + +|<> | This rule detects events that may indicate use of SMTP on TCP port 26 from an internal host to an external destination. This port is commonly used by several popular mail transfer agents to deconflict with the default SMTP port 25. This port has also been used by a malware family called BadPatch for command and control of Windows systems. The rule is scoped to outbound traffic (internal source to external destination) to focus on the command and control and exfiltration use cases, rather than benign internal mail relays or unrelated transit traffic observed by the sensor. | update | 113 + +|<> | Detects DNS queries to commonly abused remote monitoring and management (RMM) or remote access software domains from processes that are not browsers. Intended to surface RMM clients, scripts, or other non-browser activity contacting these services. | update | 5 + +|<> | This rule identifies a large number (15) of nslookup.exe executions with an explicit query type from the same host. This may indicate command and control activity utilizing the DNS protocol. | update | 317 + +|<> | Identifies a Windows host where two or more distinct remote monitoring and management (RMM) or remote-access tool vendors are observed starting processes within the same eight-minute window. Legitimate MSP environments may run multiple tools, but this pattern can also indicate compromise, shadow IT, or attacker staging of redundant access. Processes are mapped to a single vendor label so multiple binaries from the same vendor do not inflate the count. | update | 4 + +|<> | Adversaries may install legitimate remote monitoring and management (RMM) tools or remote access software on compromised endpoints for command-and-control (C2), persistence, and execution of native commands. This rule detects when a process is started whose name or code signature matches commonly abused RMM or remote access tools. New Terms type: the host.id and process.name pair has not been seen before within the configured 7-day history window. | update | 118 + +|<> | Identifies suspicious processes being spawned by the ScreenConnect client processes. This activity may indicate execution abusing unauthorized access to the ScreenConnect remote access software. | update | 316 + +|<> | Identifies attempts to export a registry hive which may contain credentials using the Windows reg.exe tool. | update | 318 + +|<> | Identifies an untrusted driver loaded by the Windows kernel. Adversaries may modify code signing policies to enable execution of unsigned or self-signed kernel code. | update | 15 + +|<> | Correlates network connections to the standard Kerberos port by an unusual process from the source machine with a Kerberos authentication ticket request from the target domain controller. | update | 6 + +|<> | Identifies Windows programs run from unexpected parent processes. This could indicate masquerading or other strange activity on a system. | update | 323 + +|<> | Identifies parent process spoofing used to create an elevated child process. Adversaries may spoof the parent process identifier (PPID) of a new process to evade process-monitoring defenses or to elevate privileges. | update | 13 + +|============================================== diff --git a/docs/detections/prebuilt-rules/prebuilt-rules-downloadable-updates.asciidoc b/docs/detections/prebuilt-rules/prebuilt-rules-downloadable-updates.asciidoc index ca4d2308c3..90b8eea614 100644 --- a/docs/detections/prebuilt-rules/prebuilt-rules-downloadable-updates.asciidoc +++ b/docs/detections/prebuilt-rules/prebuilt-rules-downloadable-updates.asciidoc @@ -13,6 +13,10 @@ For previous rule updates, please navigate to the https://www.elastic.co/guide/e |Update version |Date | New rules | Updated rules | Notes +|<> | 07 Jul 2026 | 55 | 22 | +This release includes new rules for Linux, AWS, GCP, Windows, Azure, Network Traffic, and Elastic Defend. New rules for Linux include detection for command and control, privilege escalation, execution, discovery, persistence, and defense evasion. New rules for AWS include detection for impact, persistence, execution, privilege escalation, defense evasion, initial access, and exfiltration. New rules for GCP include detection for privilege escalation, credential access, persistence, discovery, and execution. New rules for Windows include detection for command and control, exfiltration, credential access, and initial access. New rules for Azure include detection for persistence and initial access. New rules for Network Traffic include detection for initial access, credential access, discovery, command and control, and impact. New rules for Elastic Defend include detection for defense evasion. Additionally, significant tuning for Linux, Windows, macOS, Kubernetes, Microsoft 365, and network rules improves efficacy and performance. + + |<> | 25 Jun 2026 | 44 | 44 | This release includes new rules for AWS, Windows, Azure, Microsoft 365, Azure AD Graph, Network Packet Capture, and Network Traffic. New rules for AWS include detection for persistence, defense evasion, impact, discovery, and execution. New rules for Windows include detection for command and control, defense evasion, and execution. New rules for Azure include detection for lateral movement, execution, and credential access. New rules for Microsoft 365 include detection for initial access, persistence, and credential access. New rules for Azure AD Graph include detection for discovery. New rules for Network Packet Capture include detection for persistence and initial access. New rules for Network Traffic include detection for credential access. Additionally, significant tuning for Linux, Windows, macOS, Azure, Google Workspace, and network rules improves efficacy and performance. @@ -143,3 +147,4 @@ include::downloadable-packages/8-19-23/prebuilt-rules-8-19-23-summary.asciidoc[l include::downloadable-packages/8-19-24/prebuilt-rules-8-19-24-summary.asciidoc[leveloffset=+1] include::downloadable-packages/8-19-25/prebuilt-rules-8-19-25-summary.asciidoc[leveloffset=+1] include::downloadable-packages/8-19-26/prebuilt-rules-8-19-26-summary.asciidoc[leveloffset=+1] +include::downloadable-packages/8-19-27/prebuilt-rules-8-19-27-summary.asciidoc[leveloffset=+1] diff --git a/docs/detections/prebuilt-rules/prebuilt-rules-reference.asciidoc b/docs/detections/prebuilt-rules/prebuilt-rules-reference.asciidoc index 9e9eff057e..47bf816a75 100644 --- a/docs/detections/prebuilt-rules/prebuilt-rules-reference.asciidoc +++ b/docs/detections/prebuilt-rules/prebuilt-rules-reference.asciidoc @@ -24,6 +24,10 @@ and their rule type is `machine_learning`. |<> |Detects successful `AssumeRoleWithWebIdentity` where the caller identity is a Kubernetes service account and the source autonomous system organization is present but not `Amazon.com, Inc.` EKS workloads that obtain IAM credentials via IAM Roles for Service Accounts (IRSA) normally reach STS from AWS-managed or AWS-associated networks; the same identity from a clearly external ASN can indicate a stolen or misused projected service-account token being exchanged for IAM credentials off-cluster. |[Domain: Cloud], [Domain: Identity], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS CloudTrail], [Use Case: Threat Detection], [Tactic: Initial Access], [Resources: Investigation Guide] |None |2 +|<> |Identifies deletion of an AWS Backup recovery point via DeleteRecoveryPoint. A recovery point is a stored backup of a protected resource (EBS, RDS, DynamoDB, EFS, S3, and others). Deleting recovery points removes the ability to restore the associated data and is a core anti-recovery technique used in ransomware and data-destruction attacks to ensure victims cannot recover without paying or rebuilding. Routine lifecycle expirations are performed by the AWS Backup service itself; deletion by a non-service principal is rare and should be reviewed. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Backup], [Use Case: Threat Detection], [Tactic: Impact], [Resources: Investigation Guide] |None |1 + +|<> |Identifies deletion of an AWS Backup vault or removal of its Vault Lock configuration via DeleteBackupVault or DeleteBackupVaultLockConfiguration. A backup vault stores recovery points, and Vault Lock enforces WORM (write-once, read-many) immutability that prevents recovery points from being deleted before their retention expires. Removing the lock defeats the primary control designed to stop ransomware from destroying backups, and deleting the vault removes the backup container entirely. Both actions are strong anti-recovery signals and are rare in normal operations. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Backup], [Use Case: Threat Detection], [Tactic: Impact], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |1 + |<> |Identifies AWS Bedrock Agent creation performed directly by an IAM user or the root account. Bedrock Agents are autonomous AI systems that execute multi-step tasks, invoke Lambda action groups to call external APIs, and query knowledge bases. Adversaries with access to an AWS account can create rogue agents configured to exfiltrate data via action group Lambda functions, pivot to other services, or act as a persistent AI-driven command-and-control channel. This rule is scoped to IAMUser and Root identity types — AssumedRole sessions (which represent automated CI/CD pipelines and SSO-federated engineers) are excluded to avoid global false positives from legitimate deployment automation that varies widely across customer environments. |[Domain: Cloud], [Domain: LLM], [Data Source: AWS], [Data Source: AWS CloudTrail], [Data Source: Amazon Web Services], [Data Source: Amazon Bedrock], [Use Case: Threat Detection], [Tactic: Persistence], [Resources: Investigation Guide] |None |1 |<> |Detects modification of deployed Amazon Bedrock agents and their action groups, collaborators, or aliases via the Bedrock Agent control plane. Adversaries with access to an AWS account can tamper with an existing, trusted agent by altering its instructions (UpdateAgent), adding or changing action groups that wire the agent to Lambda functions or APIs (CreateAgentActionGroup, UpdateAgentActionGroup), attaching or modifying collaborators (AssociateAgentCollaborator, UpdateAgentCollaborator), or repointing an alias to a tampered version (CreateAgentAlias, UpdateAgentAlias). A PrepareAgent call is required to make a tampered configuration live. By implanting malicious behavior into an agent that legitimate users continue to invoke, an attacker can maintain durable access through a trusted component. Creation of brand-new agents (CreateAgent) is intentionally excluded as lower-signal activity. |[Domain: Cloud], [Domain: LLM], [Data Source: AWS], [Data Source: AWS CloudTrail], [Data Source: Amazon Web Services], [Data Source: Amazon Bedrock], [Use Case: Threat Detection], [Resources: Investigation Guide], [Tactic: Persistence] |None |1 @@ -148,6 +152,8 @@ and their rule type is `machine_learning`. |<> |Identifies discovery request DescribeInstanceAttribute with the attribute userData and instanceId in AWS CloudTrail logs. This may indicate an attempt to retrieve user data from an EC2 instance. Adversaries may use this information to gather sensitive data from the instance such as hardcoded credentials or to identify potential vulnerabilities. This is a New Terms rule that identifies the first time an IAM user or role requests the user data for a specific EC2 instance. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: Amazon EC2], [Resources: Investigation Guide], [Use Case: Log Auditing], [Tactic: Discovery] |None |9 +|<> |Detects when an Amazon ECR repository or registry policy is modified to grant public access using a wildcard principal (Principal:"*") statement. This rule analyzes SetRepositoryPolicy and PutRegistryPolicy events whose policy document grants an Allow effect to a wildcard ("*") principal, indicating that pull (and potentially push) permissions were extended to all identities, including unauthenticated users. A public container registry can expose proprietary images and any secrets baked into their layers, and, if push is allowed, enables supply-chain implantation. Public ECR access is sometimes intentional for image distribution, so the granting principal and the permissions should be validated. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS ECR], [Use Case: Threat Detection], [Tactic: Exfiltration], [Resources: Investigation Guide] |None |1 + |<> |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. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS EFS], [Tactic: Impact], [Resources: Investigation Guide] |None |212 |<> |Detects when the AmazonEKSClusterAdminPolicy or AmazonEKSAdminPolicy is associated with a principal via the EKS Access Entries API. This grants full cluster-admin equivalent access to the specified IAM user or role. Unlike the legacy aws-auth ConfigMap which is only visible in Kubernetes audit logs, Access Entries modifications appear in CloudTrail, providing an additional detection surface. Attackers who have obtained IAM permissions to manage EKS access entries can use this API to backdoor cluster access for persistence, mapping attacker-controlled IAM identities to cluster-admin privileges without modifying any Kubernetes resources. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS CloudTrail], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Tactic: Persistence], [Resources: Investigation Guide] |None |1 @@ -166,6 +172,8 @@ and their rule type is `machine_learning`. |<> |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. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS CloudTrail], [Data Source: AWS IAM], [Data Source: AWS STS], [Tactic: Persistence], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |7 +|<> |Identifies deletion of the AWS account password policy via DeleteAccountPasswordPolicy. The account password policy enforces minimum password requirements (length, complexity, rotation, and reuse) for all IAM users in the account. Deleting it removes those requirements account-wide, weakening authentication and easing follow-on credential-based attacks. This is an account-level change that legitimately occurs only during deliberate administration, so its deletion by an unexpected principal warrants review. |[Domain: Cloud], [Domain: Identity], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS IAM], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |1 + |<> |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. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS IAM], [Use Case: Identity and Access Audit], [Tactic: Privilege Escalation], [Tactic: Persistence], [Resources: Investigation Guide] |None |9 |<> |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. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS IAM], [Use Case: Identity and Access Audit], [Tactic: Privilege Escalation], [Tactic: Persistence], [Resources: Investigation Guide] |None |9 @@ -188,14 +196,20 @@ and their rule type is `machine_learning`. |<> |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. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS IAM], [Tactic: Impact], [Resources: Investigation Guide] |None |212 +|<> |Identifies an inline policy added to an IAM group via PutGroupPolicy. An inline policy attached to a group grants its permissions to every current and future member of that group. Adversaries can abuse this to escalate privileges (grant elevated permissions to a group they belong to, or will add themselves to) and to establish persistence through a durable, membership-based grant that is easy to overlook. Group inline policies are uncommon compared to managed-policy attachments, so their creation by an unexpected principal warrants review. |[Domain: Cloud], [Domain: Identity], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS IAM], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Tactic: Persistence], [Resources: Investigation Guide] |None |1 + |<> |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. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS IAM], [Use Case: Identity and Access Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |7 |<> |Identifies when an AWS IAM login profile is added to a user. Adversaries may add a login profile to an IAM user who typically does not have one and is used only for programmatic access. This can be used to maintain access to the account even if the original access key is rotated or disabled. This is a building block rule and does not generate alerts on its own. It is meant to be used for correlation with other rules to detect suspicious activity. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS IAM], [Use Case: Identity and Access Audit], [Tactic: Persistence], [Rule Type: BBR] |None |5 +|<> |Identifies creation or modification of a console login profile for an AWS IAM user via CreateLoginProfile or UpdateLoginProfile. A login profile enables password-based console sign-in for an IAM user. Adversaries who obtain programmatic credentials may create a login profile to add persistent interactive console access, or update an existing profile to reset another user's password and take over the account, even after the original access keys are rotated. Because console access for IAM users is increasingly provisioned through federation or IAM Identity Center, direct use of these APIs by an unexpected principal warrants review. This rule targets IAM users (the userName parameter is present); creation of a login profile for the account root user is covered by a separate rule. |[Domain: Cloud], [Domain: Identity], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS IAM], [Use Case: Identity and Access Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |1 + |<> |Identifies the first time, within the configured history window, that a long-term IAM access key ID (prefix AKIA) is used successfully from a given source.ip in AWS CloudTrail. Long-term access keys belong to IAM users or the account root user. They are a common target after credential theft or leakage, including supply-chain and exposed-key scenarios. Temporary security credentials (prefix ASIA) and console sessions are excluded so the signal emphasizes programmatic access patterns. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS CloudTrail], [Data Source: AWS IAM], [Use Case: Threat Detection], [Tactic: Credential Access], [Tactic: Initial Access], [Resources: Investigation Guide] |None |2 |<> |Detects when an uncommon user or role creates an OpenID Connect (OIDC) Identity Provider in AWS IAM. OIDC providers enable web identity federation, allowing users authenticated by external identity providers (such as Google, GitHub, or custom OIDC-compliant providers) to assume IAM roles and access AWS resources. Adversaries who have gained administrative access may create rogue OIDC providers to establish persistent, federated access that survives credential rotation. This technique allows attackers to assume roles using tokens from an IdP they control. While OIDC provider creation is benign in some environments, it should still be validated against authorized infrastructure changes. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS IAM], [Use Case: Identity and Access Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |3 +|<> |Identifies the modification or removal of an IAM permissions boundary on an IAM user or role. A permissions boundary caps the maximum permissions an identity can have, regardless of its attached identity policies. An adversary who can delete a boundary ("DeleteUserPermissionsBoundary", "DeleteRolePermissionsBoundary") or replace it with a more permissive one ("PutUserPermissionsBoundary", "PutRolePermissionsBoundary") can lift that cap and unlock permissions the identity's policies already grant, enabling privilege escalation. Boundary changes are infrequent and usually performed by a small set of administrators or infrastructure-as-code pipelines, so changes by unexpected principals warrant review. |[Domain: Cloud], [Domain: Identity], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS IAM], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |1 + |<> |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. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS IAM], [Use Case: Identity and Access Audit], [Resources: Investigation Guide], [Tactic: Discovery], [Tactic: Credential Access] |None |216 |<> |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. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS IAM], [Use Case: Identity and Access Audit], [Tactic: Persistence], [Resources: Investigation Guide] |None |9 @@ -210,6 +224,8 @@ and their rule type is `machine_learning`. |<> |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. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Use Case: Identity and Access Audit], [Tactic: Credential Access], [Tactic: Persistence], [Resources: Investigation Guide] |None |215 +|<> |Identifies an IAM user that successfully signs in to the AWS Management Console from two or more distinct countries within a short window. A single user authenticating from multiple geographic locations in a brief period is physically implausible and indicates that the account's credentials or console session are being used from more than one place at once. This is a hallmark of adversary-in-the-middle (AiTM) phishing and session theft, where the legitimate user signs in from their location while the attacker replays the captured session or credentials from their own infrastructure. Because the attacker logs in from a different network, the divergent sign-in geolocations are the detectable signal even when MFA appears satisfied (AiTM relays the live MFA challenge). This is the CloudTrail-native analog of identity-provider impossible-travel sign-in detections. |[Domain: Cloud], [Domain: Identity], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Sign-In], [Use Case: Identity and Access Audit], [Tactic: Initial Access], [Tactic: Credential Access], [Resources: Investigation Guide] |None |2 + |<> |An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by creating a new set of credentials for an existing user. This rule looks for use of the IAM `CreateAccessKey` API operation to create new programmatic access keys for another IAM user. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS IAM], [Use Case: Identity and Access Audit], [Tactic: Privilege Escalation], [Tactic: Persistence], [Resources: Investigation Guide] |None |13 |<> |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. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS CloudTrail], [Data Source: AWS IAM], [Tactic: Persistence], [Use Case: Identity and Access Audit], [Resources: Investigation Guide] |None |5 @@ -226,6 +242,10 @@ and their rule type is `machine_learning`. |<> |Identifies the deletion of an AWS Lambda function. Deleting a function removes its code, configuration, versions, and aliases. Adversaries may delete functions to disrupt business operations and automated workflows, to destroy attacker-deployed backdoors and remove evidence after achieving their objective, or to inhibit incident response. Because function deletion is destructive and often irreversible without redeployment, deletions performed by unexpected principals or outside change windows should be reviewed. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Lambda], [Use Case: Threat Detection], [Tactic: Impact], [Resources: Investigation Guide] |None |1 +|<> |Identifies a single principal directly invoking AWS Lambda functions at a high volume within a one-hour window. Adversaries may drive excessive invocations to abuse functions for resource hijacking or cryptomining, to inflate costs in a denial-of-wallet attack, or to enumerate function behavior. This is a volumetric heuristic: the threshold is environment-dependent and high-throughput applications can exceed it, so tune it to the deployment. This rule relies on AWS Lambda data event logging, which is not enabled by default. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS CloudTrail], [Data Source: AWS Lambda], [Use Case: Threat Detection], [Tactic: Impact], [Resources: Investigation Guide] |None |2 + +|<> |Identifies an AWS Lambda function invoked by a principal whose AWS account differs from the account that owns the function (a cross-account invocation). The caller's account is parsed from the invoking principal's ARN and compared to the function account. Adversaries who have been granted invoke permission on a function from an external account, or who operate from a separate attacker-controlled account, can use cross-account invocation to execute functions or retrieve the data they return. This is the data-plane counterpart to detecting the cross-account grant itself, and relies on AWS Lambda data event logging, which is not enabled by default. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Lambda], [Use Case: Threat Detection], [Tactic: Execution], [Resources: Investigation Guide] |None |2 + |<> |Identifies the first time within the prior 14 days that a principal directly invokes an AWS Lambda function in an account, excluding invocations made on behalf of AWS services (normal event-source triggers). Adversaries who compromise credentials or move laterally may directly invoke functions to execute code, retrieve data returned by a function, or abuse an over-permissioned execution role. Direct, ad hoc invocation by a principal that does not normally call Lambda deviates from the usual event-driven invocation pattern and is worth reviewing. This rule relies on AWS Lambda data event logging, which is not enabled by default. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Lambda], [Use Case: Threat Detection], [Tactic: Execution], [Resources: Investigation Guide] |None |1 |<> |Identifies an AWS Lambda function invoked directly by a principal from a source network (ASN) not seen for that principal in the prior 10 days, excluding common cloud provider networks. Direct invocation from an unfamiliar external network can indicate use of stolen execution-role or user credentials from attacker-controlled infrastructure to execute functions or retrieve the data they return. This rule relies on AWS Lambda data event logging, which is not enabled by default. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Lambda], [Use Case: Threat Detection], [Tactic: Execution], [Resources: Investigation Guide] |None |1 @@ -334,6 +354,8 @@ and their rule type is `machine_learning`. |<> |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). |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS STS], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Privilege Escalation], [Tactic: Lateral Movement], [Resources: Investigation Guide] |None |6 +|<> |Identifies an Amazon SageMaker notebook lifecycle configuration whose OnStart or OnCreate script, after base64 decoding, contains patterns associated with malicious activity such as reverse shells, EC2 instance metadata (IMDS) credential access, or download-and-execute commands. A lifecycle configuration runs as root on the notebook instance, so a script with these patterns is a strong indicator of an attempt to backdoor the notebook, steal the execution role's credentials, or establish persistent code execution. This rule decodes the script in the request and matches high-signal indicators; it is a higher-fidelity companion to the rule that alerts on any lifecycle configuration change. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS SageMaker], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Execution], [Resources: Investigation Guide] |None |1 + |<> |Identifies rapid secret retrieval activity from AWS Secrets Manager using the GetSecretValue or BatchGetSecretValue API actions. Adversaries who compromise an IAM user, instance role, or temporary credentials may attempt to enumerate or exfiltrate secrets in bulk to escalate privileges, move laterally, or gain persistence. This rule detects 20 or more unique secret retrievals by the same user identity within a short time window, which may indicate credential compromise or automated secret harvesting. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Secrets Manager], [Tactic: Credential Access], [Resources: Investigation Guide] |None |8 |<> |Identifies sensitive AWS IAM operations performed via AWS CloudShell based on the user agent string. CloudShell is a browser-based shell that provides command-line access to AWS resources directly from the AWS Management Console. While convenient for administrators, CloudShell access from compromised console sessions can enable attackers to perform privileged operations without installing tools or using programmatic credentials. This rule detects high-risk actions such as creating IAM users, access keys, roles, or attaching policies when initiated from CloudShell, which may indicate post-compromise credential harvesting or privilege escalation activity. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS CloudTrail], [Data Source: AWS IAM], [Tactic: Persistence], [Tactic: Privilege Escalation], [Use Case: Threat Detection], [Resources: Investigation Guide] |None |3 @@ -504,6 +526,8 @@ and their rule type is `machine_learning`. |<> |Identifies Azure AD Graph (graph.windows.net) requests where the combination of calling OAuth client ("azure.aadgraphactivitylogs.properties.app_id") and signed-in user ("user.id") has not been observed in the tenant in a historical window. A user appearing against AAD Graph under an OAuth client that has not previously authenticated that user is a sign of a FOCI swap, a phished refresh token being redeemed for a new client, or an adversary running tooling under a client identity the user does not normally use. |[Domain: Cloud], [Data Source: Azure], [Data Source: Azure AD Graph], [Data Source: Azure AD Graph Activity Logs], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Discovery], [Resources: Investigation Guide] |None |1 +|<> |Identifies Azure AD Graph (graph.windows.net) requests originating from network sources outside the major public-cloud and Microsoft ASNs that legitimate first-party callers normally come from. Adversary tooling typically rides on commodity hosting (residential ISPs, VPS providers, anonymisers) which produces an ASN distribution very different from the Microsoft / AWS / GCP / Akamai / Cloudflare ranges that dominate legitimate AAD Graph traffic. |[Domain: Cloud], [Data Source: Azure], [Data Source: Azure AD Graph], [Data Source: Azure AD Graph Activity Logs], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Tactic: Initial Access], [Resources: Investigation Guide] |None |1 + |<> |Detects an unusually high ratio of 4xx HTTP responses from Azure AD Graph (graph.windows.net) per calling identity in a short window. Post-identity compromise leading to recon often leaves a tail of 403s and 404s as tooling walks endpoints it does not have permission for, asks for object IDs it does not have, or uses an OAuth client that has been pulled off the AAD Graph allow-list. Surges or an unexpected ratio of 4xx responses concentrated on a single (user and ASN) pair are characteristic of automated tooling rather than human or first-party traffic. |[Domain: Cloud], [Data Source: Azure], [Data Source: Azure AD Graph], [Data Source: Azure AD Graph Activity Logs], [Use Case: Threat Detection], [Tactic: Discovery], [Resources: Investigation Guide] |None |1 |<> |Detects an Azure AD Graph (graph.windows.net) burst from a user-agent identifying as "aiohttp" (the default HTTP library used by ROADrecon's "gather" command) where a single calling identity issues many requests in a short window. ROADrecon walks every interesting directory object type via aiohttp, producing a large volume of requests from one user / source IP / UA triple. The combination of "aiohttp" UA with a burst threshold is a structural ROADrecon signature; legitimate first-party Microsoft components do not identify as aiohttp. |[Domain: Cloud], [Data Source: Azure], [Data Source: Azure AD Graph], [Data Source: Azure AD Graph Activity Logs], [Use Case: Threat Detection], [Tactic: Discovery], [Resources: Investigation Guide] |None |1 @@ -596,6 +620,8 @@ and their rule type is `machine_learning`. |<> |Identifies the deletion of a Network Watcher in Azure. Network Watchers are used to monitor, diagnose, view metrics, and enable or disable logs for resources in an Azure virtual network. An adversary may delete a Network Watcher in an attempt to evade defenses. |[Domain: Cloud], [Data Source: Azure], [Use Case: Network Security Monitoring], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |109 +|<> |Identifies a successful write to an Azure virtual machine resource ("MICROSOFT.COMPUTE/VIRTUALMACHINES/WRITE"). This operation is the parent action behind VM userData injection, where an adversary with VM contributor rights writes a base64 startup payload into the VM "userData" field that executes on the next reboot (a control-plane persistence technique requiring no guest access). The Azure activity log does not record the "userData" value or which property changed, so this behavior is indistinguishable from any other VM write at detection time. This is a building block rule and does not generate alerts on its own; it captures the VM write population so it can be correlated with other signals and baselined over time to tune a higher-fidelity userData-injection detection. To investigate a candidate, retrieve the live "userData" from the VM with an Azure Resource Manager GET using "$expand=userData". |[Domain: Cloud], [Domain: Endpoint], [Data Source: Azure], [Data Source: Azure Activity Logs], [Use Case: Asset Visibility], [Tactic: Persistence], [Rule Type: BBR] |None |1 + |<> |Detects execution of bpftool commands used to detach eBPF programs or links, or to delete or modify eBPF maps. These actions can disable, alter, or interfere with kernel-level instrumentation and enforcement mechanisms implemented through eBPF. In environments relying on eBPF-based networking, observability, or security controls, unexpected use of these operations may indicate defense evasion or runtime tampering. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Threat: Rootkit], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Auditd Manager], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |2 |<> |Detects execution of bpftool commands used to load, attach, run, or pin eBPF programs, as well as create or update eBPF maps and links. These operations interact directly with the Linux eBPF subsystem and can modify kernel-level behavior. While commonly used by legitimate networking or observability tooling, unexpected or interactive usage may indicate eBPF-based rootkit activity, policy tampering, or unauthorized kernel instrumentation. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Defense Evasion], [Threat: Rootkit], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Auditd Manager], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |2 @@ -606,7 +632,7 @@ and their rule type is `machine_learning`. |<> |Base16 and Base32 are encoding schemes that convert binary data into text, making it easier to transmit and store. This rule monitors for Base16 or Base32 encoding and decoding activity on Linux systems. Attackers may use these encoding schemes to obfuscate malicious payloads, evade detection, and facilitate data exfiltration. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Auditd Manager], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |216 -|<> |This rule detects when a base64 decoded payload is piped to an interpreter on Linux systems. Adversaries may use base64 encoding to obfuscate data and pipe it to an interpreter to execute malicious code. This technique may be used to evade detection by host- or network-based security controls. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Execution], [Data Source: Elastic Defend], [Resources: Investigation Guide], [Data Source: Crowdstrike] |None |7 +|<> |This rule detects when a base64 decoded payload is piped to an interpreter on Linux systems. Adversaries may use base64 encoding to obfuscate data and pipe it to an interpreter to execute malicious code. This technique may be used to evade detection by host- or network-based security controls. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Execution], [Data Source: Elastic Defend], [Resources: Investigation Guide], [Data Source: Crowdstrike] |None |8 |<> |Both ~/.bash_profile and ~/.bashrc are files containing shell commands that are run when Bash is invoked. These files are executed in a user's context, either interactively or non-interactively, when a user logs in so that their environment is set correctly. Adversaries may abuse this to establish persistence by executing malicious content triggered by a user’s shell. |[Domain: Endpoint], [OS: macOS], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |108 @@ -702,7 +728,7 @@ and their rule type is `machine_learning`. |<> |This rule detects the execution of TruffleHog, a tool used to search for high-entropy strings and secrets in code repositories, which may indicate an attempt to access credentials. This tool was abused by the Shai-Hulud worm to search for credentials in code repositories. |[Domain: Endpoint], [OS: Linux], [OS: Windows], [OS: macOS], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender XDR], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Data Source: Auditd Manager], [Resources: Investigation Guide] |None |4 -|<> |Identifies attempts to export a registry hive which may contain credentials using the Windows reg.exe tool. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne], [Data Source: Sysmon], [Data Source: Crowdstrike] |None |317 +|<> |Identifies attempts to export a registry hive which may contain credentials using the Windows reg.exe tool. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne], [Data Source: Sysmon], [Data Source: Crowdstrike] |None |318 |<> |Elastic Endgame detected Credential Dumping. Click the Elastic Endgame icon in the event.module column or the link in the rule.reference column for additional information. |[Data Source: Elastic Endgame], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide] |None |105 @@ -760,12 +786,8 @@ and their rule type is `machine_learning`. |<> |Detects writing executable files that will be automatically launched by Adobe on launch. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Microsoft Defender XDR], [Data Source: Crowdstrike] |None |421 -|<> |Identifies the execution of and EggShell Backdoor. EggShell is a known post exploitation tool for macOS and Linux. |[Domain: Endpoint], [OS: Linux], [OS: macOS], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |107 - |<> |Identifies registry write modifications to hide an encoded portable executable. This could be indicative of adversary defense evasion by avoiding the storing of malicious content directly on disk. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Microsoft Defender XDR], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |419 -|<> |Identifies the abuse of a Linux binary to break out of a restricted shell or environment by spawning an interactive system shell. The activity of spawning a shell from a binary is not common behavior for a user or system administrator, and may indicate an attempt to evade detection, increase capabilities or enhance the stability of an adversary. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |120 - |<> |Identifies when a Data Loss Prevention (DLP) policy is removed in Microsoft 365. An adversary may remove a DLP policy to evade existing DLP monitoring. |[Domain: Cloud], [Data Source: Microsoft 365], [Use Case: Configuration Audit], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |214 |<> |Detects the occurrence of emails reported as Phishing or Malware by Users. Security Awareness training is essential to stay ahead of scammers and threat actors, as security products can be bypassed, and the user can still receive a malicious message. Educating users to report suspicious messages can help identify gaps in security controls and prevent malware infections and Business Email Compromise attacks. |[Domain: Cloud], [Data Source: Microsoft 365], [Tactic: Initial Access], [Resources: Investigation Guide] |None |213 @@ -792,17 +814,11 @@ and their rule type is `machine_learning`. |<> |The malware known as SUNBURST targets the SolarWind's Orion business software for command and control. This rule detects post-exploitation command and control activity of the SUNBURST backdoor. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Command and Control], [Resources: Investigation Guide], [Data Source: Elastic Defend] |None |112 -|<> |Identifies the attempted use of a heap-based buffer overflow vulnerability for the Sudo binary in Unix-like systems (CVE-2021-3156). Successful exploitation allows an unprivileged user to escalate to the root user. |[Domain: Endpoint], [OS: Linux], [OS: macOS], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Use Case: Vulnerability], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |109 - |<> |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. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Elastic Endgame], [Use Case: Vulnerability], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |323 -|<> |This rule identifies unusual destination port network activity originating from a web server process. The rule is designed to detect potential web shell activity or unauthorized communication from a web server process to external systems. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Execution], [Tactic: Command and Control], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |7 - -|<> |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. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Execution], [Tactic: Command and Control], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |14 - |<> |This rule leverages alert data from various Discovery building block rules to alert on signals with unusual unique host.id and user.id entries. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Discovery], [Rule Type: Higher-Order Rule], [Rule Type: BBR] |None |3 -|<> |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. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Execution], [Tactic: Command and Control], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |14 +|<> |Identifies successful outbound TLS sessions that negotiate deprecated protocol versions (SSLv3, TLS 1.0, or TLS 1.1) or weak cipher suites such as RC4, 3DES, NULL, EXPORT, or anonymous Diffie-Hellman. Adversaries-in-the-middle and legacy malware often force these negotiations to decrypt or intercept traffic. Modern clients and services should negotiate TLS 1.2 or 1.3 with strong ciphers on internet-bound connections. |[Domain: Network], [Use Case: Network Security Monitoring], [Use Case: Threat Detection], [Data Source: Network Traffic], [Tactic: Credential Access], [Tactic: Command and Control], [Resources: Investigation Guide] |None |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. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide], [Domain: Endpoint], [Tactic: Impact] |None |4 @@ -938,7 +954,7 @@ and their rule type is `machine_learning`. |<> |Identifies when a user is observed for the first time authenticating using the device code authentication workflow. This authentication workflow can be abused by attackers to phish users and steal access tokens to impersonate the victim. By its very nature, device code should only be used when logging in to devices without keyboards, where it is difficult to enter emails and passwords. This rule only applies to Entra ID user types and detects new users leveraging this flow. |[Domain: Cloud], [Domain: Identity], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Sign-In Logs], [Use Case: Identity and Access Audit], [Tactic: Initial Access], [Resources: Investigation Guide] |None |10 -|<> |Detects successful Microsoft Entra ID sign-ins that use the OAuth device code authentication protocol with the Microsoft Authentication Broker client requesting first-party Office API resources (Exchange Online, Microsoft Graph, or SharePoint) while flagged as interactive. This pattern is associated with adversary-in-the-middle (AiTM) phishing kits such as Tycoon 2FA, where victims complete device code flows that ultimately broker tokens for mail and collaboration APIs. |[Domain: Cloud], [Domain: Identity], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Sign-in Logs], [Use Case: Threat Detection], [Threat: Tycoon2FA], [Tactic: Initial Access], [Resources: Investigation Guide] |None |1 +|<> |Detects successful Microsoft Entra ID sign-ins that use the OAuth device code authentication protocol with the Microsoft Authentication Broker client requesting first-party Office API resources (Exchange Online, Microsoft Graph, or SharePoint) while flagged as interactive. This pattern is associated with adversary-in-the-middle (AiTM) phishing kits such as Tycoon 2FA, where victims complete device code flows that ultimately broker tokens for mail and collaboration APIs. |[Domain: Cloud], [Domain: Identity], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Sign-in Logs], [Use Case: Threat Detection], [Threat: Tycoon2FA], [Tactic: Initial Access], [Resources: Investigation Guide] |None |2 |<> |Correlates a successful Entra ID device-code sign-in to the legacy Azure AD Graph audience (00000002-0000-0000-c000-000000000000) from an unmanaged device with directory enumeration against graph.windows.net by the same user within a short window. Device-code phishing is the dominant OAuth phishing variant against Microsoft tenants: the adversary initiates the flow, relays the user-facing code to the victim, and on redemption walks away with an access or refresh token bound to the targeted resource without ever handling the user's password or MFA factor. When the redeemed audience is AAD Graph and the redeeming device is unmanaged, the follow-on Graph traffic is the compromised cloud account being used by the attacker, not by the user. This rule fires when that token is immediately turned around against the directory under the same identity to read user, group, service principal, application, role assignment, directory object, policy, OAuth permission grant, or tenant detail collections. |[Domain: Cloud], [Domain: Identity], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Entra ID Sign-in Logs], [Data Source: Azure AD Graph], [Data Source: Azure AD Graph Activity Logs], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Tactic: Credential Access], [Tactic: Initial Access], [Tactic: Discovery], [Resources: Investigation Guide] |None |1 @@ -1154,7 +1170,7 @@ and their rule type is `machine_learning`. |<> |This rule identifies when a User Account starts the Active Directory Replication Process for the first time. Attackers can use the DCSync technique to get credential information of individual accounts or the entire domain, thus compromising the entire domain. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Tactic: Privilege Escalation], [Use Case: Active Directory Monitoring], [Data Source: Active Directory], [Resources: Investigation Guide], [Data Source: Windows Security Event Logs] |None |119 -|<> |Detects DNS queries to commonly abused remote monitoring and management (RMM) or remote access software domains from processes that are not browsers. Intended to surface RMM clients, scripts, or other non-browser activity contacting these services. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Command and Control], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: Sysmon] |None |4 +|<> |Detects DNS queries to commonly abused remote monitoring and management (RMM) or remote access software domains from processes that are not browsers. Intended to surface RMM clients, scripts, or other non-browser activity contacting these services. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Command and Control], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: Sysmon] |None |5 |<> |Identifies the load of a driver with an original file name and signature values that were observed for the first time during the last 30 days. This rule type can help baseline drivers installation within your environment. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Tactic: Persistence], [Resources: Investigation Guide], [Data Source: Elastic Defend] |None |13 @@ -1162,7 +1178,7 @@ and their rule type is `machine_learning`. |<> |Identifies a new credentials logon type performed by an unusual process. This may indicate the existence of an access token forging capability that are often abused to bypass access control restrictions. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |111 -|<> |Adversaries may install legitimate remote monitoring and management (RMM) tools or remote access software on compromised endpoints for command-and-control (C2), persistence, and execution of native commands. This rule detects when a process is started whose name or code signature (or whose parent's name or code signature) resembles commonly abused RMM/remote access tools, including first-time-seen child processes of such tools. New Terms type: host has not seen this process (or child-of-RMM pattern) before within the configured history window. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Command and Control], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Windows Security Event Logs], [Data Source: Sysmon] |None |117 +|<> |Adversaries may install legitimate remote monitoring and management (RMM) tools or remote access software on compromised endpoints for command-and-control (C2), persistence, and execution of native commands. This rule detects when a process is started whose name or code signature matches commonly abused RMM or remote access tools. New Terms type: the host.id and process.name pair has not been seen before within the configured 7-day history window. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Command and Control], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Windows Security Event Logs], [Data Source: Sysmon] |None |118 |<> |Identifies newly seen removable devices by device friendly name using registry modification events. While this activity is not inherently malicious, analysts can use those events to aid monitoring for data exfiltration over those devices. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Initial Access], [Tactic: Exfiltration], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |214 @@ -1238,13 +1254,41 @@ and their rule type is `machine_learning`. |<> |Identifies when a Virtual Private Cloud (VPC) route is deleted in Google Cloud Platform (GCP). Google Cloud routes define the paths that network traffic takes from a virtual machine (VM) instance to other destinations. These destinations can be inside a Google VPC network or outside it. An adversary may delete a route in order to impact the flow of network traffic in their target's cloud environment. |[Domain: Cloud], [Data Source: GCP], [Data Source: Google Cloud Platform], [Use Case: Configuration Audit], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |109 +|<> |Detects bursts of failed GKE API requests from a single user identity within a five-minute window. Repeated authorization failures across multiple actions can indicate credential stuffing, RBAC probing, or reconnaissance with stolen tokens. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: GCP], [Data Source: Google Cloud Platform], [Use Case: Threat Detection], [Tactic: Discovery], [Resources: Investigation Guide] |None |1 + +|<> |Detects creation or modification of GKE mutating or validating admission webhook configurations by non-system identities. Malicious webhooks can inject workloads, block security tooling, or intercept API traffic for persistence and defense evasion. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: GCP], [Data Source: Google Cloud Platform], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Defense Evasion], [Resources: Investigation Guide] |None |1 + +|<> |Detects creation or modification of a GKE ClusterRoleBinding that grants the cluster-admin ClusterRole, providing unrestricted cluster access and enabling rapid privilege escalation or persistence. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: GCP], [Data Source: Google Cloud Platform], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Privilege Escalation], [Resources: Investigation Guide] |None |1 + +|<> |Detects GKE pod creation with dangerous Linux capabilities that are commonly abused in container escape techniques. Standalone pods are included; controller-owned ReplicaSet, DaemonSet, and StatefulSet workloads are excluded. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: GCP], [Data Source: Google Cloud Platform], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Tactic: Execution], [Resources: Investigation Guide] |None |1 + +|<> |Detects GKE pod create, update, or patch events that enable host IPC namespace sharing. This exposes host inter-process communication mechanisms and can support privilege escalation. Controller-owned workloads are excluded. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: GCP], [Data Source: Google Cloud Platform], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Tactic: Execution], [Resources: Investigation Guide] |None |1 + +|<> |Detects GKE pod create, update, or patch events that enable host network namespace sharing. HostNetwork grants access to the node network stack and can bypass namespace network policies. System identities and controller-owned workloads are excluded. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: GCP], [Data Source: Google Cloud Platform], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Tactic: Execution], [Resources: Investigation Guide] |None |1 + +|<> |Detects GKE pod create, update, or patch events that enable host PID namespace sharing. HostPID exposes host processes and can support privilege escalation, especially with ptrace or privileged containers. System identities and controller-owned workloads are excluded. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: GCP], [Data Source: Google Cloud Platform], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Tactic: Execution], [Resources: Investigation Guide] |None |1 + +|<> |Detects GKE pod create, update, or patch events that mount sensitive hostPath volumes such as the root filesystem, kubelet paths, or container runtime sockets. This can enable container escape and credential theft. System identities and controller-owned workloads are excluded. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: GCP], [Data Source: Google Cloud Platform], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Tactic: Execution], [Resources: Investigation Guide] |None |1 + +|<> |Detects successful GKE audit events where a pod is created with allowPrivilegeEscalation enabled. This weakens container isolation and can help an attacker escalate toward host access. Standalone pods are included; workloads owned by ReplicaSet, DaemonSet, or StatefulSet controllers are excluded. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: GCP], [Data Source: Google Cloud Platform], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Tactic: Execution], [Resources: Investigation Guide] |None |1 + +|<> |Detects successful GKE secret get or list operations where the user agent matches scripting runtimes, minimal HTTP clients, or offensive-distribution fingerprints rather than typical kubectl or controller traffic. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: GCP], [Data Source: Google Cloud Platform], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide] |None |1 + +|<> |Detects the first time a human GKE caller lists secrets cluster-wide or in default or kube-system from a source autonomous system that is not attributed to common cloud provider organizations. This can indicate remote secret enumeration using stolen credentials from an unusual network. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: GCP], [Data Source: Google Cloud Platform], [Use Case: Threat Detection], [Tactic: Credential Access], [Tactic: Discovery], [Resources: Investigation Guide] |None |1 + +|<> |Detects GKE service account or node identities invoking self-subject access or rules review APIs. Non-human identities rarely enumerate their own permissions outside known controllers; this can indicate stolen tokens probing effective RBAC. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: GCP], [Data Source: Google Cloud Platform], [Use Case: Threat Detection], [Tactic: Discovery], [Resources: Investigation Guide] |None |1 + +|<> |Detects the first occurrence of a non-system GKE identity establishing an exec session into a pod. kubectl exec enables interactive command execution inside workloads and is a common post-compromise technique to access secrets and expand access. |[Domain: Cloud], [Domain: Kubernetes], [Data Source: GCP], [Data Source: Google Cloud Platform], [Use Case: Threat Detection], [Tactic: Execution], [Resources: Investigation Guide] |None |1 + |<> |This rule detects the creation of GRUB configuration files on Linux systems. The GRUB configuration file is used to configure the boot loader, which is responsible for loading the operating system. Attackers may create malicious GRUB configuration files to execute arbitrary code or escalate privileges during the boot process, which can be leveraged to maintain persistence on the system. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Execution], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Data Source: SentinelOne], [Data Source: Elastic Endgame], [Resources: Investigation Guide] |None |6 |<> |This rule detects the generation of a new GRUB configuration file using built-in Linux commands. The GRUB configuration file is used to configure the GRUB bootloader, which is responsible for loading the Linux kernel and initramfs image during the boot process. Attackers may use these built-in utilities to generate a new GRUB configuration file that includes malicious kernel parameters or boot options, which can be leveraged to maintain persistence on the system. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |6 |<> |Detects when macOS Gatekeeper is overridden followed by execution of the same binary from a suspicious location. This behavior indicates an attempt to bypass Apple's security controls and execute potentially malicious software downloaded from the internet. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |2 -|<> |Detects when GenAI tools access sensitive files such as cloud credentials, SSH keys, browser password databases, or shell configurations. Attackers leverage GenAI agents to systematically locate and exfiltrate credentials, API keys, and tokens. Access to credential stores (.aws/credentials, .ssh/id_*) suggests harvesting, while writes to shell configs (.bashrc, .zshrc) indicate persistence attempts. Note: On linux only creation events are available. Access events are not yet implemented. |[Domain: Endpoint], [OS: Linux], [OS: macOS], [OS: Windows], [Use Case: Threat Detection], [Tactic: Collection], [Tactic: Credential Access], [Data Source: Elastic Defend], [Resources: Investigation Guide], [Domain: LLM], [Mitre Atlas: T0085], [Mitre Atlas: T0085.001], [Mitre Atlas: T0055] |None |7 +|<> |Identifies GenAI agent CLIs started with permission-bypass or auto-approval flags that disable human-in-the-loop guardrails. These modes are intended for isolated sandboxes but are frequently misused on internet-connected developer workstations, allowing prompt injection, compromised dependencies, or malicious skills to execute commands, modify files, or reach sensitive paths without confirmation. |[Domain: Endpoint], [OS: Linux], [OS: macOS], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Resources: Investigation Guide], [Domain: LLM] |None |1 + +|<> |Detects when GenAI tools access sensitive files such as cloud credentials, SSH keys, browser password databases, or shell configurations. Attackers leverage GenAI agents to systematically locate and exfiltrate credentials, API keys, and tokens. Access to credential stores (.aws/credentials, .ssh/id_*) suggests harvesting, while writes to shell configs (.bashrc, .zshrc) indicate persistence attempts. Note: On linux only creation events are available. Access events are not yet implemented. |[Domain: Endpoint], [OS: Linux], [OS: macOS], [OS: Windows], [Use Case: Threat Detection], [Tactic: Collection], [Tactic: Credential Access], [Data Source: Elastic Defend], [Resources: Investigation Guide], [Domain: LLM], [Mitre Atlas: T0085], [Mitre Atlas: T0085.001], [Mitre Atlas: T0055] |None |8 |<> |Detects when GenAI tools spawn compilers or packaging tools to generate executables. Attackers leverage local LLMs to autonomously generate and compile malware, droppers, or implants. Python packaging tools (pyinstaller, nuitka, pyarmor) are particularly high-risk as they create standalone executables that can be deployed without dependencies. This rule focuses on compilation activity that produces output binaries, filtering out inspection-only operations. |[Domain: Endpoint], [OS: Linux], [OS: macOS], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Auditd Manager], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne], [Resources: Investigation Guide], [Domain: LLM], [Mitre Atlas: T0053] |None |3 @@ -1384,9 +1428,13 @@ and their rule type is `machine_learning`. |<> |Generates a detection alert for each IBM QRadar offense written to the configured indices. Enabling this rule allows you to immediately begin investigating IBM QRadar offense alerts in the app. |[Data Source: IBM QRadar], [Use Case: Threat Detection], [Resources: Investigation Guide], [Promotion: External Alerts] |None |1 +|<> |Identifies ICMP Redirect messages (type 5 for IPv4, type 137 for IPv6) sourced from an internal IPv4 or IPv6 address. Legitimate redirects are normally sent only by on-path routers. A workstation or server emitting redirects can indicate route manipulation for adversary-in-the-middle activity. |[Domain: Network], [Tactic: Credential Access], [Use Case: Threat Detection], [Use Case: Network Security Monitoring], [Data Source: Network Traffic], [Resources: Investigation Guide] |None |1 + +|<> |Identifies inbound ICMP Timestamp (type 13) or Information (type 15) requests from external addresses to internal RFC1918 destinations. These message types are rarely used in modern networks and are commonly associated with host and path fingerprinting during reconnaissance. |[Domain: Network], [Tactic: Discovery], [Tactic: Reconnaissance], [Use Case: Network Security Monitoring], [Use Case: Threat Detection], [Data Source: Network Traffic], [Resources: Investigation Guide] |None |1 + |<> |Identifies when Internet Information Services (IIS) HTTP Logging is disabled on a server. An attacker with IIS server access via a webshell or other mechanism can disable HTTP Logging as an effective anti-forensics measure. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Endgame], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender XDR], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Crowdstrike] |None |318 -|<> |This rule detects events that could be describing IPSEC NAT Traversal traffic. IPSEC is a VPN technology that allows one system to talk to another using encrypted tunnels. NAT Traversal enables these tunnels to communicate over the Internet where one of the sides is behind a NAT router gateway. This may be common on your network, but this technique is also used by threat actors to avoid detection. |[Tactic: Command and Control], [Domain: Endpoint], [Use Case: Threat Detection], [Data Source: PAN-OS], [Data Source: pfSense], [Resources: Investigation Guide] |None |111 +|<> |This rule detects outbound IPSEC NAT Traversal (NAT-T) tunnels established from an internal host to an external destination. IPSEC is a VPN technology that allows one system to talk to another using encrypted tunnels. NAT Traversal encapsulates IPSEC ESP traffic in UDP and, once a NAT device is detected, both peers float to UDP port 4500 for the tunnel data channel. The rule keys on this NAT-T signature, UDP traffic where both the source and destination port are 4500, from an internal source to an external destination, rather than on any UDP traffic to port 4500. This may be common on your network, but this technique is also used by threat actors to tunnel command and control or exfiltration traffic over the Internet to avoid detection. |[Tactic: Command and Control], [Domain: Endpoint], [Use Case: Threat Detection], [Data Source: PAN-OS], [Data Source: Network Traffic], [Data Source: pfSense], [Data Source: Zeek], [Resources: Investigation Guide] |None |112 |<> |This rule monitors for the execution of commands that enable IPv4 and IPv6 forwarding on Linux systems. Enabling IP forwarding can be used to route network traffic between different network interfaces, potentially allowing attackers to pivot between networks, exfiltrate data, or establish command and control channels. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Command and Control], [Data Source: Elastic Defend], [Data Source: SentinelOne], [Data Source: Elastic Endgame], [Resources: Investigation Guide], [Data Source: Crowdstrike] |None |108 @@ -1560,7 +1608,7 @@ and their rule type is `machine_learning`. |<> |This rule detects when secrets are accessed via an unusual user agent, user name and source IP. Attackers may attempt to access secrets in a Kubernetes cluster to gain access to sensitive information after gaining access to the cluster. |[Data Source: Kubernetes], [Domain: Kubernetes], [Domain: Cloud], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide] |None |3 -|<> |Kubernetes audit identities for kubelet (`system:node:*`) and workloads (`system:serviceaccount:*`) are meant to operate with tight, predictable API usage. Direct `get` or `list` on the Secrets API from those principals is often a sign of credential access. Attackers who stole a pod service-account token or node credentials sweep Secret objects for tokens, registry credentials, TLS keys, or application configuration. Even denied attempts still reveal intent to reach sensitive material. Legitimate controllers do read secrets they mount or manage, so this signal is most valuable when paired with triage (namespace scope, user agent, RBAC, and whether the identity should touch those secret names at all). |[Data Source: Kubernetes], [Domain: Kubernetes], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide] |None |2 +|<> |Kubernetes audit identities for kubelet (`system:node:*`) and workloads (`system:serviceaccount:*`) are meant to operate with tight, predictable API usage. Direct `get` or `list` on the Secrets API from those principals is often a sign of credential access. Attackers who stole a pod service-account token or node credentials sweep Secret objects for tokens, registry credentials, TLS keys, or application configuration. Even denied attempts still reveal intent to reach sensitive material. Legitimate controllers do read secrets they mount or manage, so this signal is most valuable when paired with triage (namespace scope, user agent, RBAC, and whether the identity should touch those secret names at all). |[Data Source: Kubernetes], [Domain: Kubernetes], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide] |None |3 |<> |Detects read access to Kubernetes Secrets (`get`/`list`) with a user agent matching a curated set of non-standard or attacker-leaning clients, for example minimal HTTP tooling, common scripting stacks, default library fingerprints, or distribution-tagged strings associated with offensive-security Linux images. Legitimate in-cluster automation usually presents stable, purpose-specific user agents (for example controller or client-go variants used by known components). |[Data Source: Kubernetes], [Domain: Kubernetes], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide] |None |1 @@ -1608,6 +1656,8 @@ and their rule type is `machine_learning`. |<> |This rule monitors for the usage of the most common clipboard utilities on unix systems by an uncommon process parent. Adversaries may collect data stored in the clipboard from users copying information within or between applications. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Collection], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Auditd Manager], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |10 +|<> |Detects applications making a curl request to a known public IP address lookup web service. Malware tends to perform this action to assess potential targets. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Discovery], [Data Source: Elastic Defend], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |1 + |<> |Identifies attempts to create a new group. Attackers may create new groups to establish persistence on a system. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Resources: Investigation Guide] |None |11 |<> |This rule monitors for potential memory dumping through gdb. Attackers may leverage memory dumping techniques to attempt secret extraction from privileged processes. Tools that display this behavior include "truffleproc" and "bash-memory-dump". This behavior should not happen by default, and should be investigated thoroughly. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Elastic Defend], [Data Source: Elastic Endgame], [Data Source: Auditd Manager], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |108 @@ -1808,7 +1858,7 @@ and their rule type is `machine_learning`. |<> |Detects Microsoft Graph activity from delegated user tokens (public client, client_auth_method 0) where a single user session and source IP rapidly touches multiple high-value Graph paths indicative of reconnaissance. The query classifies requests into categories such as role discovery, cross-tenant relationship queries, mailbox paths, contact harvesting, and organization or licensing metadata. When three or more distinct categories appear within a short burst window, it suggests a broad enumeration playbook rather than normal application traffic. |[Domain: Cloud], [Domain: Identity], [Domain: API], [Data Source: Azure], [Data Source: Microsoft Entra ID], [Data Source: Microsoft Graph], [Data Source: Microsoft Graph Activity Logs], [Use Case: Threat Detection], [Tactic: Discovery], [Resources: Investigation Guide] |None |1 -|<> |Identifies access to email resources via Microsoft Graph API using an first-party application on behalf of a user principal. This behavior may indicate an adversary using a phished OAuth refresh token or a Primary Refresh Token (PRT) to access email resources. The pattern includes requests to Microsoft Graph API endpoints related to email, such as /me/mailFolders/inbox/messages or /users/{user_id}/messages, using a public client application ID and a user principal object ID. This is a New Terms rule that only signals if the application ID and user principal object ID have not been seen doing this activity in the last 14 days. |[Domain: Cloud], [Domain: Email], [Data Source: Azure], [Data Source: Microsoft Graph], [Data Source: Microsoft Graph Activity Logs], [Use Case: Threat Detection], [Tactic: Collection], [Resources: Investigation Guide] |None |6 +|<> |Identifies access to email resources via Microsoft Graph API using an first-party application on behalf of a user principal. This behavior may indicate an adversary using a phished OAuth refresh token or a Primary Refresh Token (PRT) to access email resources. The pattern includes requests to Microsoft Graph API endpoints related to email, such as /me/mailFolders/inbox/messages or /users/{user_id}/messages, using a public client application ID and a user principal object ID. This is a New Terms rule that only signals if the application ID and user principal object ID have not been seen doing this activity in the last 14 days. |[Domain: Cloud], [Domain: Email], [Data Source: Azure], [Data Source: Microsoft Graph], [Data Source: Microsoft Graph Activity Logs], [Use Case: Threat Detection], [Tactic: Collection], [Resources: Investigation Guide] |None |7 |<> |This New Terms rule focuses on the first occurrence of a client application ID (azure.graphactivitylogs.properties.app_id) making a request to Microsoft Graph API for a specific tenant ID (azure.tenant_id) and user principal object ID (azure.graphactivitylogs.properties.user_principal_object_id). This rule may helps identify unauthorized access or actions performed by compromised accounts. Advesaries may succesfully compromise a user's credentials and use the Microsoft Graph API to access resources or perform actions on behalf of the user. |[Domain: Cloud], [Data Source: Azure], [Data Source: Microsoft Graph], [Data Source: Microsoft Graph Activity Logs], [Resources: Investigation Guide], [Use Case: Identity and Access Audit], [Tactic: Initial Access] |None |8 @@ -1858,7 +1908,7 @@ and their rule type is `machine_learning`. |<> |This rule uses alert data to determine when multiple different alerts involving the same user are triggered. Analysts can use this to prioritize triage and response, as these users are more likely to be compromised. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide] |None |9 -|<> |This rule uses alert data to determine when multiple alerts in different phases of an attack involving the same host are triggered. Analysts can use this to prioritize triage and response, as these hosts are more likely to be compromised. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide] |None |6 +|<> |This rule uses alert data to determine when multiple alerts in different phases of an attack involving the same host are triggered. Analysts can use this to prioritize triage and response, as these hosts are more likely to be compromised. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide] |None |7 |<> |This rule correlates multiple security alerts associated with the same ATT&CK tactic on a single host within a defined time window. By requiring alerts from multiple distinct detection rules, this detection helps identify hosts exhibiting concentrated malicious behavior, which may indicate an active intrusion or post-compromise activity. The rule is intended to assist analysts in prioritizing triage toward hosts with higher likelihood of compromise rather than signaling a single discrete event. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide] |None |5 @@ -1888,7 +1938,7 @@ and their rule type is `machine_learning`. |<> |Detects when a high number of Okta user authentication events are reported for multiple users in a short time frame. Adversaries may attempt to launch a credential stuffing or password spraying attack from the same device by using a list of known usernames and passwords to gain unauthorized access to user accounts. |[Use Case: Identity and Access Audit], [Data Source: Okta], [Tactic: Credential Access], [Resources: Investigation Guide] |None |212 -|<> |Identifies a Windows host where two or more distinct remote monitoring and management (RMM) or remote-access tool vendors are observed starting processes within the same eight-minute window. Legitimate MSP environments may run multiple tools, but this pattern can also indicate compromise, shadow IT, or attacker staging of redundant access. Processes are mapped to a single vendor label so multiple binaries from the same vendor do not inflate the count. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Command and Control], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Microsoft Defender XDR], [Data Source: Crowdstrike], [Data Source: Windows Security Event Logs], [Data Source: Elastic Endgame], [Data Source: Winlogbeat] |None |3 +|<> |Identifies a Windows host where two or more distinct remote monitoring and management (RMM) or remote-access tool vendors are observed starting processes within the same eight-minute window. Legitimate MSP environments may run multiple tools, but this pattern can also indicate compromise, shadow IT, or attacker staging of redundant access. Processes are mapped to a single vendor label so multiple binaries from the same vendor do not inflate the count. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Command and Control], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Microsoft Defender XDR], [Data Source: Crowdstrike], [Data Source: Windows Security Event Logs], [Data Source: Winlogbeat] |None |4 |<> |Windows Credential Manager allows you to create, view, or delete saved credentials for signing into websites, connected applications, and networks. An adversary may abuse this to list or dump credentials stored in the Credential Manager for saved usernames and passwords. This may also be performed in preparation of lateral movement. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Windows Security Event Logs], [Resources: Investigation Guide] |None |116 @@ -1914,6 +1964,8 @@ and their rule type is `machine_learning`. |<> |Identifies DNS queries to commonly abused Top Level Domains by common LOLBINs or executables running from world writable directories or unsigned binaries. This behavior matches on common malware C2 abusing less formal domain names. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Command and Control], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Data Source: Sysmon] |None |4 +|<> |Detects network connections originating from a binary located in a potentially suspicious location, followed by a file creation event. This behavior is consistent with C2 agents such as Poseidon and Athena, connecting to a C2 framework such as Mythic. The agent polls the C2 for commands through a web request, after which the command gets executed. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Command and Control], [Tactic: Execution], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |1 + |<> |This rule identifies an egress internet connection initiated by an SSH Daemon child process. This behavior is indicative of the alteration of a shell configuration file or other mechanism that launches a process when a new SSH login occurs. Attackers can also backdoor the SSH daemon to allow for persistence, call out to a C2 or to steal credentials. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |9 |<> |This detection rule addresses multiple vulnerabilities in the CUPS printing system, including CVE-2024-47176, CVE-2024-47076, CVE-2024-47175, and CVE-2024-47177. Specifically, this rule detects network connections initiated by a child processes of foomatic-rip. These flaws impact components like cups-browsed, libcupsfilters, libppd, and foomatic-rip, allowing remote unauthenticated attackers to manipulate IPP URLs or inject malicious data through crafted UDP packets or network spoofing. This can result in arbitrary command execution when a print job is initiated. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Use Case: Vulnerability], [Tactic: Command and Control], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |6 @@ -2028,6 +2080,8 @@ and their rule type is `machine_learning`. |<> |This rule detects passwordless sudo probing activity on Linux systems. Passwordless sudo probing can be an indication of an attacker attempting to enumerate it's allowed commands and potential privilege escalation. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Discovery], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Auditd Manager], [Data Source: Crowdstrike], [Data Source: SentinelOne], [Resources: Investigation Guide] |None |1 +|<> |This rule detects when a payload is downloaded by an interpreter, and piped to an interpreter. Attackers may use this technique to download and execute payloads for various malicious purposes, such as establishing persistence or exfiltrating data. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Execution], [Tactic: Command and Control], [Tactic: Defense Evasion], [Data Source: Elastic Defend] |None |1 + |<> |Detects when an unusual parent process like Node.js, Python, or osascript executes the pbpaste binary to access clipboard data. This technique has been used by malware like OtterCookie to steal passwords and seed phrases from the clipboard. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Collection], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |1 |<> |Identifies use of the Windows file system utility (fsutil.exe) to gather information about attached peripheral devices and components connected to a computer system. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Discovery], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender XDR], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Crowdstrike] |None |316 @@ -2058,7 +2112,7 @@ and their rule type is `machine_learning`. |<> |A job can be used to schedule programs or scripts to be executed at a specified date and time. Adversaries may abuse task scheduling functionality to facilitate initial or recurring execution of malicious code. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Microsoft Defender XDR], [Resources: Investigation Guide] |None |416 -|<> |Identifies the creation of a launch agent or daemon property list file containing abnormal or suspicious values. An adversary may establish persistence by installing a new launch agent or daemon which executes at login. This rule looks for plist files created in LaunchAgents/LaunchDaemons directories with paths commonly used by malware. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |1 +|<> |Identifies the creation of a launch agent or daemon property list file containing abnormal or suspicious values. An adversary may establish persistence by installing a new launch agent or daemon which executes at login. This rule looks for plist files created in LaunchAgents/LaunchDaemons directories with paths commonly used by malware. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |2 |<> |Detects the successful hijack of Microsoft Compatibility Appraiser scheduled task to establish persistence with an integrity level of system. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender XDR], [Data Source: Sysmon], [Data Source: SentinelOne], [Data Source: Crowdstrike], [Resources: Investigation Guide] |None |318 @@ -2160,9 +2214,13 @@ and their rule type is `machine_learning`. |<> |A population analysis machine learning job detected potential DGA (domain generation algorithm) activity. Such activity is often used by malware command and control (C2) channels. This machine learning job looks for a source IP address making DNS requests that have an aggregate high probability of being DGA activity. |[Use Case: Domain Generation Algorithm Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Command and Control], [Resources: Investigation Guide] |None |9 +|<> |Identifies a burst of DHCP DISCOVER messages with an unusually high number of distinct client hardware addresses observed on the same capture segment within a short window. Attackers flood DISCOVER requests with spoofed or random MAC addresses to exhaust the DHCP lease pool, often as a precursor to deploying a rogue DHCP server. |[Domain: Network], [Use Case: Threat Detection], [Use Case: Network Security Monitoring], [Tactic: Impact], [Data Source: Network Traffic], [Resources: Investigation Guide] |None |1 + |<> |Identifies an instance of a Windows trusted program that is known to be vulnerable to DLL Search Order Hijacking starting after being renamed or from a non-standard path. This is uncommon behavior and may indicate an attempt to evade defenses via side loading a malicious DLL within the memory space of one of those processes. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Execution], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender XDR], [Resources: Investigation Guide], [Data Source: Crowdstrike], [Data Source: SentinelOne] |None |219 -|<> |This rule identifies a large number (15) of nslookup.exe executions with an explicit query type from the same host. This may indicate command and control activity utilizing the DNS protocol. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Command and Control], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne], [Data Source: Sysmon] |None |316 +|<> |Identifies potential DNS exfiltration on Windows hosts by detecting a high volume of DNS queries whose subdomain labels follow a chunked encoding pattern (index-payload.base_domain). Attackers split stolen data across many DNS queries to evade volume-based detection; this rule aggregates queries per process, base domain, and five-minute window and flags sessions with many distinct chunk indices and sufficiently long encoded payloads. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Exfiltration], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: Crowdstrike], [Data Source: Sysmon] |None |1 + +|<> |This rule identifies a large number (15) of nslookup.exe executions with an explicit query type from the same host. This may indicate command and control activity utilizing the DNS protocol. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Command and Control], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Windows Security Event Logs], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne], [Data Source: Sysmon], [Data Source: Crowdstrike] |None |317 |<> |A machine learning job has detected data exfiltration to a particular destination port. Data transfer patterns that are outside the normal traffic patterns of an organization could indicate exfiltration over command and control channels. |[Use Case: Data Exfiltration Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Exfiltration], [Resources: Investigation Guide] |None |8 @@ -2242,6 +2300,8 @@ and their rule type is `machine_learning`. |<