LoFP LoFP / elastic

elastic

TitleTags
a benign assistant reply that quotes a documentation token, a commit sha, or a sample encoded string can score above 0.98. the completion step is expected to label a refusal or an ordinary answer fp. an alert means the completion model confirmed that the assistant complied, revealed hidden instructions, or returned a secret or obfuscated payload.
a corporate nat, jump host, or ci runner that is not in the excluded asn list can send `getcalleridentity` for several iam users from one ip. confirm the source ip, user agent, and user list against approved automation before treating the activity as malicious.
a customer managed kms key may be disabled or scheduled for deletion by a system administrator. verify whether the user identity, user agent, and/or hostname should be making changes in your environment. key deletions by unfamiliar users should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
a database instance may be created by a system or network administrator. verify whether the user identity, user agent, and/or hostname should be making changes in your environment. instances creations by unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
a developer or operator legitimately running first-party tooling under the device-code flow that then enumerates directory objects during onboarding or troubleshooting. validate the calling app and source ip and exclude as appropriate.
a dlp policy may be removed by a system or network administrator. verify that the configuration change was expected. exceptions can be added to this rule to filter expected behavior.
a documented maintenance window can enable ssh, relax execinstalledonly, and force-install a vendor vib on the same host. confirm the change ticket and the vib name before treating the sequence as malicious.
a domain transfer lock may be intentionally disabled by an authorized administrator to prepare for a planned domain migration or registrar change. confirm that the action aligns with an approved change request. you may exempt known administrative accounts involved in routine domain operations to reduce noise.
a elasticache security group deletion may be done by a system or network administrator. verify whether the user identity, user agent, and/or hostname should be making changes in your environment. security group deletions by unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
a elasticache security group may be created by a system or network administrator. verify whether the user identity, user agent, and/or hostname should be making changes in your environment. security group creations by unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
a group may be created by a system or network administrator. verify whether the user identity, user agent, and/or hostname should be making changes in your environment. group creations by unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
a legitimate application that has been deleted from the tenant while a client continues to authenticate against its former client id via ropc can generate error code 700016. a misconfigured legacy client submitting an incorrect client id is also possible. in both cases the client id is typically stable and low-volume, unlike the many distinct or randomized identifiers seen in spoofing. verify the application identifier, the source infrastructure, and whether the same principal is targeted by many different unresolved client ids.
a legitimate change in agent behavior, such as a new workflow, a bulk-processing task, or a prompt update that asks the model to call many tools in one turn, can produce a larger batch than the caller's history. confirm with the agent owner.
a legitimate spike in agent usage, such as a batch job, a load test, a launch, or a retry storm, can produce a high volume of tool-requesting responses. confirm with the agent owner.
a legitimate vba for outlook is usually configured interactively via outlook.exe.
a legitimate, never-patched windows 10 host at build `10.0.19041.928` (20h1) or `10.0.19045.2006` (22h2) can present the same dsreg user agent during a genuine azure ad join or register. validate the device name, owner, and patch level against your device inventory before escalating.
a malware filter policy may be deleted by a system or network administrator. verify that the configuration change was expected. exceptions can be added to this rule to filter expected behavior.
a malware filter rule may be deleted by a system or network administrator. verify that the configuration change was expected. exceptions can be added to this rule to filter expected behavior.
a misconfgured network application or firewall may trigger this alert. security scans or test cycles may trigger this alert.
a misconfigured service account can trigger this alert. a password change on an account used by an email client can trigger this alert. security test cycles that include brute force or password spraying activities may trigger this alert.
a new and unusual program or artifact download in the course of software upgrades, debugging, or troubleshooting could trigger this alert. users downloading and running programs from unusual locations, such as temporary directories, browser caches, or profile paths could trigger this alert.
a new role may be assigned to a management group by a system or network administrator. verify that the configuration change was expected. exceptions can be added to this rule to filter expected behavior.
a new transport rule may be created by a system or network administrator. verify that the configuration change was expected. exceptions can be added to this rule to filter expected behavior.
a newly deployed or newly enabled tool is rare by definition until it has been used regularly. confirm any recent change to the agent's tool set.
a newly installed program or one that rarely uses the network could trigger this alert.
a newly installed program or one that runs rarely as part of a monthly or quarterly workflow could trigger this alert. powershell scripts that are new to the environment or run infrequently may trigger this alert.
a newly installed program or one that runs very rarely as part of a monthly or quarterly workflow could trigger this detection rule.
a newly installed program, or one that runs under a new or rarely used user context, could trigger this detection rule. manual interrogation of the metadata service during debugging or troubleshooting could trigger this rule.
a newly onboarded caller has little history, so early batches can look unusual until the model has learned its normal range.
a newly onboarded caller has little history, so early bursts can look unusual until the model has learned its normal range.
a principal that legitimately both registers a high-compute public-image task definition and runs ecs workloads in the same window could match (for example, some data-science or batch pipelines). confirm the image and cpu in \"aws.cloudtrail.request_parameters\" of the registertaskdefinition event, the launched workload, and whether the principal in \"aws.cloudtrail.user_identity.arn\" is an expected ecs operator; exclude known principals after validation. the cpu threshold and registry list are tunable in the query.
a prompt that contains both an email address and a sentence such as \"the password is required\" matches the password assignment pattern. read the message and drop test subscriptions that intentionally send fake secrets.
a safe attachment rule may be disabled by a system or network administrator. verify that the configuration change was expected. exceptions can be added to this rule to filter expected behavior.
a security group may be created by a system or network administrator. verify whether the user identity, user agent, and/or hostname should be making changes in your environment. security group creations by unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
a service principal may be created by a system or network administrator. verify whether the username, hostname, and/or resource name should be making changes in your environment. service principal additions from unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
a service principal used by a ci/cd pipeline may trigger this rule when the pipeline runs from a new ip range for the first time (e.g., migrating to a new runner pool). the 7-day history window will learn the new ips after the first occurrence.
a shared subscription key behind one nat can combine refusals from unrelated users. raise the threshold or split keys per application if that subscription is noisy.
a subscription key used from a vpn, a cloud vm, or a corporate proxy whose egress geo is far from the developer's network. a home isp and a cloud build agent on the same key look like impossible travel.
a support script stored under `/tmp` or a python inventory check can be pointed at a datastore during maintenance. confirm the file name, the account, and whether virtual machines were shut down in the same session.
a tool or target that is broken or misconfigured for all callers (an upstream outage, a bad deployment, or an expired credential) produces the same failure burst as a single caller probing it, and the error events carry no caller, target, or tool identity to tell them apart. confirm the gateway's target health and recent change history before treating a burst as adversarial, and add an exception by gateway (resource_arn) for gateways fronting known-flaky upstreams.
a transport rule may be modified by a system or network administrator. verify that the configuration change was expected. exceptions can be added to this rule to filter expected behavior.
a user authenticating via the device code flow for the first time from a new but legitimate network, such as travel, a new home or office isp, a corporate vpn, or a mobile carrier. device code authentication is expected when enrolling or signing in on input-constrained devices (smart tvs, kiosks, iot, conference room devices) and for some cli or headless developer workflows. review the source asn, geolocation, and the user's prior device code history to confirm whether the origin is plausible before escalating.
a user completing initial passwordless enrollment and registering their first device in the same session can match. validate against expected onboarding and the device's provenance (managed/compliant, expected name, expected source).
a user experiencing legitimate login issues (forgotten password, typos) may trigger credential attack alerts before successfully authenticating.
a user experiencing login issues may generate multiple device tokens through repeated legitimate attempts.
a user legitimately enrolling a new personal or corporate device (new laptop, replacement phone, byod enrollment). validate by confirming the device registration timing aligns with a known device refresh, it hardware ticket, or onboarding event.
a user legitimately enrolling several devices in a short window (for example, a new laptop and phone during onboarding, or re-registering a device after a wipe) can produce three or more registrations. validate against the user's device inventory and onboarding activity, and consider raising the threshold or tightening the window if benign multi-device enrollment is common in the environment.
a user legitimately using the device code flow for the first time on a personal or otherwise non-compliant device, such as a smart tv, kiosk, iot device, conference room device, or a personal laptop for a cli or headless developer workflow. review the source asn, geolocation, application, and the user's device posture to confirm whether the activity is expected before escalating.
a user may copy a public template that uses a container-bound script and consent to that add-on within three minutes from the same ip. confirm the oauth client with the template owner before treating the grant as malicious.
a user may generate a shared access link to encryption key files to share with others. it is unlikely that the intended recipient is an external or anonymous user.
a user may have multiple sessions open at the same time, such as on a mobile device and a laptop.
a user may report suspicious activity on their okta account in error.
a user repeatedly clicking an expired or invalid magic link from the same browser session can produce several failures before requesting a new link or signing in successfully.
a user running azure cli, azure powershell, vs code, graph cli, or visual studio on a jump host, cloud shell, or vpn egress that differs from the workstation's windows sign-in ip can match if that activity still presents a compliant or managed workstation deviceid. validate whether the graph client ran on the enrolled device before treating the event as cookie theft.
a user sending emails using personal distribution folders may trigger the event.
a user simultaneously enrolling multiple workspace-aware apps on a new device (e.g., first-time setup of gmail, drive, calendar, and meet on a new laptop in a short window) may produce three or more distinct device ids in a minute. validate by checking whether the burst is tied to a fresh device or onboarding event.
a user who runs azure cli, azure powershell, vs code, graph cli, or visual studio from a new egress (vpn, hotel, cloud shell, jump host) while wam still attaches a compliant or managed workstation deviceid will match on first sight of that ip. exception: add known developer and cloud shell ranges after confirming the client ran there.
a windows administrator may have triggered a low-fidelity credential access alert during a legitimate administrative action. following this, the administrator may have reset the mfa credentials for themselves and then logged into the okta console for ad directory services integration management.
a workload or observability agent with partial rbac can be denied across several resource types and resemble enumeration (for example a monitoring agent that watches resources it lacks permission for). baseline such identities and raise the cardinality threshold, or exclude the specific validated service account, after review. single-resource retry loops (one resource denied repeatedly) do not trigger this rule because detection is based on the number of distinct resources denied, not the raw failure count.
access level modifications may be done by a system or network administrator. verify whether the username, hostname, and/or resource name should be making changes in your environment. access level modifications from unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
access removal may be a part of normal operations and should be verified before taking action.
access-denied errors can result from benign permission gaps: a newly created role or user whose iam policy has not yet been provisioned, automation pipelines running ahead of permission grants, or ml teams experimenting in non-production accounts during onboarding. verify that the principal, source ip, and user agent are expected before escalating. recurring denials from known onboarding or provisioning workflows can be exempted for specific users or roles.
accounts may legitimately leave an organization during company splits, divestitures, or other structural changes. this action requires the account's root credentials or an explicit policy granting `organizations:leaveorganization`. any unexpected event, successful or denied, should be treated as a critical incident requiring immediate investigation and confirmation with account/organization owners.
administrative or automated tasks that involve accessing microsoft graph api using the specified client application id and tenant id, such as provisioning or managing resources.
administrative scripts and software deployment tools may intentionally unblock trusted executables or installers.
administrator roles may be assigned to okta users by a super admin user. verify that the behavior was expected. exceptions can be added to this rule to filter expected behavior.
administrator roles may be assigned to okta users or groups by authorized super admin users during normal it operations such as onboarding, role changes, or organizational restructuring. verify that the behavior was expected and authorized. exceptions can be added to this rule to filter known administrators, service accounts, or automated provisioning systems.
administrators accessing arc clusters from a new vpn endpoint or travel location. validate the caller identity matches an expected user and correlate with known travel or access patterns.
administrators add legitimate corporate domains during onboarding or m&a.
administrators and developers may legitimately acquire tokens and use them with powershell, command-line tools, or custom scripts to query microsoft graph. confirm that the client application, account, enumeration target, and timing are expected before escalating.
administrators and identity teams may legitimately create or reset console login profiles during user onboarding, password resets, or break-glass procedures. verify the principal in \"aws.cloudtrail.user_identity.arn\", the target user in \"aws.cloudtrail.request_parameters\", and whether the change aligns with an approved request. known administration roles and provisioning automation can be excluded after validation.
administrators behind a shared egress address, such as a corporate nat gateway or vpn concentrator, can trigger this rule when separate people mistype root passwords for different accounts within the window, since a single failure per account is sufficient. an administrator who legitimately holds root credentials for several accounts can also match. verify whether the source ip is an expected corporate or administrator address, and whether the targeted accounts correspond to that person's scope, before escalating. repeated failures against a single account do not trigger this rule and are covered by the separate brute-force rule.
administrators create local accounts during onboarding or break-glass setup. confirm the account name and whether it was then granted the admin role.
administrators deactivate or delete sso connections during identity provider migrations, certificate rotation, or maintenance. validate the actor, `anthropic.audit.connection_id`, and whether sso was restored after the change.
administrators deleting expired workspace log archives under an approved retention policy.
administrators disable lockdown mode for a documented maintenance window, then turn it back on. confirm the change ticket and that lockdown mode is enabled again afterward.
administrators disable magic link second factor during authentication policy changes or troubleshooting. verify the actor and whether the setting was re-enabled or replaced with an equivalent control.
administrators enable ssh for a documented troubleshooting window. esxi often disables the service again on reboot, so a later enable by a known operator can be expected.
administrators intentionally enable or disable workspace features during rollout.
administrators legitimately enabling external sharing for a new collaboration site or project.
administrators list virtual machines during maintenance and troubleshooting. review whether the same session then kills those processes or searches the datastore.
administrators mark a maintenance or support script executable during a change window. confirm the path, the account, and whether the same session then executes a file from `/tmp` or enumerates virtual disks.
administrators may add external users to groups to share files and communication with them via the intended recipient be the group they are added to. it is unlikely an external user account would be added to an organization's group where administrators should create a new user account.
administrators may create drive data transfer requests during employee offboarding to preserve files for a manager or successor account.
administrators may create or change gmail routing, dual-delivery, address maps, or mail hosts for migrations, journaling, spam handling, or partner integrations.
administrators may delete kubernetes event objects during routine troubleshooting or cleanup. confirm the actor, scope, and timing before treating the activity as malicious.
administrators may delete resource groups during decommissioning, lab cleanup, or organizational restructuring. verify the actor, change ticket, and whether the deleted group was non-production before treating the event as malicious.
administrators may enable hostipc for legitimate debugging. exclude trusted users or namespaces after baselining.
administrators may grant impersonation roles when onboarding new applications or delegating access. verify that the grant aligns with a known change and that both the granting principal and the added member are expected.
administrators may legitimately add security group rules to allow traffic from any ip address or from specific ip addresses to common remote access ports.
administrators may legitimately enable serial console access during troubleshooting of instances with boot issues, network misconfigurations, or ssh access problems. verify whether the user identity, user agent, and/or source ip should be making changes in your environment. serial console access enablement by unfamiliar users or from unexpected locations should be investigated. if this is expected behavior for troubleshooting, it can be exempted from the rule, but ensure serial console access is disabled after troubleshooting is complete.
administrators may legitimately use cloudshell for iam management tasks during routine operations or troubleshooting. verify whether the user, source ip, and specific actions align with expected administrative workflows. establish a baseline of normal cloudshell usage patterns to reduce false positives.
administrators may mark accounts as compromised during security testing or incident response exercises. if this is expected behavior in your environment, consider adjusting the rule or adding exceptions for specific test accounts.
administrators may remove 2-step verification (2sv) temporarily for testing or during maintenance. if 2sv was previously enabled, it is not common to disable this policy for extended periods of time.
administrators may temporarily disabled bitlocker on managed devices for maintenance, testing or to resolve potential endpoint conflicts.
administrators may upload ssh public keys to ec2 instances for legitimate purposes.
administrators may use ec2 instances to interact with iam services as part of an automation workflow, ensure validity of the triggered event and include exceptions where necessary.
administrators may use the tasklist command to display a list of currently running processes. by itself, it does not indicate malicious activity. after obtaining a foothold, it's possible adversaries may use discovery commands like tasklist to get information about running processes.
administrators or automated systems may legitimately perform multiple `describe`, `list`, `get` and `generate` api calls in a short time frame. verify the user identity and the purpose of the api calls to determine if the behavior is expected.
administrators or ci jobs using a new workstation, bastion, vpn egress, or nonstandard api client can produce a first-seen alert; confirm against change records and expected automation.
administrators or developers may execute kubeletctl during legitimate troubleshooting or incident response to validate kubelet api connectivity or enumerate pods. confirm the user/session and change window before escalating.
administrators or developers who are unaware of the deprecation status of amis they are using.
administrators power off virtual machines for patching, decommissioning, and hardware maintenance. review the account and whether the command targeted one vm id or every id returned by `getallvms`.
administrators reading kubeconfig or cloud profiles during migration can match; correlate with change tickets and bastion sessions.
administrators rotate the root password during scheduled maintenance. confirm the change ticket and that the new password was stored with the approved break-glass process.
administrators routinely exec into pods for troubleshooting. baseline expected users and target pods, then exclude known break-glass or operator identities after review.
administrators run these commands during inventory, troubleshooting, and support. review whether the same session continues into virtual machine shutdown, snapshot removal, or a datastore search.
administrators sign in to the host client or the api as root from a jump host during maintenance. confirm the source address is a known workstation and that the session does not continue into ssh enablement, file copies to `/tmp`, or virtual machine shutdowns.
administrators sometimes force a vendor vib during a documented recovery or upgrade when the acceptance level would otherwise reject it. confirm the vib name against the change ticket.
administrators troubleshooting rbac from a workstation or vpn may generate mixed allow/deny results across many apis in a short window; tune by identity or source ip after validation.
administrators use `wget` to download a patch, vib, or support script during maintenance. confirm the url and whether the same session continues into file execution or virtual machine shutdown.
administrators using service principal credentials to manage arc-connected clusters during maintenance windows may trigger this rule. correlate with change management records.
administrators with owner or contributor roles opening the keys and endpoint blade in the azure portal or foundry portal, which issues a listkeys call. confirm the activity with the principal and prefer entra id authentication over key-based access.
administrators within an aws organization structure may legitimately suspend object versioning. ensure that this behavior is not part of a legitimate operation before taking action.
administrators, developers, ci runners, and saas egress often exit through datacamp, m247, vultr, linode, or brand-name vpn asns. expect more noise on hosting asns than on vpn-only registrations. exclude approved principals, accounts, cidrs, or asns after review. geoip and asn enrichment gaps (`source.as.number` unset) will skip events entirely. maintain the asn list with local intelligence (for example ripe, bgpview, or peeringdb).
aggressive safetysettings (for example block_low_and_above) on red-team or content-moderation workloads can produce frequent safety finishes. exclude those projects or models, or require concurrent high/medium ratings.
ai coding assistants running on cloud instances may read their own credential file and then fall back to the instance metadata service for cloud provider authentication (for example gemini cli on google compute engine). confirm the process is the assistant itself and that the credential file belongs to that assistant.
ai platform administrators tuning content filter thresholds or blocklists for a new use case. confirm the change with the account owner and change records.
ami sharing is a common practice in aws environments. ensure that the sharing is authorized before taking action. aws marketplace subscriptions automatically result in assets.marketplace.amazonaws.com invoking modifyimageattribute to share the ami with your account. this rule excludes marketplace-invoked sharing by design. other aws services like workspaces.amazonaws.com and backup.amazonaws.com may invoke this action when users configure sharing through workspaces or backup plans. review such service-invoked events to confirm they match legitimate and intended sharing configurations.
an administrator can reset the loghost while moving the host to a new collector. confirm that a new `--loghost` value was set in the same change and that logs are arriving at the collector.
an administrator deletes a rotated log under `/var/log` during a documented maintenance window. confirm the path and the change ticket.
an administrator may need to attach a hostpath volume for a legitimate reason. this alert should be investigated for legitimacy by determining if the kuberenetes.audit.requestobject.spec.volumes.hostpath.path triggered is one needed by its target container/pod. for example, when the fleet managed elastic agent is deployed as a daemonset it creates several hostpath volume mounts, some of which are sensitive host directories like /proc, /etc/kubernetes, and /var/log. add exceptions for trusted container images using the query field \"kubernetes.audit.requestobject.spec.container.image\"
an administrator may need to exec into a pod for a legitimate reason like debugging purposes. containers built from linux and windows os images, tend to include debugging utilities. in this case, an admin may choose to run commands inside a specific container with kubectl exec ${pod_name} -c ${container_name} -- ${cmd} ${arg1} ${arg2} ... ${argn}. for example, the following command can be used to look at logs from a running cassandra pod: kubectl exec cassandra --cat /var/log/cassandra/system.log . additionally, the -i and -t arguments might be used to run a shell connected to the terminal: kubectl exec -i -t cassandra -- sh
an administrator may submit this request as an \"impersonateduser\" to determine what privileges a particular service account has been granted. however, an adversary may utilize the same technique as a means to determine the privileges of another token other than that of the compromised account.
an administrator or developer may want to use a pod that runs as root and shares the hosts ipc, network, and pid namespaces for debugging purposes. if something is going wrong in the cluster and there is no easy way to ssh onto the host nodes directly, a privileged pod of this nature can be useful for viewing things like iptable rules and network namespaces from the host's perspective. add exceptions for trusted container images using the query field \"kubernetes.audit.requestobject.spec.container.image\"
an administrator who mistypes the root password in the host client a few times can reach three failures. confirm the source address is a known workstation and that a successful login did not follow.
an agentcore agent that legitimately integrates with additional aws services will produce a first-time service call for its execution role. verify the role in \"aws.cloudtrail.user_identity.session_context.session_issuer.arn\", the action in \"event.action\" and \"event.provider\", and the origin in \"source.ip\" and \"source.as.organization.name\", and confirm the activity matches the agent's intended design. known agent integrations can be excluded after validation.
an anti-phishing policy may be deleted by a system or network administrator. verify that the configuration change was expected. exceptions can be added to this rule to filter expected behavior.
an anti-phishing rule may be deleted by a system or network administrator. verify that the configuration change was expected. exceptions can be added to this rule to filter expected behavior.
an okta admnistrator may be logged into multiple accounts from the same host for legitimate reasons.
an rds security group deletion may be done by a system or network administrator. verify whether the user identity, user agent, and/or hostname should be making changes in your environment. security group deletions by unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
an rds security group may be created by a system or network administrator. verify whether the user identity, user agent, and/or hostname should be making changes in your environment. security group creations by unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
anonymous access to the api server is a dangerous setting enabled by default. common anonymous connections (e.g., health checks) have been excluded from this rule. all other instances of authorized anonymous requests should be investigated.
anonymous api access is a dangerous default. health probes are excluded; investigate all other authorized anonymous requests and disable anonymous authentication where possible.
anonymous pod writes should be rare. if observed from expected automation, anonymous authentication or rbac for system:anonymous is likely misconfigured and should be remediated rather than broadly excluded.
application credential additions may be done by a system or network administrator. verify whether the username, hostname, and/or resource name should be making changes in your environment. application credential additions from unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
application defects, stress tests, or intentionally low php memory limits may generate similar errors. confirm the complete signature, source, timing, and surrounding requests before escalating.
application installers, software-management systems, and administrators may legitimately set systemcomponent during deployment, updates, packaging, or shared-device and kiosk hardening. confirm the matched branch, binary or uninstall target, initiating identity, host, parent process, and change window against the change record before adding a narrow exception.
application migrations or reconfigurations that switch from certificate/secret authentication to federated credentials will appear as new behavior. confirm with application owners.
application onboarding, directory synchronization, inventory tools, and permission-validation scripts may query multiple directory collections and encounter expected access denials.
application teams and infrastructure-as-code pipelines routinely create event source mappings to wire data pipelines, queue consumers, and stream processors to lambda functions. verify whether the principal in `aws.cloudtrail.user_identity.arn`, the function, and the event source are expected for the workload. known deployment roles and automation can be excluded after validation.
applications can be added and removed from blocklists by google workspace administrators, but they can all be explicitly allowed for users. verify that the configuration change was expected. exceptions can be added to this rule to filter expected behavior.
applications can be added to a google workspace domain by system administrators. verify that the configuration change was expected. exceptions can be added to this rule to filter expected behavior.
applications for password management.
applications that intentionally allow unauthenticated identity pool access for legitimate purposes (for example, anonymous usage analytics or unauthenticated content delivery) will trigger this rule the first time that pattern is observed for a given identity pool. confirm whether the pool's unauthenticated role grants only the minimal permissions the application actually needs, and treat repeated alerts for the same pool as expected once validated.
applications will tag the operating system as null when the device is not recognized as a managed device. in environments where users frequently switch between managed and unmanaged devices, this may lead to false positives.
approved agentcore browsers or code interpreters that require public egress, such as a code interpreter installing packages or a browser tool reaching external sites, created by a known platform or ci/cd principal. validate the caller, the attached execution role, and whether vpc or sandbox network mode was required by policy.
approved automation that uses chatgpt's slack connector for triage or knowledge lookup. raise the distinct-query threshold if those roles remain noisy.
approved automation, compliance api tooling, or sso libraries that use non-browser user agents.
approved automation, platform controllers, or gitops may update the coredns configmap (for example custom forward rules). validate the identity and change window, and add exclusions for verified service accounts.
approved batch evaluation clients or shared nat egress. raise the threshold or exclude known source ip prefixes.
approved batch evaluation or high-traffic applications. raise thresholds above the normal peak per model.
approved batch jobs, evaluation harnesses, and user-facing apps that fan out from one nat. exclude that caller ip prefix and deployment, or raise the thresholds to sit above the normal 9-minute peak.
approved certificate workflows (for example cert-manager, internal pki rotation, or node bootstrap) may create or update csrs from identities not in the exclusion list if they run under a custom service account. baseline automation that legitimately approves csrs and tune exclusions for those principals.
approved credential-rotation automation may create and immediately validate or use a replacement access key. confirm the principal, source addresses, user agents, timing, and change records. exclude only verified rotation workflows.
approved internal automation, ci jobs, or sdk integrations may present scripting user agents. validate the actor, source ip, and action against change tickets before treating as compromise. prefer excluding stable identities or source networks rather than removing the matching user-agent pattern.
approved mcp apps such as slack or ticketing connectors generate routine traffic during normal work. first-seen alerts are common during onboarding when a user first uses an approved app.
approved platform engineering changes that update publisher logging destinations. confirm the actor and change ticket.
approved prompt-security or dlp validation tests may intentionally submit synthetic secrets.
approved prompt-security tests that send known jailbreak strings, such as dan or \"ignore previous instructions\". exclude that source ip or api management subscription.
approved red-team or evaluation prompts that deliberately include jailbreak strings. exclude known test principals or lower severity for those models.
approved red-team or prompt-security evaluations that intentionally elicit refusals. exclude those users or raise the count threshold.
approved red-team suites that intentionally elicit refusals. exclude those models or raise the threshold.
approved red-team, evaluation, or detection-engineering tests that deliberately include jailbreak strings (such as dan or \"ignore previous instructions\") in prompts or regex experiments run through genai agent shells. exclude known lab hosts or lower severity after validation.
approved research projects that document block_none for evaluation. prefer labeled service accounts and exclude those principals.
approved rmm deployments, one-time support sessions, product migrations, and security testing can trigger this rule. recursive resolvers or dns forwarders can also appear as the client when sensor placement does not preserve the originating endpoint address.
approved rollout of codex plugins such as slack, gmail, or google drive for engineering or support teams. confirm the plugin against your workspace connector inventory and change process before escalating.
approved runbooks or support sessions may use kubectl exec with curl/wget to test egress or download vendor tools.
approved scripts, ci jobs, or penetration tests may use generic http clients. validate change tickets and identity scope before treating as compromise. internal automation using generic libraries can be excluded by stable service account after review.
approved third-party applications that use google drive download urls.
assignment of rights to a service account.
assumed roles may be used by legitimate automated systems to create iam users for specific workflows. verify if this event aligns with known automation activities. if the action is routine for specific roles or user agents (e.g., `aws-cli`, `boto3`), consider adding those roles or user agents to a monitored exception list for streamlined review.
audit settings change during collector maintenance. confirm that transmission was enabled again and that the change matches a ticket.
authorization rule additions or modifications may be done by a system or network administrator. verify whether the username, hostname, and/or resource name should be making changes in your environment. authorization rule additions or modifications from unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
authorized administrators may delete web acls as part of planned migrations, infrastructure refactoring, or automation-driven redeployments. ensure the deletion aligns with approved change requests, maintenance windows, or known iac workflows. deletions performed by unfamiliar users, unusual identities, or unexpected automation should be investigated.
authorized administrators may temporarily stop the aws config recorder during planned maintenance, account restructuring, or controlled configuration changes. automated infrastructure or compliance tooling may also stop and restart the recorder as part of setup or teardown workflows. activity outside of documented change windows or from unexpected identities should be investigated.
authorized administrators or automated workflows may purge sqs queues for legitimate operational reasons, such as clearing stale messages, resetting test environments, or performing approved maintenance. verify that the action aligns with documented procedures and expected operational behavior.
authorized administrators or automation may purge multiple queues during maintenance, testing, disaster recovery, or application resets. confirm the client, authenticated rabbitmq user, affected queues, and change window before escalating. add exceptions for verified administrative sources rather than reducing the queue-cardinality threshold.
authorized ai agent workflows that include shell or filesystem tools may trigger this rule. validate that the user identity and tool usage pattern are consistent with expected application behavior.
authorized github actions runner with no malicious workflow actions.
authorized github repository with no malicious workflow actions.
authorized heavy usage of the system that is business justified and monitored.
authorized infrastructure teardown automation may legitimately invoke these commands. correlate with change management records and known deployment pipeline identities before escalating.
authorized inventory jobs, secret migration tools, and multi-vault deployment pipelines may retrieve many secrets across several vaults within 15 minutes.
authorized it or managed service provider deployment of remote monitoring and management software through vendor, internal, or other software distribution infrastructure can produce this behavior.
authorized model training
authorized penetration tests, red team exercises, or research activity may originate from kali linux. internal secret scanning pipelines may run trufflehog with permission to reach aws for verification. validate the iam principal, source network, change records, and whether the activity matches documented security or devsecops workflows.
authorized red team activity exercising roadrecon. document the engagement window and add exceptions on the source ip or calling user.
authorized red team activity. document and add exceptions on the user, app id, or source ip.
authorized red team engagements and cloud security assessments use the same frameworks. correlate with known assessment windows, operator identities, and approved change records before escalating.
authorized red team or audit activity (roadrecon, roadtools, aadinternals, roadtx). document the engagement window and add exceptions on the calling user.
authorized red team or audit activity. add exceptions on the calling user after review.
authorized red team or penetration test activity using roadrecon, roadtools, aadinternalsor similar tooling can match. add exceptions on the source ip, signed-in user, or app id after validation.
authorized red team or penetration testing engagements that register devices and exercise prts will match this sequence. document the engagement and add scoped exceptions for the involved principals or source addresses.
authorized red team or penetration testing engagements that use roadtools to register devices will match this rule. if this is expected, add exceptions for the specific user principal names, source ips, or device names involved.
authorized red team or penetration testing that uses roadtools or phishing-kit infrastructure to register devices will match this rule. if this is expected, add exceptions for the specific user principal names, source ips, or device names involved.
authorized red team or research engagements that borrow a whfb/passkey and register a device will match. document the engagement and add scoped exceptions for the involved principals or source addresses.
authorized red-team or penetration testing tooling exercising the cve-2026-20253 exploit chain. legitimate splunk user activity should not produce postgresql connection-string keywords, suspicious filesystem targets, empty basic auth credentials, or unauthenticated 400 responses on the recovery endpoints.
authorized security testing may deliberately write a harmless forged pitboss or ppe record to validate exposure or detection. confirm the source and testing window. normal pitboss and packet-engine records should not contain shell separators, command substitution, pipes, or redirection.
authorized security testing or a purpose-built synthetic process fixture may reproduce this lineage. patched zimbra 10.1.20 and later invokes `snmptrap` without passing the attacker-controlled value through a shell. on vulnerable installations, legitimate monitoring should launch `snmptrap` from the shell but should not launch another child.
authorized self-hosted github actions runner.
authorized softwareupdate settings changes
authorized third party network logon providers.
authorized third-party applications or services that use the specified client application id to access microsoft graph api resources for legitimate purposes.
authorized vulnerability research or penetration testing of php2shell will trigger this rule.
authorized vulnerability scanners (nessus, tenable, qualys, etc.) running cve-2026-41940 plugins will reproduce the exploit shape. validate against scan windows and source ips of approved scanners before escalating.
automated agents, chat applications, retrieval-augmented generation services, evaluation pipelines, and load tests routinely generate high bedrock inference volume against one model and will exceed any fixed threshold. validate the principal, user agent, source ip, and application context before treating the activity as malicious, and tune the threshold to the deployment.
automated configuration management or monitoring scripts that use lolbins via ssm for legitimate purposes. consider excluding known automation accounts or specific command patterns.
automated infrastructure tests that create and immediately tear down eks access entries as part of ci/cd validation may trigger this rule. validate that the sequence corresponds to a documented test pipeline.
automated integrations or scripts using service accounts with session cookies may trigger user-agent based detection. consider excluding known automation accounts by okta.actor.alternate_id.
automated mailbox rules that move security notifications to specific folders.
automated monitoring or penetration testing tools scanning from multiple ips.
automated monitoring scripts, infrastructure inventory tools, or ci/cd pipelines that use long-term iam keys to audit ses configuration will trigger this rule. migrate automation to iam roles with short-lived credentials; long-term keys used for ses management are a security anti-pattern regardless of this alert.
automated monitoring tools or compliance audit scripts using long-term iam keys to inventory backup coverage will trigger this rule. migrate automation to iam roles with short-lived credentials. long-term key usage for backup management is a security anti-pattern.
automated password reset flows where a user fails multiple times then succeeds after resetting their password.
automated processes or misconfigured applications retrying authentication may trigger this rule.
automated processes that attempt to authenticate using expired credentials or have misconfigured authentication settings may lead to false positives.
automated provisioning tools or scripts that assign site admin roles during site creation workflows.
automated scripts or processes that retrieve secrets or keys for legitimate purposes, such as secret rotation or application configuration, may also lead to false positives.
automated scripts or processes that use azcopy for routine data transfers from azure storage accounts.
automated testing or monitoring tools that do not persist cookies may trigger this rule.
automated tools or scripts that query for deprecated amis as part of a security assessment.
automated tools such as jenkins may encode or decode files as part of their normal behavior. these events can be filtered by the process executable or username values.
automated workflows might assume root to perform periodic administrative tasks.
automation or sdk tooling configured with a bedrock api key may call non-bedrock apis for benign credential validation. ubiquitous no-op sts identity calls (getcalleridentity, getsessiontoken, getaccesskeyinfo) are excluded; other non-bedrock activity by a bedrockapikey-* principal — recon, privilege escalation, lateral movement, or exfiltration — is unexpected for an inference-only key. confirm the key and source in \"source.ip\"/\"user_agent.original\" are sanctioned.
automation that both submits and approves csrs in one workflow may trigger this rule. baseline cert-manager or internal pki pipelines and tune exclusions for known service accounts.
automation that intentionally manages bedrock resources using an api key could match. confirm the principal in \"aws.cloudtrail.user_identity.arn\", the affected resource in \"aws.cloudtrail.request_parameters\", and whether the change was expected. known maintenance principals can be excluded after validation.
automation, ci runners, and platform engineering scripts may legitimately print tokens or dump kubeconfig across providers in one session. baseline approved identities and runner images before tuning thresholds.
aws accounts may be legitimately closed as part of organizational restructuring, account consolidation, or decommissioning of workloads. legitimate closures should always have a corresponding change-management record and documented approval; any closure without one should be treated as a critical incident.
aws administrators or automated processes might regularly assume roles for legitimate administrative purposes and to perform periodic tasks such as data backups, updates, or deployments.
aws administrators or automated processes might regularly assume root for legitimate administrative purposes.
aws credentials legitimately shared between github actions and another microsoft/azure service may trigger this rule. verify whether the non-ci/cd source ip is expected for the workload.
aws iam roles anywhere trust anchors are legitimate profiles that can be created by administrators to allow access from any location. ensure that the trust anchor is created by a legitimate administrator and that the external certificate authority is authorized.
aws roles anywhere profiles are legitimate profiles that can be created by administrators to allow access from any location. ensure that the profile created is expected and that the trust policy is configured securely.
aws services might assume root to access aws resources as part of their standard operations.
azure ad connect or adfs provisioning can legitimately modify msds-keycredentiallink when the writer account, source, object class, target dn, bounded change set, and post-change authentication all match an expected workflow.
azure arc system components may create or update secrets and configmaps in the azure-arc and azure-arc-release namespaces during normal cluster management. filter by namespace to exclude these.
azure front web application firewall (waf) policy deletions may be done by a system or network administrator. verify whether the username, hostname, and/or resource name should be making changes in your environment. azure front web application firewall (waf) policy deletions by unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
b2b collaboration migrations where external users are intentionally promoted to full membership. organizational restructuring that converts former contractors to permanent employees in place.
backup deduplication engines, migration utilities, and filesystem sync tools can generate high volumes of legitimate nfs writes. validate the source against known backup or storage-management hosts before escalating.
backup, configuration management, and image scanners may open the same paths from scripted utilities; baseline trusted agents and narrow exclusions by process executable hash or parent chain.
backup, platform, or infrastructure-as-code teams may delete recovery points during retention cleanup, migration, or decommissioning. verify the principal in \"aws.cloudtrail.user_identity.arn\", the affected recovery point and vault in \"aws.cloudtrail.request_parameters\", and whether the deletion aligns with an approved change. known administration roles can be excluded after validation.
base images, entrypoints, or init wrappers may legitimately invoke curl or wget during container startup (package installs, health checks); baseline trusted images and exclude stable image digests or namespaces when noisy.
based on the high-frequency threshold, it would be unlikely for a legitimate user to exceed the threshold for failed totp code attempts in a short time-span over multiple sessions.
because these ports are in the ephemeral range, this rule may false under certain conditions such as when a nated web server replies to a client which has used a port in the range by coincidence. in this case, such servers can be excluded if desired. some cloud environments may use this port when vpns or direct connects are not in use and database instances are accessed directly across the internet.
because this port is in the ephemeral range, this rule may false under certain conditions, such as when a nated web server replies to a client which has used a port in the range by coincidence. in this case, such servers can be excluded. some applications may use this port but this is very uncommon and usually appears in local traffic using private ips, which this rule does not match. some cloud environments, particularly development environments, may use this port when vpns or direct connects are not in use and cloud instances are accessed across the internet.
bedrock agent and action group changes are common during legitimate development, prompt tuning, and ci/cd deployments. verify whether the user identity, user agent, and/or source ip should be modifying agents in your environment, and confirm a corresponding change request exists. automation roles (iac pipelines, deployment tooling) may routinely call these apis and can be exempted from the rule if they generate false positives.
benign base64 examples, git commit shas, and ordinary requests can still score above 0.98. the completion step is expected to label those fp. an alert means the completion model confirmed the message as a jailbreak, prompt injection, or obfuscated payload.
benign files can trigger signatures in the built-in virus protection
blob permissions may be modified by system administrators. verify that the configuration change was expected. exceptions can be added to this rule to filter expected behavior.
blue/green deployments, instance remediation, and automation may rebind instance profiles intentionally. confirm the instance id, new `iaminstanceprofile` or `iaminstanceprofile` arn, and change records. exclude known automation roles after validation.
borderline creative-writing or news-summarization prompts can occasionally score medium. confirm category and prompt text before escalating.
bounded troubleshooting, ir, lab-validation, or red-team activity where the reconstructed target/output, launch context, and artifact/authentication evidence align.
break-glass admin tooling, security scanners, or approved controllers that legitimately use impersonation with privileged targets may match if not covered by exclusions. map expected callers and expand `not user.name` filters as needed for your environment.
break-glass debugging from platform engineers may include curl to the metadata ip or hostname.
break-glass debugging or vendor diagnostics may cat credential-adjacent paths. baseline approved operators and automation identities, then expand client.user.email exclusions as needed.
break-glass troubleshooting by administrators using curl against 168.63.129.16. confirm the change window and exclude the admin host or user if the activity is authorized.
briefly disabling restrictions to onboard an approved vendor app. re-enable immediately and approve that app explicitly instead when possible.
broken automation, expired tokens, or inventory tools hitting renamed repositories. review the routes and whether the token is expected.
browsers, download utilities, and security tools may remove mark-of-the-web during legitimate file handling.
bucket configurations may be deleted by a system or network administrator. verify whether the user identity, user agent, and/or hostname should be making changes in your environment. bucket configuration deletions by unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
bucket logging may be disabled by a system or network administrator. verify whether the user identity and/or user agent should be making changes in your environment. bucket component deletions by unfamiliar users should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
build and packaging images sometimes run chroot against a staged root filesystem inside ci or init containers; correlate with approved pipelines and image build jobs before escalating.
build servers and ci systems can sometimes trigger this alert. security test cycles that include brute force or password spraying activities may trigger this alert.
build systems and ci runners frequently compile or download binaries into temporary directories and then make aws api calls as part of integration tests. exclude known runner paths and restrict to interactive or production hosts if alert volume is high.
build systems, like jenkins, may start processes in the `/tmp` directory. these can be exempted by name or by username.
built-in controller service accounts are rarely assigned to running pods. false positives should be rare; allowlist documented platform automation by actor when baselined.
bulk device enrollment campaigns (e.g., mdm rollout, fleet refresh) where many users register the same new device type in a short window. consider suppressing during planned rollouts.
bulk provisioning workflows, autopilot/mdm rollouts, or device-management tooling that registers devices on behalf of users may generate multiple registrations across many users at once. suppress during planned rollout windows.
business travelers who roam to new locations may trigger this alert.
business workflows that occur very occasionally, and involve a business relationship with an organization in a country that does not routinely appear in network events, can trigger this alert. a new business workflow with an organization in a country with which no workflows previously existed may trigger this alert - although the model will learn that the new destination country is no longer anomalous as the activity becomes ongoing. business travelers who roam to many countries for brief periods may trigger this alert.
business workflows that occur very occasionally, and involve an unusual surge in network traffic, can trigger this alert. a new business workflow or a surge in business activity may trigger this alert. a misconfigured network application or firewall may trigger this alert.
by default a container is not allowed to access any devices on the host, but a \"privileged\" container is given access to all devices on the host. this allows the container nearly all the same access as processes running on the host. an administrator may want to run a privileged container to use operating system administrative capabilities such as manipulating the network stack or accessing hardware devices from within the cluster. add exceptions for trusted container images using the query field \"kubernetes.audit.requestobject.spec.container.image\"
capacity reports, backup troubleshooting, and support scripts list `vmdk` files on a datastore. review the account and whether the search was followed by process kills or snapshot removal.
carrier-grade nat or load-balanced corporate egress that occasionally routes through alternate asns.
cdn, cloud load-balancer, software-update, and telemetry hostnames can be long and change often. recursive resolvers, forwarders, nat gateways, and localhost dns listeners can also combine queries from many endpoints under one client address. dns research, testing, and security tools can generate null or unusually long txt queries. validate the apex domain and whether the source is an endpoint before treating the activity as tunneling.
certain applications may install root certificates for the purpose of inspecting ssl traffic.
certain kinds of security testing may trigger this alert. powershell scripts that use high levels of obfuscation or have unusual script block payloads may trigger this alert.
certain programs or applications may modify files or change ownership in writable directories. these can be exempted by username.
certain tools may create hidden temporary directories upon installation or as part of their normal behavior. these events can be filtered by the process arguments, username, or process name values.
certain tools may create hidden temporary files or directories upon installation or as part of their normal behavior. these events can be filtered by the process arguments, username, or process name values.
certain tools or automated software may enumerate hardware information. these tools can be exempted via user name or process arguments to eliminate potential noise.
certain utilities that delete files for disk cleanup or administrators manually removing backup files.
changes to the shell profile tend to be noisy, a tuning per your environment will be required.
changes to windows services or a rarely executed child process.
ci, laptops, or travel networks using the same pat or oauth token from a new egress ip. confirm the token owner and whether the repositories are expected.
ci/cd pipelines that authenticate as a service principal and then access arc clusters as part of deployment workflows will trigger this rule. identify and exclude known automation service principal app ids.
cloud administrators and machine-learning teams routinely enable model access, submit use cases, and accept model end-user license agreements (eulas) during account onboarding or when adopting a new foundation model. verify that the principal, source ip, and user agent are expected and that the change aligns with a known onboarding or provisioning activity before escalating. if this activity is expected and authorized for specific principals, consider adding exceptions for those users or roles.
cloud agents (ssm, waagent, cloud-init, instance connect) and authorized scanners may reach the same paths during provisioning or health checks. exclude known agent user agents, source hosts, or parent processes after baselining.
cloud egress, split-tunnel, or dual-homed clients that present different public ips for concurrent anthropic sessions (for example browser and api tooling) can look like impossible travel when both resolve far apart.
cloud infrastructure teams requesting quota increases for planned capacity expansions, new region deployments, or scaling events will trigger this rule. validate the requested service and limit against your infrastructure roadmap before closing.
cloud or security administrators may legitimately delete or reconfigure bedrock model invocation logging during onboarding, log destination migrations, or compliance changes. verify whether the user identity, user agent, and source ip are expected to make this change. for putmodelinvocationloggingconfiguration, confirm that the destination s3 bucket or cloudwatch log group remains owned and monitored by your organization. known, planned changes can be exempted from this rule.
cloud-hosted internal automation running outside the major providers (smaller cloud or colo). add exceptions on the calling user or app id after validation.
cloudwatch alarm deletions can occur legitimately during scheduled maintenance, infrastructure redeployments, or automation workflows that clean up temporary monitoring configurations. verify that the user identity, role, and ip address are expected for the environment. if deletions are performed by ci/cd pipelines or authorized administrators during controlled operations, consider adding exceptions based on specific iam roles, automation accounts, or ip address ranges.
cloudwatch log group deletions may occur during normal maintenance or infrastructure re-deployments, especially in environments managed by iac tools (e.g., terraform, cloudformation, cdk). automation pipelines may recreate log groups as part of expected workflows. verify that the identity, user agent, and source ip match approved administrative or automation activity. if deletions are routine for specific automation roles or ci/cd hosts, consider adding scoped exceptions.
cloudwatch log streams may be deleted legitimately during log rotation processes, test environment resets, or infrastructure deployments that recreate log groups and streams. validate the identity, automation pipeline, and ip address associated with the deletion. if deletions are expected from specific ci/cd systems or administrative roles, consider adding targeted exceptions.
cluster administrators may legitimately update coredns configuration for forwarding, stub domains, or cluster dns troubleshooting. baseline approved operators and automation identities; tune exclusions for known change pipelines.
cluster operators and gitops automation may legitimately install or upgrade admission controllers (e.g. cert-manager, gatekeeper, kyverno, service mesh components). validate change tickets and approved controllers before tuning.
cluster operators and node diagnostics may legitimately probe kubelet endpoints (for example /pods or /metrics) during troubleshooting. validate the initiating user, session, and whether the target node/ip is expected for the host.
cluster operators or sres may legitimately use ephemeral containers for debugging production workloads. baseline approved admin identities and tune exclusions for known automation.
cluster provisioning (kubeadm), configuration management, or administrators editing manifests during maintenance may match. baseline approved automation and interactive admin sessions on control plane nodes.
cluster provisioning, gitops, or approved platform automation may perform these apis under iam principals whose arns do not match the exclusion patterns. baseline expected roles and expand exclusions if needed.
command execution on a virtual machine may be done by a system or network administrator. verify whether the username, hostname, and/or resource name should be making changes in your environment. command execution from unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
common google drive/gmail and slack connector app_id values are excluded; other sanctioned connectors may still alert.
compliance, legal, and platform teams download organization data exports after scheduled audits, migrations, or litigation holds. validate the actor and business justification before escalating.
configuration management (ansible, cloud-init) and bootstrap scripts that write ~/.aws/config run as generic interpreters (python3, bash) and will trigger this rule. add exceptions on host.name, user.name, or process.executable for known provisioning hosts and pipelines. dotfile managers (chezmoi, stow, yadm) and package managers are excluded by process name.
consider adding exceptions to this rule to filter false positives if okta mfa rules are regularly modified in your organization.
consider adding exceptions to this rule to filter false positives if okta policies are regularly modified in your organization.
consider adding exceptions to this rule to filter false positives if oyour organization's okta network zones are regularly modified.
consider adding exceptions to this rule to filter false positives if sign on policies for okta applications are regularly modified or deleted in your organization.
consider adding exceptions to this rule to filter false positives if the mfa factors for okta user accounts are regularly reset in your organization.
consider adding exceptions to this rule to filter false positives if your organization's okta applications are regularly deleted and the behavior is expected.
controlled red-team, malware-analysis, detection-validation, or harness activity where script content, target process set, origin, user/host scope, and recovered launcher align.
controller service accounts aren't normally assigned to running pods, this is abnormal behavior with very few legitimate use-cases and should result in very few false positives.
controller upgrades, sidecar replacements, or client library version bumps change user agents and can produce a first-seen alert for known service accounts. confirm the new client is expected before treating as compromise.
controllers, ci/cd systems, and platform components legitimately request service account tokens. baseline the requesting identities and exclude verified automation after review.
coordinated maintenance that expands rbac and rolls workloads in the same change window may alert; validate against change tickets and the actor's expected client fingerprint.
corporate proxy or vpn exit nodes may aggregate traffic from multiple legitimate users.
cost-control or license changes that turn ghas off for archival orgs. confirm billing intent and that production orgs remain covered.
creating specific groups via the exchange online powershell module will make exchange use an actor token on your behalf. the rule excludes group operations and directory feature operations to reduce false positives from these legitimate administrative activities.
credential reads under non-root home trees are intentionally excluded; clone the rule with explicit per-user file.path values and optional process.executable prefixes if you must cover interactive accounts with matching audit -w lines for those paths.
cross-account db snapshot sharing is common in multi-account aws organizations, particularly for backup workflows, migrations, analytics pipelines, and disaster recovery. ensure the added account is expected, previously approved, and aligns with operational change plans before taking action.
cross-account invoke permissions are used for legitimate multi-account architectures and partner integrations. verify the granted account in `aws.cloudtrail.request_parameters`, the function, and the `principal` value in `aws.cloudtrail.request_parameters` against approved cross-account access. known partner or internal account ids can be excluded after validation. this rule cannot distinguish a grant to the function's own account from an external account, so same-account resource-policy grants (uncommon, since same-account invocation normally uses iam identity-based policies) will also alert.
cross-account kms key usage may be legitimate in multi-account aws organizations architectures where centralized encryption keys are used for data governance or auditing workflows. confirm whether the external kms key belongs to an expected account before taking action. data migration or cross-account backup workflows may legitimately re-encrypt s3 objects using a key in another account. ensure these workflows are documented, tied to known iam roles, and occur on predictable schedules.
cross-account s3 replication is common in multi-account aws organizations, centralized logging architectures, and disaster-recovery designs. confirm whether the destination account is an approved replication target. unexpected replication configuration changes should be treated as suspicious.
custom administrative wrappers or hardened images that legitimately ship a setuid shell outside /usr/bin or /bin for emergency access may match; document and exclude by executable hash or path when verified.
custom applications may be allowed by a system or network administrator. verify that the configuration change was expected. exceptions can be added to this rule to filter expected behavior.
custom configuration-management that decrypts cms blobs with an organization key outside /var/lib/waagent. confirm the key path and exclude the specific command line after review.
custom container tooling, ci agents, or monitoring may connect to docker.sock or containerd.sock from non-standard paths after relocation or bind mounts. tune by process.executable or user.name when noise is high.
custom device management agents, oem enrollment clients, or updated microsoft clients that use new user-agent strings may match. add exclusions for known `azure.auditlogs.properties.useragent` values or enrollment programs after review.
custom ecs agent implementations or ecs-agent-compatible schedulers may legitimately contact acs. add their executable paths to the exclusion list. allowlist known sidecar executable paths if alert volume from those containers is high.
custom google workspace admin roles may be created by system administrators. verify that the configuration change was expected. exceptions can be added to this rule to filter expected behavior.
custom health checks that call hostgaplugin /versions or /vmsettings with curl. exclude the specific user agent or host group after validating the script.
custom inventory or health scripts that call wireserver with curl or powershell. validate the command line and exclude the specific signed binary or scheduled task after review.
custom network security rules that triggers on a proxy or gateway used by users to access azure or o365.
custom organization-specific macos packages that use .pkg files to run curl could trigger this rule. if known behavior is causing false positives, it can be excluded from the rule.
custom pki or administrative tooling may legitimately request kubernetes.io/kube-apiserver-client certificates in self-managed clusters. baseline approved operators and tune exclusions for known automation on gke.
custom role creations may be done by a system or network administrator. verify whether the user email, resource name, and/or hostname should be making changes in your environment. role creations by unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
custom windows error reporting debugger or applications restarted by werfault after a crash.
customer takeout exports may be created for legal hold, compliance, migration, or user-requested backups. verify the initiator, target user, and export scope are expected.
data engineers and devops teams legitimately use rclone, s5cmd, and s3cmd for bulk data transfers. this rule gates on a scripted parent to suppress interactive use, but automation pipelines that shell out to these tools may still trigger alerts. the 7-day new-terms window suppresses recurring invocations of the same client on the same host after the first alert. allowlist known pipeline executor paths if additional tuning is needed.
database administrators and scheduled data-processing jobs may legitimately use copy program for import or export workflows. confirm the command, client address, database role, maintenance context, and resulting process activity before escalating.
database administrators may install approved native mysql user-defined functions during planned maintenance. validate the function and library names, the client address, the maintenance window, and whether the shared library was supplied through an approved software deployment process.
database administrators, deployment automation, test teardown jobs, and schema migration tools may issue destructive commands legitimately. validate the client address, target resource, change window, and associated administrator activity before escalating.
debug or break-glass pods may enable privilege escalation intentionally. exclude trusted namespaces, users, or deployment patterns after baselining.
debug pods may legitimately use hostpid. exclude trusted admin workflows after baselining.
decommissioning of a guardduty publishing destination during a planned security architecture migration may trigger this rule. validate that the deletion is associated with a known infrastructure change and that an alternative destination was configured.
delegation by first-party applications that require mailbox access.
deletion of aws config resources may occur during legitimate account restructuring, environment teardown, or changes to compliance tooling. centralized security teams or approved automation may also delete and recreate config components as part of controlled workflows. confirm that the action aligns with approved change management and was performed by an expected principal.
developer activity prototyping against aad graph from a workstation may match. validate via the calling `azure.aadgraphactivitylogs.properties.app_id` and the signed-in user; legitimate developer use is rare in production tenants since microsoft has been steering callers off aad graph for years.
developer activity using aiohttp or python http libraries against aad graph for prototyping. rare in production tenants and typically low-volume.
developer or deployment scripts running on cloud-hosted macos or windows instances may read a package registry or source control token and then request instance role credentials from the same interpreter (for example a release script that publishes a package and uploads artifacts with the instance role). validate the script path, parent process and whether the host is an approved build or release system.
developer or documentation content that legitimately discusses the instance metadata service or aws key formats could match. review the prompt in \"aws.bedrock_agentcore.request_payload.prompt\" to confirm intent.
developer-oriented containers and ci build pods can run curl/wget from pid 1 descendants under runc; correlate with build pipelines and approved registries.
developers adding a key for a new workstation, or administrators adding an approved deploy key for ci/cd or repository automation. confirm the key, source ip, affected account or repository, and expected access level.
developers adding localhost redirect uris for local development environments. ci/cd pipelines updating production redirect uris during deployment. application owners adding redirect uris for new platform support.
developers authorizing approved internal or vendor oauth apps. maintain an allowlist of expected application names and investigate first-time grants from unusual ips or user agents.
developers create codex tokens for ci runners and local environments.
developers downloading archives for offline review, backup jobs, or ci that fetches zipballs. confirm the actor, token type, and whether the repositories are expected.
developers may have a legitimate use for nodeports. for frontend parts of an application you may want to expose a service onto an external ip address without using cloud specific loadbalancers. nodeport can be used to expose the service on each node's ip at a static port (the nodeport). you'll be able to contact the nodeport service from outside the cluster, by requesting <nodeip>:<nodeport>. nodeport unlike loadbalancers, allow the freedom to set up your own load balancing solution, configure environments that aren't fully supported by kubernetes, or even to expose one or more node's ips directly.
developers may legitimately use nodeport for frontends without cloud load balancers, or for nonstandard networking. system:addon-manager patch reconciliation of existing nodeport services is excluded; create and update from addon-manager still alert.
developers may leverage third-party applications for legitimate purposes in google workspace such as for administrative tasks.
developers may paste example keys while debugging or documenting integrations.
developers or administrators creating bedrock agents interactively using personal iam user credentials. this is the intended detection surface — validate the identity against known developer accounts and confirm the agent configuration (instruction, action groups, model) matches a known project.
developers or administrators sending base64-encoded configuration blobs, tokens, or binary artifacts to a model for parsing or analysis. review the decoded content and the surrounding prompt to determine intent.
developers or ci jobs with incomplete rbac can generate denied creates. tune after validating expected identities and namespaces. gke control-plane and bootstrap identities are excluded.
developers or database administrators may deploy approved javascript udfs in environments where scripted functions are intentionally enabled. validate the function body, client address, cassandra version, configuration, and change window before escalating.
developers performing browsers plugin or extension debugging.
developers testing new applications or oauth flows in non-production tenants may generate alerts during development cycles.
developers travelling or switching between home, mobile and corporate networks will appear from a new asn the first time each is used. ci runners and cloud build services appear once per cloud provider asn; add exceptions for known automation identities if the volume is high.
developers who explicitly instruct an agent to tear down a development environment or rotate access keys will trigger this rule. confirm intent with the user before escalating.
developers, analysts, or knowledge workers bulk-uploading documents during migrations, evaluations, or large project onboarding can exceed the daily threshold from a single workstation or vpn egress.
developers, notebooks, and ci service accounts execute sandbox code from new offices, home isps, or cloud egress asns until baselined. exclude known build and research identities after review.
developers, operators, and ci/cd or automation identities legitimately invoke functions directly for testing, operations, and deployments. new automation roles or first-time operators will generate this alert. verify the principal in `aws.cloudtrail.user_identity.arn`, the function, and the source before treating it as malicious, and exclude known operational identities after validation.
development or deployment pipelines that update static frontends frequently (e.g., react/vue apps) may trigger this. verify the user agent, source ip, and whether the modification was expected.
development servers, lab environments, newly stood-up self-hosted services on public ips (vps, homelab, nas, cameras, and similar iot), and some vendor appliances may use recently issued self-signed certificates. exclude known internal development egress or validated vendor destinations after review.
development teams and data pipelines may legitimately use container overrides to parameterize job executions with dynamic inputs. validate that the submitting identity, job queue, and override content are consistent with expected workload behavior.
development tooling that includes git commit shas, docker image digests, or package checksums in prompts for ci/cd automation.
development, staging, and quality-assurance systems may generate frequent novel fatal errors during testing.
devops or it teams performing authorized data transfers or downloads from azure storage using azcopy.
directories /dev/shm and /run/shm are temporary file storage directories in linux. they are intended to appear as a mounted file system, but uses virtual memory instead of a persistent storage device and thus are used for mounting file systems in legitimate purposes.
disabling a dkim configuration may be done by a system or network administrator. verify that the configuration change was expected. exceptions can be added to this rule to filter expected behavior.
disabling encryption may be done by a system or network administrator. verify whether the user identity, user agent, and/or hostname should be making changes in your environment. disabling encryption by unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
disabling mfa delete when rotating the root account credentials used to manage versioning may trigger this rule. this operation requires root account credentials and is uncommon in automated pipelines.
disabling safe links may be done by a system or network administrator. verify that the configuration change was expected. exceptions can be added to this rule to filter expected behavior.
discussions of certificate or tls rotation can match loosely worded replies; this rule requires secret-family terms plus exposure or recognition phrasing to reduce those cases.
distributed ci or multi-region automation that shares one service account across distant egress ips. prefer per-region identities, or raise distance and speed thresholds.
dns domains that use large numbers of child domains, such as software or content distribution networks, can trigger this alert and such parent domains can be excluded.
documentation and unit tests that paste example keys (for example an aws access key ending in example) match the token patterns. confirm the value is live before rotating it.
documentation and unit tests that paste example keys, such as an aws access key ending in example, match the token patterns. confirm the value is live before rotating it.
documentation samples and example keys can match token patterns. confirm the value is live before rotating it.
documentation that mentions \"developer mode\", \"jailbreak\", or \"without restrictions\" in a non-adversarial context. review the full parent and child command lines before escalating.
documentation, examples, or test content may include sample key material. confirm whether the key is live by reviewing \"aws.bedrock_agentcore.request_payload.prompt\" and the originating session and application.
documented disaster-recovery tests. dual-control these events and store codes offline.
documented test of push protection using a dummy token, or a temporary disable while fixing a noisy pattern. re-enable afterward and confirm no live secret was pushed.
domain administrators may use this command-line utility for legitimate information gathering purposes.
domain-wide delegation of authority may be granted to service accounts by system administrators. verify that the configuration change was expected. exceptions can be added to this rule to filter expected behavior.
downloading rar or powershell files from the internet may be expected for certain systems. this rule should be tailored to either exclude systems as sources or destinations in which this behavior is expected.
email retention policies that automatically delete old notification emails.
emergency access during an idp outage. this should be rare, ticketed, and re-enabled immediately.
emergency kubectl changes, vpn or workstation migrations, and ci runner rotation can produce new user agent, source ip, and username combinations for authorized operators. baseline expected automation before tuning.
encryption or platform teams that operate keys with imported key material (byok/hyok) may delete and re-import material during key rotation, migration, or decommissioning. verify the principal in \"aws.cloudtrail.user_identity.arn\", confirm the change aligns with a planned key lifecycle activity, and check whether material was re-imported shortly after. known administration roles and automation can be excluded after validation.
endpoint security installers, updaters and post installation verification scripts.
engineers creating key pairs from home isp, corporate vpn, or colocation as names will match until baselined. geoip databases vary by vendor; organization labels may differ slightly from the excluded strings (for example alternate amazon or google legal names). tune exclusions on `source.as.organization.name` or principal arn after validation.
engineers enable approved codex mcp connectors for github, slack, ticketing, and internal tools during normal development. validate the tool name, connector, and whether the integration matches an approved workflow.
engineers listing secrets from home isp or corporate vpn as names may match until baselined. geoip organization labels vary by vendor; tune exclusions after validation.
enumeration of files and directories may not be inherently malicious and noise may come from scripts, automation tools, or normal command line usage. it's important to baseline your environment to determine the amount of expected noise and exclude any known fp's from the rule.
environments that do not enforce mfa for all iam users will see this regularly. this is a new terms rule, so it only fires once per `user.id` within the configured history window (7d); use it to drive mfa enrollment and enforcement rather than treating every occurrence as an incident, unless mfa is a mandated control in your environment.
event cleanup jobs or platform tooling may bulk-delete events. baseline the responsible identities and exclude verified automation after review.
event hub deletions may be done by a system or network administrator. verify whether the username, hostname, and/or resource name should be making changes in your environment. event hub deletions by unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
eventbridge rules may be disabled or deleted during legitimate maintenance, refactoring, environment teardown, or migration to new event patterns/targets. verify whether the initiating identity, user agent, and source host are expected to administer eventbridge and whether the change aligns with an approved change window or deployment.
events deletions may be done by a system or network administrator. verify whether the username, hostname, and/or resource name should be making changes in your environment. events deletions by unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
example or dummy tokens that are themselves committed to a public repository can still be flagged as publicly leaked. tune by repository, pattern name (`github.secret_type`), or known test org when such keys are expected.
exclude dns servers from this rule as this is expected behavior. endpoints usually query local dns servers defined in their dhcp scopes, but this may be overridden if a user configures their endpoint to use a remote dns server. this is uncommon in managed enterprise networks because it could break intranet name resolution when split horizon dns is utilized. some consumer vpn services and browser plug-ins may send dns traffic to remote internet destinations. in that case, such devices or networks can be excluded from this rule when this is expected behavior.
expected red team assessments or penetration tests may utilize bloodhound tools to evaluate the security posture of azure or microsoft 365 environments. if this is expected behavior, consider adjusting the rule or adding exceptions for specific ip addresses, registered applications, jwt tokens, prts or user principal names (upns).
expected red team assessments or penetration tests may utilize teamfiltration to evaluate the security posture of azure or microsoft 365 environments. if this is expected behavior, consider adjusting the rule or adding exceptions for specific ip addresses, registered applications, jwt tokens, prts or user
exporting snapshots may be done by a system or network administrator. verify whether the user identity, user agent, and/or hostname should be making changes in your environment. snapshot exports from unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
external account ids or broken automation may trigger this rule. for accessdenied (http 403 forbidden), s3 doesn't charge the bucket owner when the request is initiated outside of the bucket owner's individual aws account or the bucket owner's aws organization.
false positives are expected to be very rare due to the specific nature of this rule. legitimate application deployments typically do not involve multipart form uploads to .action endpoints followed immediately by jsp file creation in webapps directories. however, custom deployment scripts or automated testing tools that simulate file uploads could potentially trigger this alert. review the source ip, user agent, uploaded file content, timing, and deployment schedules to validate if the activity is authorized. standard package manager operations are already excluded from detection.
false positives can occur because the rules may be mapped to a few mitre att&ck tactics. use the attached timeline to determine which detections were triggered on the host.
false positives may occur when users are using a vpn or when users are traveling to different locations\"
false-positives (fp) can appear if another remote terminal service is being used to connect to it's listener but typically ssh is used in these scenarios.
false-positives (fp) can appear if the pid file is legitimate and holding a process id as intended. to differentiate, if the pid file is an executable or larger than 10 bytes, it should be ruled suspicious.
false-positives (fp) should be at a minimum with this detection as pid files are meant to hold process ids, not inherently be executables that spawn processes.
field mapping differences between auditd versions can occasionally mis-populate effective versus real user ids; validate raw audit fields when triaging unexpected hits.
files generated during installation will generate a lot of noise, so the rule should only be enabled after the fact.
finance or platform teams delete outdated spend limits when consolidating billing policies or replacing them with new limits. confirm the actor, nearby create or update events, and an approved change before escalating.
firewall changes are part of some network troubleshooting and product installs. confirm the change was temporary and that `--enabled true` and a drop default action were restored.
firewall policy deletions may be done by a system or network administrator. verify whether the username, hostname, and/or resource name should be making changes in your environment. firewall policy deletions by unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
firewall rules may be created by system administrators. verify that the firewall configuration change was expected. exceptions can be added to this rule to filter expected behavior.
firewall rules may be deleted by system administrators. verify that the firewall configuration change was expected. exceptions can be added to this rule to filter expected behavior.
firewall rules may be modified by system administrators. verify that the firewall configuration change was expected. exceptions can be added to this rule to filter expected behavior.
first-time bedrock onboarding by a developer using long-term iam user credentials. verify the requesting identity is a known engineer, the use case description is legitimate, and the model invocation follows expected application behavior. consider migrating bedrock workloads to iam roles to eliminate this pattern.
first-time or infrequent access to legacy services, cross-platform integrations, and inter-domain trust activity may legitimately establish a new requester-to-service relationship using rc4 encryption.
first-time use of a legitimate first-party or sanctioned client by the user (newly installed app, first sign-in to a workload, fresh powershell module install). validate by `azure.aadgraphactivitylogs.properties.app_id` and the user's history.
for additional tuning, severity exceptions for google_workspace.alert.metadata.severity can be added.
foundry masks the last octet of caller_ip_address, so unrelated users behind the same network prefix are counted together.
ftp servers should be excluded from this rule as this is expected behavior. some business workflows may use ftp for data exchange. these workflows often have expected characteristics such as users, sources, and destinations. ftp activity involving an unusual source or destination may be more suspicious. ftp activity involving a production server that has no known associated ftp workflow or business requirement is often suspicious.
full network packet capture may be done by a system or network administrator. verify whether the user identity, user agent, and/or hostname should be making changes in your environment. full network packet capture from unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
geo-ip and asn enrichment updates can occasionally shift how a stable egress is labeled, creating a one-time \"new\" tuple.
getsessiontoken is widely used by legitimate automation, cli users, and administrative scripts to acquire temporary credentials. frequent, authorized usage is expected in most environments, especially where iam users authenticate with mfa or use short-lived tokens. review iam and ci/cd users, sdks, and service accounts that regularly perform this action and document them in an allowlist. suppress or tune accordingly to reduce noise.
github actions self-hosted runners running on non-microsoft/amazon/google infrastructure will appear as suspicious. add the asn of your self-hosted runner infrastructure to the is_cicd_infra allowlist.
gitleaks is a legitimate open-source tool used by security professionals and developers to search for sensitive information, such as passwords, api keys, and other secrets, within code repositories. it is commonly employed during security assessments and code reviews to identify potential vulnerabilities.
gitops and platform controllers (cert-manager, gatekeeper, kyverno, service mesh) legitimately manage webhooks. validate change tickets and controller identities before tuning.
gitops controllers and cluster scanners can still match if not covered by built-in exclusions; baseline approved service accounts after review.
gitops or platform controllers that sync sensitive roles and immediately reconcile daemonsets, deployments, or cronjobs can match. baseline approved automation after confirming the role content is intentional.
gitops, backup, and platform operators may span these resource types during sync. exclude validated service accounts or raise the cardinality threshold after baselining.
gitops, namespace onboarding, and workload deployment commonly create rolebindings for service accounts. default bootstrap bindings from `system:apiserver` and gke node bootstrap from `gcp:kube-bootstrap` are excluded.
global administrator additions may be done by a system or network administrator. verify whether the username, hostname, and/or resource name should be making changes in your environment. global administrator additions from unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
global employees on vpns, split dns or proxy paths that change as labels, regional carrier rebrands, or mobile hotspots can produce a small non-cloud as share on the same iam user as hyperscaler- or saas-classified traffic. corporate travel, emergency break-glass from a home isp, and multi-region runners may also widen as diversity without malice. tune thresholds, add account or principal allowlists, or narrow the sensitive-action list after baseline review.
globally distributed applications or ci runners that call bedrock with one shared iam user or role. prefer per-region identities, or raise the country threshold for these principals.
google workspace admin role assignments may be modified by system administrators. verify that the configuration change was expected. exceptions can be added to this rule to filter expected behavior.
google workspace admin roles may be deleted by system administrators. verify that the configuration change was expected. exceptions can be added to this rule to filter expected behavior.
google workspace admin roles may be modified by system administrators. verify that the configuration change was expected. exceptions can be added to this rule to filter expected behavior.
google workspace administrators may change which organizational unit a user belongs to as a result of internal role adjustments.
google workspace administrators may renew a suspended user account if the user is expected to continue employment at the organization after temporary leave. suspended user accounts are typically used by administrators to remove access to the user while actions is taken to transfer important documents and roles to other users, prior to deleting the user account and removing the license.
google's risk engine occasionally flags legitimate sign-ins as suspicious when the user is on a new device, on a vpn egress that geo-resolves to a different region, or after extended time away. validate by checking the user's recent sign-in history and confirming with the user.
guardduty member relationships may be modified during legitimate organizational changes such as account migrations, security architecture restructuring, or delegated administrator transitions. verify whether the user identity and timing align with approved change management processes. if this is expected administrative activity, it can be exempted from the rule.
guest user invitations may be sent out by a system or network administrator. verify whether the username, hostname, and/or resource name should be making changes in your environment. guest user invitations from unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
helm operations managed through arc may create release secrets (prefixed with sh.helm.release.v1). these are normal arc lifecycle operations.
help desk teams issuing taps for locked-out users or new employee onboarding workflows. automated identity lifecycle systems that provision taps during device enrollment.
highly distributed environments (e.g., globally deployed automation or edge nodes) may cause a single iam user to appear from multiple ips. review the geolocation, network context, and user agent patterns to rule out benign use. this rule automatically excludes console login sessions, reducing false positives from legitimate console-based access across vpn or network changes.
highly unusual for legitimate workflows to embed or reference full administrator access in getfederationtoken session policies; if found, it is often legacy or misconfigured tooling. confirm with the owning team and replace with least-privilege session policies. tune only after documented approval.
host windows firewall planned system administration changes.
hr or finance personnel legitimately searching for employee or financial records.
hr, legal, finance, or ir users who legitimately search gmail for attachments, payroll, or contract terms via chatgpt.
hr, legal, finance, or vendor-management workflows that legitimately search drive for payroll, nda, or contract terms across several queries. validate the query values and business context before escalating.
http traffic on a non standard port. verify that the destination ip address is not related to a domain controller.
hybrid activation is a legitimate operation when onboarding on-premises or non-ec2 hosts as managed nodes for the first time, and re-registration after an agent reinstall. de-registration (\"-register -clear\") does not match this rule. add exceptions for known provisioning automation or onboarding hosts if this fires in expected environments.
iac pipelines setting event selectors during trail creation always set includemanagementevents to true — the rule will not fire on those calls. the remaining fp vector is an administrator intentionally restricting a trail to data-events-only for cost reasons. validate the caller, change management ticket, and confirm this is not a multi-region or organization-wide trail where the coverage impact would be severe.
iam users may occasionally share ec2 snapshots with another aws account belonging to the same organization. if known behavior is causing false positives, it can be exempted from the rule.
identity and platform teams and infrastructure-as-code pipelines occasionally manage group inline policies as part of normal access governance. verify the principal in `aws.cloudtrail.user_identity.arn`, the targeted group, and the policy document against approved change records. known administration roles and deployment automation can be excluded after validation.
identity and platform teams or infrastructure-as-code may delete or replace the account password policy during governance changes. verify the principal in `aws.cloudtrail.user_identity.arn` against approved change records, and confirm whether a replacement policy was applied shortly after. known administration roles and automation can be excluded after validation.
identity governance and provisioning tools that assign directory roles on behalf of administrators. review the initiating application and exclude it by application id after review.
identity provider directory sync and scim provisioning can deactivate or delete sso connections during idp migrations, directory attribute changes, or connector maintenance. if `anthropic.audit.actor.type` is `scim_directory_sync_actor`, correlate with workos or okta change windows before escalating.
idp or sso cutover testing against a pilot account can generate a short burst of failed attempts for one email during maintenance windows.
if a credential-shaped string is present alongside other encoded content, the credential pattern suppresses this alert. the higher-severity credential rule fires instead and the investigation guide for that rule covers triage of any co-occurring obfuscated content.
if cloud app security identifies, for example, a high rate of file uploads or file deletion activities it may represent an adverse encryption process.
if the behavior of creating okta api tokens is expected, consider adding exceptions to this rule to filter false positives.
if the behavior of deactivating mfa for okta user accounts is expected, consider adding exceptions to this rule to filter false positives.
if the behavior of deactivating okta policies is expected, consider adding exceptions to this rule to filter false positives.
if the behavior of revoking okta api tokens is expected, consider adding exceptions to this rule to filter false positives.
if the domains listed in this rule are used as part of an authorized workflow, this rule will be triggered by those events. validate that this is expected activity and tune the rule to fit your environment variables.
if you have front-facing proxies that provide authentication and tls, this rule would need to be tuned to eliminate the source ip address of your reverse-proxy.
in-cluster automation may produce the same pattern: validate `esql.user_name_values`, workload ownership, and whether `source.ip` / `source.as.organization.name` match expected egress before tuning or allowlisting.
in-cluster controllers, operators, and ci jobs may legitimately reconcile rbac manifests. baseline known automation service accounts before tuning.
in-cluster operators, csi drivers, gitops agents, and some platform controllers legitimately list or get secrets in namespaces they manage; exclude known service accounts, namespaces, or user agents after baselining.
incident responders, support engineers, or community managers who run many slack search refinements in a short window. validate the query values and business context before escalating.
infrastructure teams may legitimately delete multiple snapshots during planned maintenance, storage optimization, or cleanup of expired backup data according to retention policies. verify that the deletion activity was expected and follows organizational change management processes. consider exceptions for approved maintenance windows or automation service principals managing backup retention.
infrastructure teams may legitimately delete multiple storage accounts during planned decommissioning, resource cleanup, or large-scale infrastructure optimization. verify that the deletion activity was expected and follows organizational change management processes. consider exceptions for approved maintenance windows or automation service principals.
infrastructure-as-code deployments that recreate rai policies on every release. add exceptions for the service principals that run these pipelines.
infrastructure-as-code pipelines and deployment scripts that read keys to configure applications. prefer managed identities, or add exceptions for the service principals that run these pipelines.
infrastructure-as-code pipelines that manage project iam bindings. add exceptions for the service accounts that run these pipelines.
infrastructure-as-code tooling (e.g. terraform), ci/cd pipelines, and platform automation routinely grant serviceaccountuser or serviceaccounttokencreator when wiring up workloads, deployments, or impersonation chains. identify the expected automation principals and target service accounts and add exceptions for them.
infrastructure-as-code, ci/cd, and iam administrators routinely publish new policy versions or roll back defaults. validate the policy arn, change tickets, and whether the policy document broadens permissions. exclude automation roles or pipelines after review.
infrastructure-as-code, ci/cd, and platform automation (for example crossplane, terraform, arm/bicep, aks control plane) commonly delete resource groups during environment teardown. the first occurrence per principal will alert; baseline expected service principals and exclude them if the activity is authorized.
infrastructure-as-code, configuration management, and patching automation may create or update managed run commands. the first occurrence per principal will alert; baseline expected service principals, managed identities, and admin users and exclude them if the activity is verified as authorized.
infrastructure-as-code, configuration management, and patching automation routinely create, update, and delete vm extensions. the first time a given extension resource name is operated on from a new source as number will alert. baseline expected management networks (corporate egress, ci/cd runners, third-party automation saas) and exclude their as numbers if the activity is verified as authorized. read operations are typically not emitted to the azure activity log; the rule predominantly fires on write and delete.
initial sso configuration issues or first-time federation setup errors for legitimate users may trigger this detection. temporary federation service outages affecting multiple users simultaneously.
install or update of a legitimate printing driver. verify the printer driver file metadata such as manufacturer and signature information.
installing a documented ci, chat, or ticketing integration that uses github webhooks. confirm the payload url and subscribed events with the repository owners.
intentionally public containers (static websites, public datasets) generate anonymous getblob and listblobs. baseline those storage accounts and exclude `azure.resource.id` after review.
internal account restructuring, mergers and acquisitions, or legitimate ownership transfers between business units may involve transferring dns domains to other aws accounts. confirm the transfer is approved and documented in change management processes before taking action. transfers performed by unfamiliar identities, originating from atypical locations, or outside expected maintenance windows should be investigated.
internal automation built with generic libraries can resemble suspicious user agents; baseline known jobs and tune by service account, namespace, or stable source ip allowlists.
internal hosts that legitimately send mail to external mail transfer agents listening on tcp port 26 may cause false positives. mail servers or applications with known external smtp relays can be excluded by source or destination ip address as this is expected behavior.
internet-wide scanners will produce first-seen anonymous access on newly created or newly logged accounts. confirm whether the account is meant to be public.
inventory jobs, configuration management, and security scanners that are not in the exclusion list may read `userdata` across a large fleet. confirm the principal arn, source ip, asn, and user agent against approved automation before treating the activity as malicious.
iot (internet of things) devices and networks may use telnet and can be excluded if desired. some business work-flows may use telnet for administration of older devices. these often have a predictable behavior. telnet activity involving an unusual source or destination may be more suspicious. telnet activity involving a production server that has no known associated telnet work-flow or business requirement is often suspicious.
iot development, device testing, telemetry agents, installers, and administrative scripts can legitimately run from temporary or hidden paths and connect to aws iot core. confirm the executable, parent process, source asset role, and complete aws iot endpoint before creating an exception. scope exceptions to an approved executable and endpoint pair rather than excluding aws iot or a writable directory globally.
irc activity may be normal behavior for developers and engineers but is unusual for non-engineering end users. irc activity involving an unusual source or destination may be more suspicious. irc activity involving a production server is often suspicious. because these ports are in the ephemeral range, this rule may false under certain conditions, such as when a nat-ed web server replies to a client which has used a port in the range by coincidence. in this case, these servers can be excluded. some legacy applications may use these ports, but this is very uncommon and usually only appears in local traffic using private ips, which does not match this rule's conditions.
it administrators and hiring workflows routinely invite new members during onboarding, contractor access, or staffing changes. verify the invited email, role, and that a hiring or access request exists when policy requires one.
it administrators legitimately promote users to account-owner during staffing changes.
it administrators promote users to organization admin during onboarding, staffing changes, or incident response. verify that the target user should hold org admin privileges, and that a change request exists when policy requires one.
it administrators searching for configuration or infrastructure documentation.
it administrators using pnp powershell for site management, migration, or backup operations.
it and hiring workflows routinely invite new members during onboarding.
it and identity teams verify or add corporate domains during tenant onboarding, mergers, or dns migrations. confirm the domain and actor against change management records.
it or devops using azcopy for authorized migrations on a host that has not used it in the history window.
it or managed service providers may distribute rmm binaries through public hosting or shared download links. confirm the package, host, operator, timing, and enrollment destination against a change record or support ticket.
it's recommended that you rotate your access keys periodically to help keep your storage account secure. normal key rotation can be exempted from the rule. an abnormal time frame and/or a key rotation from unfamiliar users, hosts, or locations should be investigated.
it's strongly recommended that the root user is not used for everyday tasks, including the administrative ones. verify whether the ip address, location, and/or hostname should be logging in as root in your environment. unfamiliar root logins should be investigated immediately. if known behavior is causing false positives, it can be exempted from the rule.
jwts used as legitimate authentication tokens passed to the model for parsing, validation, or debugging. inspect the prompt context to confirm whether the token was intentionally shared for a benign purpose.
key vault modifications may be done by a system or network administrator. verify whether the username, hostname, and/or resource name should be making changes in your environment. key vault modifications from unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
lambda function owners or deployment pipelines may legitimately add or update layers as part of normal development and maintenance workflows. confirm that the layer addition aligns with approved changes, expected ci/cd behavior, or routine dependency updates. known automation roles or build systems can be excluded if they consistently perform authorized modifications.
lambda functions are routinely deleted during application decommissioning, environment teardown, and infrastructure-as-code apply/destroy cycles. verify whether the principal in `aws.cloudtrail.user_identity.arn` and the deleted function are expected for the workload, and whether the change aligns with an approved maintenance or deployment window. known deployment roles and automation can be excluded after validation.
large enterprises with many users experiencing simultaneous password issues during credential rotation events.
legacy federation broker applications that call getfederationtoken and immediately redirect users to a console session from the same host may trigger this rule. validate the source ip against known application server infrastructure and confirm the federation architecture is documented.
legacy internal applications, industrial control systems, or embedded devices may still require deprecated tls versions or weak ciphers. exclude known legacy destination ips or subnets after validation.
legacy tooling may still be using aad graph. validate and add exceptions on the calling app id after review.
legal teams searching for contract or privileged documents.
legit application crash with rare werfault commandline value
legitimate account decommissioning or cost-reduction exercises may disable security hub in unused regions. validate with the responsible team via change management records before escalating. disabling in the primary account region or the security hub delegated administrator account is always high-risk.
legitimate acme certificate renewal agents (cert-manager, certbot, caddy) use acme-tls/1 during tls-alpn-01 challenges. a single incomplete challenge due to a network timeout can occur normally, but five or more incomplete sessions from the same source within the detection window is abnormal even for misconfigured acme clients. tls decode_error or illegal_parameter alerts can also be produced by buggy tls clients or misconfigured load balancers. suppress by adding known acme client source ips or acme ca validation ip ranges to an exception list.
legitimate administrative activity
legitimate administrative activity related to shadow copies.
legitimate administrative or security assessment activities may use these user-agents, especially in environments where teamfiltration is employed for authorized audits. if this is expected behavior, consider adjusting the rule or adding exceptions for specific user-agents or ip addresses.
legitimate administrative tasks using ssm to run system utilities may trigger this rule. review the command context, user identity, and timing to determine if the activity is authorized.
legitimate administrators and automation may deploy custom script, run command, dsc, or monitoring extensions during provisioning, patching, or guest configuration. baseline expected principals, vms, and extension types before tuning exclusions.
legitimate administrators may add lifecycle expiration configurations to reduce storage costs or enforce retention policies. confirm whether this change aligns with an approved data management policy or infrastructure-as-code workflow. known lifecycle automation processes (e.g., cost-management tools, data-lifecycle governance jobs) can be safely excluded from alerting once verified.
legitimate administrators or automation tools may access ssm inventory apis for asset management or compliance purposes. verify whether the user identity should be using these apis. if known behavior is causing false positives, add exceptions.
legitimate af_alg usage from unprivileged users is uncommon, but some kernel crypto tests, ipsec helpers, disk encryption tooling, hsm integrations, or approved security research systems may exercise this interface. verify the process, user, and host role before adding an exception.
legitimate allowlisting of noisy accounts
legitimate automation or administrators may change user data and restart instances during maintenance, image baking, or configuration fixes. review the caller identity, change tickets, and whether `user_agent.original` and `source.ip` match known tooling and networks (the rule groups on both together with `user.name`).
legitimate automation scripts using powershell to interact with sharepoint or onedrive for business purposes.
legitimate automation that deploys configuration via azure run command and launches powershell with unrestricted policy and numbered script files (for example `script1.ps1`) may match. baseline known deployment pipelines, vm names, and principal ids before tuning.
legitimate automation, sdks, or custom applications that obtain tokens through the microsoft authentication broker against graph, azure ad, or device registration service may use non-browser user agents. baseline approved service principals, managed identities, and developer tooling before tuning exclusions for known automation patterns.
legitimate backup, compliance scanners, or admin scripts that enumerate paths under /home or /var/run/secrets may match. tune by parent process, image, or automation identity.
legitimate broker sign-ins to first-party microsoft resources that use alternate well-known ids, regional variants, or new microsoft services not yet in the exclusion list may match. third-party applications that integrate with mab for delegated authentication can also appear. baseline `resource_id` and `resource_display_name` for your environment and add exclusions for approved resources.
legitimate causes such as system maintenance, server shutdowns, or temporary network outages may trigger this alert.
legitimate changes to eks logging configuration during cluster provisioning, troubleshooting, or cost optimization may match. validate the caller identity and change records, and baseline expected automation roles.
legitimate changes to lambda functions can trigger this signal. ensure that the changes are authorized and align with your organization's policies.
legitimate changes to share an s3 bucket with an external account may be identified as false positives.
legitimate ci/cd automation that commits and pushes changes (e.g., auto-formatting, changelog updates, version bumps, dependabot auto-merge) will trigger this alert on first use in a repository. review the repository's workflow configurations to determine if bot pushes are expected.
legitimate ci/cd automation that requires workflow file modifications may trigger this alert if not properly configured with the necessary permissions. review the workflow configuration and ensure the github_token or pat has the required 'workflows' permission if the modification is intentional.
legitimate ci/cd pipelines, infrastructure tooling, or configuration management systems may retrieve secret files from s3 as part of their normal operation. validate the calling identity, user agent, and source ip against known automation accounts and expected access patterns.
legitimate cloud platform operations — enabling security hub, guardduty, or other aws services at the organization level — require registering a delegated administrator. validate the called service and target account against your organization's approved delegated admin configuration and a corresponding change management record.
legitimate configuration management, extension deployment, or automation that uses azure run command with the same powershell or shell script paths may match. baseline approved vm names, script naming, and deployment windows before tuning.
legitimate data migration or backup operations using azcopy with sas tokens may trigger this rule.
legitimate decommissioning of an aws account, regional consolidation, or removal of an unused detective deployment may trigger this rule. validate the caller identity and confirm a corresponding change management ticket exists before closing.
legitimate device onboarding (for example a user enrolling a new corporate device through azure ad join) can produce a broker authentication to the device registration service followed by prt issuance. validate that the device, source ip/asn, and user agent are expected, and that the device is managed/compliant.
legitimate device registrations may coincidentally use the `10.0.19045.2006` build (windows 10 22h2) with a default `desktop-` hostname, particularly on imaged or unmanaged windows hosts that have not been updated. validate against your device inventory, expected provisioning workflows, and the registering user before escalating.
legitimate device registrations using microsoft authentication broker may occur during corporate enrollment scenarios or bulk provisioning, but it is uncommon for multiple source ips to register the same identity across microsoft graph, device registration service (drs), and azure active directory (aad) in a short time span.
legitimate email service automation may attach amazonsesfullaccess to a service account. validate the target iam entity against known email automation roles and ci/cd pipeline identities. because this is a new terms rule keyed on the calling identity, recurring attachments by the same automation will not re-alert within the 7-day history window; first-time attachments by administrators performing legitimate setup may still trigger and should be validated against change management records.
legitimate exchange system administration activity.
legitimate external partners or managed service providers with help desk-style display names may trigger this rule. validate the sender tenant, domain, and business relationship before closing as benign.
legitimate federation workflows, admin portals, sso helpers, ci/cd jobs, or internal scripts that create one-click console links, commonly invoke getsignintoken and may generate frequent benign events.
legitimate files reported by the users
legitimate first-party clients occasionally hit 4xx responses as part of conditional access flows, transient permission changes, or stale token retries. tune the threshold for your tenant baseline.
legitimate first-party microsoft components (for example the azure graph client library used by portal or office experiences) occasionally call aad graph with the internal api version, but at single-digit to low-double-digit volume; the burst thresholds exclude them. validate the calling `azure.aadgraphactivitylogs.properties.app_id` and user if a low-volume match appears.
legitimate first-party or line-of-business applications that use delegated permissions and enumerate several graph resources during onboarding or sync may match. baseline known app ids and tune thresholds or path lists for your tenant.
legitimate first-time use of a new network: isp change, new vpn provider, travel to a region using a different mobile carrier, new home office.
legitimate gke automation does not request certificates for system:masters, system:kube-controller-manager, or system:admin as the csr subject. node bootstrap and kubelet rotation use system:node:* identities instead. alerts should be rare; tune exclusions only for documented custom pki workflows that intentionally mint these identities.
legitimate group deletion during decommissioning of projects, clean-up of service accounts, or identity lifecycle changes may trigger this alert. verify whether the user identity, user agent, and/or hostname should be making changes in your environment. resource group deletions by unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
legitimate high volume data exchanges during scheduled updates
legitimate high-throughput applications, batch jobs, load tests, and automation can invoke functions at high volume and will exceed any fixed threshold. validate the principal in `aws.cloudtrail.user_identity.arn` and the workload context, and tune the threshold to the environment.
legitimate iam administrators may attach customer-managed policies to roles for various reasons, such as granting temporary permissions or updating existing policies. ensure that the user attaching the policy is authorized to do so and that the action is expected.
legitimate it administrators adding site admins as part of routine sharepoint site management.
legitimate knowledge base maintenance, content onboarding, and scheduled re-ingestion performed by data engineering teams, mlops automation, or infrastructure-as-code pipelines will generate these events. validate the calling identity, user agent, and source ip against known automation and approved operators. if a known maintenance workflow is causing noise, it can be exempted from this rule.
legitimate kubelet debugging, node troubleshooting, or security tooling that uses the node proxy outside the excluded metrics prefix may match. baseline approved operators and automation identities.
legitimate large or encoded powershell scripts (automation frameworks, installers, or admin tooling) can exhibit high entropy or uneven character distributions.
legitimate manual or automated snapshots created for backups can trigger this rule. ensure that the snapshots are authorized and align with your organization's policies.
legitimate misunderstanding by users on accessing the bedrock models.
legitimate misunderstanding by users or overly strict policies
legitimate nfs root squashing misconfiguration, administrative automation, or backup appliances may present uid 0 from known infrastructure. confirm the source ip against approved nfs client inventories before closing.
legitimate node group lifecycle, cluster upgrades, or infrastructure-as-code (terraform, cloudformation, eksctl) may update aws-auth during expected change windows. baseline automation identities and expand exclusions beyond eks:kms-storage-migrator if your environment uses additional known controllers.
legitimate node health checks, diagnostics, or in-cluster agents may access the kubelet api on port 10250. validate the calling process, command line, and whether the destination is the local node or another node.
legitimate node.js or undici-based automation, health checks, or internal services that use the microsoft authentication broker or the same first-party application ids against graph or exchange may match. developers using axios or undici with delegated flows can also resemble this pattern.
legitimate operations such as new user onboarding, role changes, or service account updates may trigger this event. verify whether the user identity, user agent, and/or hostname should be making changes in your environment. user additions from unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
legitimate operators using aws systems manager session manager to administer instances will spawn child processes under the session worker. tune with host, user, or command-line exclusions for known automation and break-glass workflows.
legitimate platform, ml, or application teams may associate or update knowledge bases on bedrock agents as part of normal development, onboarding, or rag pipeline changes. verify that the actor identity, user agent, and source ip correspond to expected automation or authorized engineers, and that the associated knowledge base is an approved, organization-owned resource. if known behavior is causing false positives, it can be exempted from the rule.
legitimate postgresql recovery operations performed by splunk administrators through the backup and restore api. these should be rare and originate from known management networks. if such operations occur in your environment, scope exceptions by source ip or approved management network rather than suppressing the rule entirely.
legitimate powershell scripts that make use of these functions.
legitimate powershell scripts that reconstruct to a confirmed benign installer, updater, or administrative workflow for the same user and host scope.
legitimate powershell scripts which makes use of encryption.
legitimate processes may be spawned from the microsoft exchange server unified messaging (um) service. if known processes are causing false positives, they can be exempted from the rule.
legitimate project collaboration routinely adds owners and editors when teams spin up or staff claude projects. verify the project (`anthropic.audit.resource_id`), role, and available actor fields against expected membership changes.
legitimate provisioning of bedrock agentcore resources by ci/cd pipelines or platform engineers. validate the caller identity against expected provisioning principals and verify the attached role is commensurate with the workload's documented requirements.
legitimate provisioning, patching, and configuration-management automation may deploy an extension to a host for the first time. the first occurrence per host will alert. baseline expected automation principals and hosts and exclude verified-benign ones.
legitimate psreflect use when reconstructed content, imported api set, script origin, launcher, user/host scope, and same-host effects align with an approved workflow
legitimate publicly shared files from google drive.
legitimate remote account administration.
legitimate sandboxing, container tooling, or maintenance scripts may use unshare and spawn privileged helpers under controlled workflows. baseline approved tools and tune by host role, parent process, or user accounts.
legitimate scheduled jobs may be created during installation of new software.
legitimate scheduled tasks may be created during installation of new software.
legitimate scheduled tasks running third party software.
legitimate security scanners, cspm products, compliance jobs, and inventory automation may call the same read-only bucket apis across many buckets quickly. verify the principal arn, source ip, user agent, and schedule against known approved tooling before treating the activity as malicious.
legitimate setup scripts may reference metadata endpoints or download tooling. review the decoded script in \"esql_priv.aws_cloudtrail_lifecycle_script\", verify the principal in \"aws.cloudtrail.user_identity.arn\", and confirm the activity is approved. note this rule only matches unobfuscated patterns; a clean result does not guarantee a benign script.
legitimate software or scripts using cron jobs for recurring tasks.
legitimate spikes in usage due to business processes
legitimate support, diagnostic, accessibility, update, or enterprise management workflows may cause zoom to launch command-line utilities. verify the executable path, command line, code signature, and surrounding user activity before adding exceptions.
legitimate teardown or environment decommissioning processes may delete efs file systems. verify whether the calling user, role, automation system, or ci/cd workflow is expected to perform destructive actions in the affected account. file system deletions by unfamiliar identities, from unusual ip addresses, or occurring outside approved change windows should be carefully reviewed. if known automation routinely deletes ephemeral test file systems, consider adding scoped exceptions.
legitimate use of aws session manager to establish a session to an ec2 instance.
legitimate use of cloudshell by administrators for routine aws management tasks. verify whether the user has a legitimate need for cloudshell access and correlate with recent console login activity. environment creation also occurs when users access cloudshell in a new aws region.
legitimate use of deprecated amis for testing or development purposes.
legitimate use of device code flow where a user authenticates via browser for a cli tool or headless application. common legitimate scenarios include azure cli, azure powershell, or vs code remote development. review the user agent combinations - browser + known cli tool from the same user may be expected behavior.
legitimate use of server-side encryption with customer-provided keys (sse-c) to encrypt objects in an s3 bucket.
legitimate use of the `describeinstances` api call by an aws resource that requires information about instances in multiple regions.
legitimate use of the `sendcommand` api call to execute commands on ec2 instances using the ssm service may be done by system administrators or devops engineers for legitimate purposes.
legitimate use of the kubelet run/exec/attach/portforward endpoints via nodes/proxy is rare. administrative debugging tools that proxy exec through the api server may match; baseline and exclude verified operators.
legitimate user shell modification activity.
legitimate users and processes, such as system administration tools, may utilize shell utilities inside a container resulting in false positives.
legitimate users may access a large number of mailbox items in a short period, especially in environments with high email volume or during data migrations. if this is expected behavior, consider adjusting the rule or adding exceptions for specific users or groups.
legitimate users may appear in multiple countries within the window when using vpns or proxies with exit nodes in different countries, when traveling near borders, or when mobile networks geolocate to different countries. verify the source ips and asns in \"esql.source_ip_values\", confirm whether the locations are consistent with the user's expected activity, and exclude known vpn egress patterns after validation. shared iam users (an anti-pattern) used by multiple people will also match.
legitimate users may create sns topics for legitimate purposes. ensure that the creation is authorized before taking action.
legitimate users may create ssm command documents for legitimate purposes. ensure that the document is authorized and the user is known before taking action.
legitimate users may download files from onedrive using oauth authentication. ensure that the downloads are authorized and the user is known before taking action.
legitimate users may export dynamodb tables for various reasons, such as data analysis or backup purposes. ensure that the user has the necessary permissions and that the exporttabletopointintime operation is authorized before taking action.
legitimate users may scan dynamodb tables for various reasons, such as data analysis or application functionality. ensure that the user has the necessary permissions and that the scan operation is authorized before taking action.
legitimate users may subscribe to sns topics for legitimate purposes. ensure that the subscription is authorized before taking action.
legitimate users may travel, rotate through vpn egress ips, or run automation from new build hosts, producing a first-seen ip for an existing access key. baseline the principal, confirm with the key owner, and extend the history window or add exceptions for known automation networks if needed.
legitimate users who routinely use vpn or proxy services for privacy may trigger this if they also trigger unrelated security alerts.
legitimate webproxy settings modification
legitimate whfb and passwordless onboarding commonly generate this event, especially for new users or users enrolling from a new network asn. this rule fires only on first-seen combinations of tenant, user, and source asn over 14 days. investigate unexpected asns, users outside the enrollment population, or enrollments preceded by anomalous sign-ins.
legitimate windows defender configuration changes
local automation or provisioning applications that are designed to assign roles to themselves. review the owner and purpose, then exclude by application id.
logging bucket deletions may be done by a system or network administrator. verify whether the user email, resource name, and/or hostname should be making changes in your environment. logging bucket deletions by unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
logging sink deletions may be done by a system or network administrator. verify whether the user email, resource name, and/or hostname should be making changes in your environment. logging sink deletions by unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
logging sink modifications may be done by a system or network administrator. verify whether the user email, resource name, and/or hostname should be making changes in your environment. sink modifications from unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
long documents such as design docs or detection specs that describe several jailbreak techniques together. review `esql.message_length` and the message context before escalating.
long helpful answers that incidentally include phrases such as \"i can't help with x, but i can help with y.\" read the sampled messages before treating the alert as a hard refusal campaign.
machine learning engineers, mlops automation, or platform teams may legitimately import custom models or stand up marketplace model endpoints as part of normal model lifecycle operations. verify whether the user identity, user agent, source ip, and model artifact source (s3 location) are expected for your environment. imports performed by approved ci/cd or iac pipelines can be exempted from this rule. activity from unfamiliar identities or untrusted artifact sources should be investigated.
major os upgrades or workspace client refreshes that re-attest several apps concurrently may also produce a burst. cross-reference against the user's known device os transitions.
managed service provider, helpdesk, migration, software inventory, and lab systems may legitimately contact multiple rmm vendors. recursive resolvers can aggregate queries from many endpoints and must be identified before treating the client ip as one asset.
master password modification may occur during legitimate administrative recovery (e.g., a lost password, rotation event, or secrets manager reassociation). validate whether the change was expected, approved, and performed by authorized personnel. if known workflows routinely perform this action, consider adding targeted exceptions.
mfa device deactivation may occur legitimately during device rotation, user offboarding, or troubleshooting. for example, aws requires deactivation of an existing mfa device before adding a replacement. these actions are often performed by administrators following approved change-control processes. to reduce false positives, validate whether the deactivation aligns with a documented workflow, known device replacement, or expected maintenance window. if performed outside of expected operational hours, by an unexpected user, or from an unfamiliar source ip, this event should be investigated for potential credential compromise or unauthorized tampering.
mfa policies may be modified by system administrators. verify that the configuration change was expected. exceptions can be added to this rule to filter expected behavior.
mfa settings may be modified by system administrators. verify that the configuration change was expected. exceptions can be added to this rule to filter expected behavior.
microsoft antimalware service executable installed on non default installation path.
microsoft teams, microsoft office, onedrive syncengine, microsoft authentication broker, outlook mobile, bing, azure portal, adibizaux, and office 365 management are omitted. the rest of the secureworks known-foci-clients.csv family (edge, onedrive, intune company portal, windows search, authenticator, sharepoint, planner, power bi, and similar) is omitted for the same reason: routine workstation or mobile graph whose microsoft 365 egress often differs from the windows sign-in ip without cookie theft. hunt those app_ids separately if harvest is already confirmed.
microsoft teams, office, onedrive syncengine, authentication broker, outlook mobile, bing, azure portal, and office 365 management are omitted because first sight of a mobile or m365 egress ip for those clients is routine.
microsoft windows installers leveraging rundll32 for installation.
microsoft-owned resource providers (for example azure cosmos db networking) may remove diagnostic settings as part of private-endpoint or control-plane lifecycle. confirm the actor, app, and whether the group is non-production before treating the event as malicious.
migration or onboarding projects that temporarily require external sharing to be enabled.
misconfiguration, system reboot, network issues or expected uninstall of the elastic defend agent.
misconfigured applications or services that rely on deprecated amis for compatibility reasons.
misconfigured phones, expired credentials, or provisioning errors can generate repeated register failures from a single device. validate the client, affected extensions, and registration state before escalating.
misconfigured workloads can generate repeated denied secret gets during startup; confirm rbac intent before treating as compromise.
mknod is a linux system program. some normal use of this program, at varying levels of frequency, may originate from scripts, automation tools, and frameworks. usage by web servers is more likely to be suspicious.
mlops pipelines and data science teams routinely create sagemaker resources with execution roles, and new pipelines or team members appear as new principals on first use. verify the principal in `aws.cloudtrail.user_identity.arn`, the passed rolearn in `aws.cloudtrail.request_parameters`, and whether the role's privileges and the activity are approved. known automation roles can be excluded after validation.
mobile access may also result in false positives, as users may log in from various locations while on the go.
mobile clients on cellular networks that peer through regional hubs may geo-resolve differently than the user location.
mobile users switching between wifi and cellular may show ip address changes. correlate with device type and typical user behavior patterns.
monitoring agents and cni components may require hostnetwork. exclude known platform identities after review.
monitoring and log-collection agents that run outside kube-system (for example a metrics agent in its own namespace) proxy to the kubelet on every scrape and will match repeatedly. add targeted exclusions for verified monitoring service accounts and namespaces after review.
multi-account architectures and partner integrations legitimately invoke functions across account boundaries. verify the caller account, the principal in `aws.cloudtrail.user_identity.arn`, and the function against approved cross-account access, and exclude known trusted accounts or identities after validation.
multi-region automation or ci pipelines that share one iam user or role session across distant egress ips. prefer per-region identities, or raise the distance and speed thresholds.
nated servers that process email traffic may false and should be excluded from this rule as this is expected behavior for them. consumer and personal devices may send email traffic to remote internet destinations. in this case, such devices or networks can be excluded from this rule if this is expected behavior.
netcat and openssl are common tools used for establishing network connections and creating encryption keys. while they are popular, capturing the stdout and stderr in a named pipe pointed to a shell is anomalous.
netcat is a dual-use tool that can be used for benign or malicious activity. netcat is included in some linux distributions so its presence is not necessarily suspicious. some normal use of this program, while uncommon, may originate from scripts, automation tools, and frameworks.
network acl's may be created by a network administrator. verify whether the user identity should be making changes in your environment. network acl creations by unfamiliar users should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
network acl's may be deleted by a network administrator. verify whether the user identity, user agent, and/or hostname should be making changes in your environment. network acl deletions by unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
network changes, office ip rotations, or vpn egress updates performed by org owners. confirm the entry value and that enforcement was not enabled unexpectedly.
network monitoring or management products may have a web server component that runs shell commands as part of normal behavior.
network or security teams remove ip restrictions during office moves, vpn migrations, or policy redesigns. validate the actor, and confirm replacement restrictions were applied if the control is still required.
network watcher deletions may be done by a system or network administrator. verify whether the username, hostname, and/or resource name should be making changes in your environment. network watcher deletions by unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
new administrators or vpn users, travel, mobile networks, isp address rotation, managed service providers, and first observations after integration onboarding or retention loss can trigger this rule.
new application servers, autoscaled workloads, cache warmers, deployment jobs, administrative tools, and failover systems may legitimately write to memcached for the first time. validate the client and server roles, affected keys, deployment context, and application behavior before escalating.
new automation, admission webhooks, or platform agents that legitimately call the tokenrequest api under a non-standard user string may require narrow exclusions by user.name or source ip.
new ci/cd pipeline deployments using github actions, azure devops, or kubernetes oidc will trigger this rule when federated authentication is first used. validate the issuer url against approved identity providers.
new deployments, application defects, dependency changes, resource exhaustion, and configuration errors can legitimately produce a first-seen php fatal error.
new deployments, dr sites, ip rotation, or first-time ci/cd expansion can produce a genuinely new (service principal, asn) pair without malicious intent. baseline expected apps and approve new network paths.
new ec2 workloads, nat or egress changes, isp renumbering, or geoip database updates can change `source.as.organization.name` for the same logical path. roles that legitimately call sts from many networks (for example, developer-exported temporary credentials) may also produce alerts. tune using role arn, account, or user agent where appropriate.
new iam administrator roles, recently provisioned automation accounts, or first-time iac deployments may legitimately delete policies for the first time. validate that the identity is an authorized iam management role and that the deleted policy was obsolete or replaced as part of a known change.
new internal tools, sdks, or ci runners introduce novel user agents. baseline expected clients, then exclude stable automation uas after review.
new legitimate applications or integrations recently deployed in the environment may trigger this detection during initial setup or rollout phases.
new model deployments.
new or infrequently used iot devices, telemetry agents, application messaging services, test environments, and broker migrations can create legitimate first-seen relationships. sensor onboarding or retention gaps can also cause existing relationships to appear new.
new or unusual command and user geolocation activity can be due to manual troubleshooting or reconfiguration; changes in cloud automation scripts or workflows; adoption of new services; expansion into new regions; increased adoption of work from home policies; or users who travel frequently.
new or unusual event and user geolocation activity can be due to manual troubleshooting or reconfiguration; changes in cloud automation scripts or workflows; adoption of new services; expansion into new regions; increased adoption of work from home policies; or users who travel frequently.
new or unusual user command activity can be due to manual troubleshooting or reconfiguration; changes in cloud automation scripts or workflows; adoption of new services; or changes in the way services are used.
new or unusual user event activity can be due to manual troubleshooting or reconfiguration; changes in cloud automation scripts or workflows; adoption of new services; or changes in the way services are used.
new users or roles may legitimately publish messages to sns topics for authorized purposes. ensure that the action is authorized before taking action.
new virtualization administrators and service accounts are granted admin during approved account provisioning. confirm the account name against the identity ticket.
new workload identity federation configurations for legitimate automation will trigger on first use.
newly deployed legitimate site-to-site or client vpn gateways, or established gateways that were inactive for more than 5 days, will generate an alert when first observed. where these peers are expected, their external destination ip addresses can be excluded.
newly deployed network devices may legitimately generate other detection alerts during commissioning, testing, vulnerability scanning, or monitoring validation. shared addresses, network address translation, and incomplete asset attribution can also cause unrelated activity to correlate to the exporter ip.
newly deployed operators or workloads that change egress ip will alert once while the history window learns their client fingerprint.
newly deployed routers, switches, firewalls, packet brokers, collector migrations, disaster-recovery activation, exporter address changes, and integration re-onboarding can trigger this rule.
newly deployed workloads with incomplete rolebindings can probe several apis during startup and encounter intermittent denials; exclude known service accounts if documented.
node agents and observability daemonsets commonly mount host paths like /proc or /var/log. controller ownerreferences exclusions reduce noise; add image exceptions if needed.
node bootstrap, cert-manager, and platform controllers legitimately create and approve csrs. validate the requesting identity and the certificate subject, and add exclusions for verified automation.
normal use of hping is uncommon apart from security testing and research. use by non-security engineers is very uncommon.
normal use of iodine is uncommon apart from security testing and research. use by non-security engineers is very uncommon.
oidc providers may be created during legitimate ci/cd integration (e.g., github actions, gitlab ci), kubernetes service account federation, or other web identity use cases. verify whether the user identity and timing align with approved change management processes. if this is expected administrative activity, it can be exempted from the rule.
onboarding of a sanctioned mail client, add-in, backup, archiving, crm, calendar or sharepoint application that legitimately requires delegated access with a refresh token. validate publisher verification, application ownership (esql.app_owner_type) and whether the scopes align with an approved business use case, then add an exception for the reviewed application. microsoft first-party developer tooling such as graph explorer or microsoft graph command line tools may legitimately request mailbox or file scopes when used by it staff. restricting end-user consent to verified publishers and low-risk permissions reduces this residual set to unsanctioned applications only.
one shared subscription key in front of users in different countries. split that key per application, or raise the distance and speed thresholds in the query.
operations teams create approved triggers for recurring agent workflows.
operators and automation may legitimately invoke functions from new networks (new offices, vpns, home ips, or new egress infrastructure). verify the principal in `aws.cloudtrail.user_identity.arn`, the source network, and the function, and exclude known operator networks or identities after validation.
operators and support tooling use ephemeral containers (kubectl debug) for legitimate troubleshooting. baseline expected users and exclude verified break-glass or platform identities after review.
operators may use ad hoc http clients, scripts, or penetration-test images during approved exercises or break-glass maintenance; validate tickets, source ip, and identity before treating as compromise.
org-wide backup, secret-rotation, or inventory scripts that list secrets, hooks, and repositories. allowlist known automation tokens and user agents.
organization administrators, identity teams, and compliance reviewers may list users, export members, and view groups during audits, access reviews, or offboarding. confirm the actor and change ticket before escalating.
organization and security administrators, billing tooling, landing-zone automation, and delegated administrator workflows may call these apis legitimately. interactive or one-off use from unusual principals warrants review.
organization-wide security scanners, cspm products, inventory jobs, or approved red-team exercises may list secrets across many projects. validate the principal, source ip, user agent, and schedule against known tooling before treating the activity as malicious, and exclude documented automation identities when baselined.
organizational policy changes that intentionally broaden sharing capabilities across sites.
organizational restructuring where site ownership is being transferred to new administrators.
organizations may enable fine-grained pat auto-approval intentionally to streamline trusted internal token workflows. confirm the change against a policy decision or change ticket, and scope exceptions by actor when the behavior is expected.
organizations sometimes publish shared utility layers across their own accounts or to partners intentionally. verify the layer, the granted principal in `aws.cloudtrail.request_parameters`, and the principal in `aws.cloudtrail.user_identity.arn` against approved sharing practices. known shared layers and distribution accounts can be excluded after validation.
organizations that use azure monitor alert rules with financial or billing related naming conventions for legitimate infrastructure monitoring may trigger this rule. review the email subject and recipient to determine if the alert originates from a known internal azure subscription.
organizations transfer primary ownership during reorganizations, administrator departures, or vendor transitions. verify both the previous and new owner with internal stakeholders before treating the event as malicious.
organizations with mature multi-region operations may legitimately query ec2 service quotas across regions for capacity planning, automation, or compliance validation. infrastructure-as-code tooling, quota monitoring solutions, or centralized cloud governance platforms may also generate similar activity. validate the identity, purpose, and historical behavior of the calling principal before treating this activity as malicious.
password policies may be modified by system administrators. verify that the configuration change was expected. exceptions can be added to this rule to filter expected behavior.
penetration tests and red-team exercises that use curl, httpx, or similar clients will match. add temporary exceptions for the engagement window after validation.
permissions boundaries are managed by identity/platform teams and infrastructure-as-code pipelines as part of normal governance. verify the principal in `aws.cloudtrail.user_identity.arn`, the targeted user or role, and the boundary policy against approved change records. known administration roles and deployment automation can be excluded after validation.
planned ca rotation. create the replacement ca before deleting the old one, and do not disable the certificate requirement except during a documented outage.
planned decommissioning activities or large-scale infrastructure changes may result in legitimate bulk deletion of restore point collections. verify with the user and change management processes whether these deletions are authorized. large-scale migration or cleanup projects should be coordinated and documented to avoid false positives.
planned identity provider (idp) migration or saml reconfiguration performed during an approved change window. confirm the change against a ticket, keep a second owner session active, and re-enable sso as soon as the new provider is ready.
planned ownership moves during org restructuring or when an employee takes a personal project. confirm the destination owner and that the transfer was approved.
planned policy change to allow inner-source forks. confirm change tickets and that the setting is reverted if it was a test.
planned role assignments by administrators during onboarding, role changes, or delegation. validate against the change record, and add exceptions for the administrators or automation accounts that routinely assign roles.
planned stream rotation, sink migration, or pausing a misconfigured destination by an enterprise owner. confirm the actor, change ticket, and that the production siem sink remains enabled.
planned tenant offboarding, sandbox teardown, or contract termination can produce these events. confirm the actor and timing against change management or offboarding records before escalating.
planned windows defender configuration changes.
platform agents, admission webhooks, and ci jobs may legitimately call tokenrequest under non-standard identities. baseline approved automation by client.user.email after validation. expected gke and kube-system controllers are excluded; expand exclusions if additional managed components appear in telemetry.
platform and security teams create compliance-scoped api keys when onboarding the anthropic fleet integration or setting up siem ingestion. verify the actor and confirm the key is in the approved credentials inventory.
platform and security teams delete admin api keys during scheduled rotation or decommissioning. check for a nearby `admin_api_key_created` event or an approved change ticket to explain the deletion.
platform automation, node bootstrap, and legitimate break-glass admin sessions may use these clis with overlapping arguments. tune by parent process, user, or host role (worker vs bastion).
platform engineers may nsenter into pid 1 namespaces during deep node debugging; correlate with tickets and bastion sessions before escalating.
platform installers, gitops controllers, and emergency break-glass roles sometimes ship or widen wildcard clusterroles; correlate with change records and narrow by user or service account when baselined.
platform installers, gitops controllers, and rbac refactoring may legitimately create roles with broad permissions. baseline approved automation and tune exclusions for known operators.
platform operators, installers, or runbooks that reconcile rbac and workload state may span these resource types in a short window; tune by identity, source ip, or user agent when documented.
platform or iam administrators troubleshooting secret manager access across environments may briefly exceed the project cardinality threshold. correlate with change tickets and expected administrative clients.
platform or infrastructure-as-code teams may delete empty or deprecated vaults during decommissioning, or adjust vault lock during a planned governance change (note that compliance-mode locks cannot be removed). verify the principal in \"aws.cloudtrail.user_identity.arn\" and confirm the change aligns with an approved request. known administration roles can be excluded after validation.
platform or ml engineering teams granting vertex ai access to new users and service accounts. confirm the grant against change records or the access request process.
platform or ml engineering teams may legitimately tune, iterate on, or decommission guardrails as part of normal development. if this is expected in your environment, the responsible identities can be exempted from the rule.
platform or security administrators disable compliance logging during onboarding, integration testing, or log pipeline migrations. verify the actor, source ip, and whether logging was re-enabled promptly. planned changes can be exempted from this rule.
platform or security teams may legitimately associate these policies during cluster onboarding, break-glass admin setup, or controlled rbac migrations from aws-auth. validate the caller, change ticket, and target iam principal.
platform teams publish approved custom agents during workspace rollouts.
platform, security, and observability teams create admin api keys during integration setup or scheduled key rotation. verify the actor, `anthropic.audit.scopes`, and whether the creation matches an approved change.
pods may be deleted by a system administrator. verify whether the user identity, user agent, and/or hostname should be making changes in your environment. pods deletions by unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
policy administrators, ml platform engineers, or infrastructure-as-code pipelines may legitimately update or remove automated reasoning policies during model governance changes, policy tuning, or environment teardown. verify that the user identity, source ip, and user agent correspond to an approved change and that a corresponding change request exists. known automation roles can be exempted if they generate recurring noise.
power users and legitimate multi-connector codex workflows (for example slack + github + google drive in one session) can approach these thresholds. raise `esql.gen_ai_tool_name_count_distinct` or `esql.connector_id_count_distinct` above your baseline before broad enablement.
power users iterating many related document titles in one session. raise the distinct-query or sensitive-query thresholds if approved roles remain noisy.
power users, automation engineers, or evaluation scripts that create many short-lived chats during testing can exceed the threshold without malicious intent.
power users, trainers, or documentation owners who intentionally snapshot many chats for sharing, archival, or handoff workflows can exceed the threshold without malicious intent.
powershell and windows command shell are often observed as legit child processes of the jetbrains teamcity service and may require further tuning.
powershell remoting is a dual-use protocol that can be used for benign or malicious activity. it's important to baseline your environment to determine the amount of noise to expect from this tool.
private hosted zones may be legitimately associated with vpcs by network or infrastructure administrators. verify whether the user identity, user agent, and source ip address align with expected administrative behavior. known and authorized associations may be exempted to reduce noise.
processes such as ms office using ieproxy to render html content.
prompts or completions that reference example or documentation keys (for example the aws sample access key ending in example) match the access-key pattern. review the matched value in \"gen_ai.prompt\" or \"gen_ai.completion\" and confirm whether it is a live credential before responding.
provisioned throughput changes may be performed by platform, ml, or finops teams as part of capacity planning, scaling for production demand, or cost optimization. infrastructure-as-code pipelines and automation roles may also create, update, or delete provisioned throughput during deployments. verify that the user identity, user agent, and source ip correspond to known administrators or automation and that a corresponding change request exists. if known behavior is causing false positives, it can be exempted from the rule.
psexec is a dual-use tool that can be used for benign or malicious activity. it's important to baseline your environment to determine the amount of noise to expect from this tool.
public access is a common configuration used to enable access from outside a private vpc. ensure that the instance should not be modified in this way before taking action.
publicly accessible thrift apis, partner integrations, remote offices, and routed environments that preserve public client addresses can generate legitimate alerts. validate the client, service, method, server role, and expected network path before escalating.
publishers in the maintained signer list may also sign scanners, backup clients, or other non-rmm software. confirm the actual product and purpose from executable, command-line, hash, and deployment evidence.
queries that are designed to expect empty responses or benign system errors
query log configuration deletions may occur during legitimate networking changes, logging pipeline updates, or infrastructure redesign. confirm the activity aligns with expected operations before taking action.
rare and unusual errors may indicate an impending service failure state. rare and unusual user error activity can also be due to manual troubleshooting or reconfiguration attempts by insufficiently privileged users, bugs in cloud automation scripts or workflows, or changes to iam privileges.
rare and unusual failures may indicate an impending service failure state. rare and unusual user failure activity can also be due to manual troubleshooting or reconfiguration attempts by insufficiently privileged users, bugs in cloud automation scripts or workflows, or changes to iam privileges.
rare edge cases during initial passwordless onboarding may briefly produce a windows hello for business or passkey sign-in before the device is fully registered. validate against the user's device registration timeline. genuine whfb and passkey sign-ins are otherwise accompanied by a populated device identifier.
rare kubelet or node maintenance tooling may touch secret apis; validate against change windows and approved node management paths.
rare legitimate automation or third-party tools may create inbox rules with non-alphanumeric names. validate against known messaging workflows and approved admin scripts before escalating.
rare legitimate interactive device code flows that use the microsoft authentication broker against exchange, graph, or yammer may match, for example during troubleshooting or specialized kiosk setups. document approved scenarios and exclude known principals or networks.
rare node maintenance or diagnostic tooling may touch the secrets api; validate against change windows and approved node management paths.
rare troubleshooting can open an ssh session with vpxuser. confirm the source address and that the session matches a change ticket. vcenter itself manages hosts through the api, not through ssh as vpxuser.
rare troubleshooting one-liners can use `printf` or `awk` to generate text. a line that also decodes to a syslog, firewall, or vm command should still be investigated.
rdp connections may be made directly to internet destinations in order to access windows cloud server instances but such connections are usually made only by engineers. in such cases, only rdp gateways, bastions or jump servers may be expected internet destinations and can be exempted from this rule. rdp may be required by some work-flows such as remote access and support for specialized software products and servers. such work-flows are usually known and not unexpected. usage that is unfamiliar to server or network owners can be unexpected and suspicious.
rds instances or clusters may be intentionally deleted by database administrators or during planned decommissioning activities. verify the user identity, source ip, and change context to ensure the deletion is expected. cloudformation stack removals and automated cleanup workflows may also trigger these events and can be exempted if known and authorized.
red-team or application tests that intentionally send prompts the model refuses. exclude that source ip or api management subscription.
removal of an outdated or inaccurate threat intelligence set during a scheduled feed rotation may trigger this rule. confirm the deletion corresponds to a planned feed update and that a replacement set was activated.
repositories used to distribute public images may legitimately contain principal:\"*\". this rule does not by itself determine whether a deny statement restricts the same access; review the full policy in \"aws.cloudtrail.request_parameters\" and confirm the granted actions (pull-only versus push) and whether public exposure is intended.
repository admins disabling dependabot on archival, template, or non-code repos. confirm the change was intended and that production application repos remain covered.
resource policy changes may be performed by administrators, infrastructure-as-code pipelines, or automation during legitimate onboarding, sharing, or access-management activities. verify whether the user identity, user agent, and source ip are expected to manage bedrock resource policies in your environment. known automation can be exempted from the rule.
restore point collection deletions may be performed by system administrators during routine cleanup or decommissioning activities. verify whether the user and resource should be performing these operations. deletions from unfamiliar users or targeting critical resources should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
restoring an rds db instance may be performed legitimately during troubleshooting, development refresh processes, migrations, or disaster-recovery drills. validate the user identity, source ip, automation context, and whether the restoration aligns with a known maintenance or testing workflow before treating the event as suspicious. expected behavior can be exempted through rule exceptions.
role chaining can be used as an access control. ensure that this behavior is not part of a legitimate operation before taking action.
role deletions may be done by a system or network administrator. verify whether the user email, resource name, and/or hostname should be making changes in your environment. role deletions by unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
route tables could be modified or deleted by a system administrator. verify whether the user identity, user agent, and/or hostname should be making changes in your environment. route tables being modified from unfamiliar users should be investigated. if known behavior is causing false positives, it can be exempted from the rule. also automated processes that use terraform may lead to false positives.
route tables may be created by a system or network administrators. verify whether the user identity, user agent, and/or hostname should be making changes in your environment. route table creation by unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule. automated processes that use terraform may lead to false positives.
routine automation, ci/cd jobs, infrastructure tooling, package management, and expected artifact downloads to destinations that are not yet in the allow-list may be classified as suspicious. add persistent, verified benign destinations to the deterministic allow-list.
routine waf maintenance, rule lifecycle updates, or temporary rule removals during application changes may trigger this alert. validate whether the principal, source ip, automation role, or deployment pipeline is expected to modify waf rules. confirm that the deletion corresponds to a documented change or deployment before taking action.
saml provider could be updated by a system administrator. verify whether the user identity, user agent, and/or hostname should be making changes in your environment. saml provider updates by unfamiliar users should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
saml providers may be created during legitimate identity federation setup, sso integration projects, or infrastructure-as-code deployments. verify whether the user identity and timing align with approved change management processes. if this is expected administrative activity, it can be exempted from the rule.
scheduled tasks or scripts that require information about instances in multiple regions.
seasonal or rarely used legitimate tools, such as monthly reporting or maintenance tools, can appear unusual when they are used.
security and compliance teams download audit log exports for investigations, regulatory requests, or siem validation. validate the actor and confirm the activity matches an approved ticket.
security and compliance teams download workspace logs for investigations, siem validation, or regulatory requests.
security audits may trigger this alert. conditions that generate bursts of failed logins, such as misconfigured applications or account lockouts could trigger this alert.
security audits, maintenance, and network administrative scripts may trigger this alert only when parent context, child identity, command scope, service identity, and available artifact or destination evidence align to the same bounded workflow.
security engineering teams legitimately onboard repositories and tune scan lookback windows.
security engineers running prowler, scoutsuite, or cartography on a schedule for compliance or asset inventory will trigger this rule. add host or user exceptions for known security tooling environments.
security or compliance teams using ediscovery or content search for legitimate investigations.
security or forensics workflows that send file hashes to a model for threat intelligence lookup or malware triage. review the surrounding context and verify the hash does not correspond to a credential or sensitive artifact.
security researchers, sandbox detonations, or red team engagements that intentionally run the kali365 client against a monitored tenant may generate this user agent. document approved research activity and exclude the associated principals, source ips, or tenants if expected.
security scans and tests may result in these errors. misconfigured or buggy applications may produce large numbers of these errors. if the source is unexpected, the user unauthorized, or the request unusual, these may indicate suspicious or malicious activity.
security teams may legitimately register trusted ip ranges (vpns, scanners, nat gateways) or update threat intelligence feeds as part of normal guardduty tuning. verify whether the user identity, user agent, and/or hostname should be making changes to guardduty configuration. if known behavior is causing false positives, it can be exempted from the rule.
security teams performing routine audits or assessments that involve retrieving keys or secrets from key vaults may trigger this rule if they perform multiple retrievals in a short time frame.
security teams running authorized cloud posture assessments or infrastructure cleanup may legitimately issue these commands. correlate with change management windows and operator identity before escalating.
security testing may produce events like this. activity of this kind performed by non-engineers and ordinary users is unusual.
security testing or red team exercises using proxy infrastructure.
security testing tools and frameworks may run `nmap` in the course of security auditing. some normal use of this command may originate from security engineers and network or server administrators. use of nmap by ordinary users is uncommon.
security testing tools and frameworks may run this command. some normal use of this command may originate from automation tools and frameworks.
security testing, red-team exercises, or guardrail validation may intentionally send prompt-injection or credential-harvesting payloads to an agent. confirm the source session and caller, and exclude approved testing identities after validation.
security tools and device drivers may run these programs in order to enumerate kernel modules. use of these programs by ordinary users is uncommon. these can be exempted by process name or username.
security tools and device drivers may run these programs in order to load legitimate kernel modules. use of these programs by ordinary users is uncommon.
security training, ctf-style images, or vendor diagnostics may include bash redirection or /dev/tcp examples. baseline approved images then expand exclusions as needed.
security, platform, and encryption teams legitimately update kms key policies during onboarding, key rotation, or cross-account access design. review the policy document diff, ticketing, and whether new principals are in-org.
security, red team, and ai safety staff who paste jailbreak samples, threat models, or prompt-injection research into chatgpt for analysis. exclude these users or the workspaces they use for this work.
selfsubjectaccessreview (\"can i do x\") is routinely issued by controllers checking their own permissions, so busy clusters generate benign volume from platform and add-on service accounts (for example kube-system managed add-ons such as azure-policy, microsoft defender, metrics-server, and konnectivity, plus operators like cert-manager, ingress controllers, and argo/flux). the rule ships with only the azure arc agent accounts (system:serviceaccount:azure-arc:*) excluded; that namespace exists only on arc-enabled clusters and is one example, not a complete list. treat the exclusion set as a per-environment denylist: baseline the calling service accounts and add validated platform/observability controllers after review. selfsubjectrulesreview (\"list everything i can do\") is far rarer from non-human identities and higher signal. admin impersonation workflows can also trigger this via an impersonated service account; validate the impersonating user.
service account key deletions may be done by a system or network administrator. verify whether the user email, resource name, and/or hostname should be making changes in your environment. key deletions by unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
service account keys may be created by system administrators. verify that the configuration change was expected. exceptions can be added to this rule to filter expected behavior.
service accounts can be created by system administrators. verify that the behavior was expected. exceptions can be added to this rule to filter expected behavior.
service accounts may be deleted by system administrators. verify that the behavior was expected. exceptions can be added to this rule to filter expected behavior.
service accounts may be disabled by system administrators. verify that the behavior was expected. exceptions can be added to this rule to filter expected behavior.
service accounts or applications that frequently access azure key vault for configuration or operational purposes may trigger this rule.
service accounts that perform replication may trigger this alert on the first run per ad object, but they'll be suppressed in subsequent runs since this rule uses the new_terms rule type.
service accounts whose workloads move between cloud providers, regions, or ci runners on different networks. exclude these service accounts or pin their workloads to known networks.
service principal credential additions may be done by a system or network administrator. verify whether the username, hostname, and/or resource name should be making changes in your environment. credential additions from unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
ses account sending may be legitimately re-enabled by an administrator after a sending pause for bounce/complaint rate investigation or maintenance. validate against a change management record or scheduled maintenance window. this api is rarely called in normal operations.
shared egress addresses, managed service providers, help desks, identity-provider outages, password rotation, or several legitimate users entering incorrect credentials before another user successfully authenticates may trigger this rule. add exceptions only for confirmed shared-service sources and scope them to the relevant appliance.
shared or reused service principal secrets across teams may register as new paths when first used from another site.
shared service accounts accessed from multiple legitimate infrastructure ips.
shared service accounts used by multi-region ci, build agents, or dual-homed vpn/cloud egress can span several countries. prefer per-region identities, or exclude known automation principals.
shared service or automation accounts may receive editor access during content workflows. confirm the assigner and affected project are expected for the workflow; grantee identity may require correlating org membership or `anthropic.audit.target_id` when the api supplies it.
shared systems such as kiosks and conference room computers may be used by multiple users.
shared systems such as kiosks or conference room computers may have multiple users authenticating.
sign-ins using powershell may be done by a system or network administrator. verify whether the username, hostname, and/or resource name should be signing into your environment. sign-ins from unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
signals are generated by microsoft defender for office 365. false-positives may occur if legitimate user activity is misclassified as a threat.
snapshot consolidation after backups, storage pressure, and planned decommissioning can remove every snapshot for a vm. confirm the account and whether the command ran against one vm or every vm.
snapshot exports may be performed by administrators, automation pipelines, or data engineering workflows. confirm whether the export was expected and initiated by an authorized user, role, or automation process. snapshot exports by unfamiliar principals or from unexpected networks should be investigated. if known behavior causes false positives, it can be exempted from the rule.
snapshots may be deleted by a system administrator. verify whether the user identity should be making changes in your environment. snapshot deletions by unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
socat is a dual-use tool that can be used for benign or malicious activity. some normal use of this program, at varying levels of frequency, may originate from scripts, automation tools, and frameworks. usage by web servers is more likely to be suspicious.
some automation or break-glass tooling may invoke python from scripts under /home or other temporary directories; validate parent identity and working directory before escalating.
some automation or break-glass tooling may invoke suid binaries from scripts under /home; validate parent identity and change tickets before escalating.
some break-glass workflows or automation may legitimately invoke sudo/su from scripts under user home directories. validate the initiating user, parent context, and change approvals; tune by known admin tooling paths or accounts.
some ci/cd pipelines or administrative users may use session tokens. review user context, ip, and timing to validate. this rule automatically excludes console login sessions using the aws.cloudtrail.session_credential_from_console field, which significantly reduces false positives from legitimate console-based iam operations.
some container images require the addition of privileged capabilities. this rule leaves space for the exception of trusted container images. to add an exception, add the trusted container image name to the query field, kubernetes.audit.requestobject.spec.containers.image.
some controllers and admin impersonation workflows legitimately submit self-subject reviews. excluded identities include common argo and datadog service accounts.
some legitimate administrative workflows or ci/cd automation pipelines may temporarily configure or re-enable mfa devices using session-based credentials. validate the calling identity’s purpose, source ip, and user agent to confirm whether this activity was authorized. this rule automatically excludes console login sessions, which filters out expected mfa operations performed via the aws management console.
some legitimate architectures use permissive nacls as a passthrough layer while relying on security groups for access control. validate that the modified nacl is associated with subnets where this design pattern is expected and that the change was authorized through a change management process.
some legitimate provisioning or monitoring tools enumerate extensions during onboarding. validate the source against known pbx management systems before closing.
some network security policies allow rdp directly from the internet but usage that is unfamiliar to server or network owners can be unexpected and suspicious. rdp services may be exposed directly to the internet in some networks such as cloud environments. in such cases, only rdp gateways, bastions or jump servers may be expected expose rdp directly to the internet and can be exempted from this rule. rdp may be required by some work-flows such as remote access and support for specialized software products and servers. such work-flows are usually known and not unexpected.
some network security policies allow ssh directly from the internet but usage that is unfamiliar to server or network owners can be unexpected and suspicious. ssh services may be exposed directly to the internet in some networks such as cloud environments. in such cases, only ssh gateways, bastions or jump servers may be expected expose ssh directly to the internet and can be exempted from this rule. ssh may be required by some work-flows such as remote access and support for specialized software products and servers. such work-flows are usually known and not unexpected.
some networks may utilize pptp protocols but this is uncommon as more modern vpn technologies are available. usage that is unfamiliar to local network administrators can be unexpected and suspicious. torrenting applications may use this port. because this port is in the ephemeral range, this rule may false under certain conditions, such as when an application server replies to a client that used this port by coincidence. this is uncommon but such servers can be excluded.
some normal applications and scripts may contain no user agent. most legitimate web requests from the internet contain a user agent string. requests from web browsers almost always contain a user agent string. if the source is unexpected, the user unauthorized, or the request unusual, these may indicate suspicious or malicious activity.
some normal use of this command may originate from security engineers and network or server administrators, but this is usually not routine or unannounced. use of `nping` by non-engineers or ordinary users is uncommon.
some normal use of this command may originate from server or network administrators engaged in network troubleshooting.
some normal use of this program, at varying levels of frequency, may originate from scripts, automation tools and frameworks. usage by non-engineers and ordinary users is unusual.
some organizations allow login with the root user without mfa, however, this is not considered best practice by aws and increases the risk of compromised credentials.
some organizations intentionally use lambda functions to provision iam principals, bootstrap accounts, or run identity automation (including roles and instance profiles). confirm the function name in `user_identity.arn`, deployment pipelines, and change records. exclude known automation roles or specific `session_context.session_issuer.arn` values after validation.
some organizations may have legitimate use cases for s3 browser or cyberduck, particularly in development, data migration, or backup scenarios. verify whether the iam principal, source network, and accessed buckets align with approved workflows. unexpected activity from these clients, especially accessing sensitive buckets, should be investigated.
some organizations may legitimately expose lambda functions for cross-account or anonymous invocation (e.g., custom public apis, integrations, or legacy architectures). validate whether the function owner explicitly intended to make the function publicly invokable. routine ci/cd deployments or iac templates may also temporarily set permissive policies; confirm this is expected behavior before treating it as suspicious.
some platform or security images legitimately require elevated capabilities. add image or namespace exceptions after review.
some proxied applications may use these ports but this usually occurs in local traffic using private ips which this rule does not match. proxies are widely used as a security technology but in enterprise environments this is usually local traffic which this rule does not match. if desired, internet proxy services using these ports can be added to allowlists. some screen recording applications may use these ports. proxy port activity involving an unusual source or destination may be more suspicious. some cloud environments may use this port when vpns or direct connects are not in use and cloud instances are accessed across the internet. because these ports are in the ephemeral range, this rule may false under certain conditions such as when a nated web server replies to a client which has used a port in the range by coincidence. in this case, such servers can be excluded if desired.
some public-facing applications, webhooks, and lightweight apis legitimately use lambda function urls with no authentication and enforce access control elsewhere. verify the function, the principal in `aws.cloudtrail.user_identity.arn`, and the intended exposure with the owning team. known public endpoints can be excluded after validation.
some recovery and lab images leave execinstalledonly off, and an approved change can disable it while a custom vib is installed. confirm the setting is restored to true afterward.
specialized crash-analysis, debugging, or diagnostics tooling that invokes werfaultsecure.exe directly to capture a secure process dump. validate the parent process, its code signature, and the targeted process before adding an exception.
spikes in error message activity can also be due to bugs in cloud automation scripts or workflows; changes to cloud automation scripts or workflows; adoption of new services; changes in the way services are used; or changes to iam privileges.
spikes in failures can also be due to bugs in cloud automation scripts or workflows; changes to cloud automation scripts or workflows; adoption of new services; changes in the way services are used; or changes to iam privileges.
split-horizon dns, vpn transitions, service discovery, failover, hairpin nat, and dual-stack names that publish a public a record with a unique-local aaaa record can legitimately produce public and private answers for the same name. recursive resolvers, dns forwarders, and localhost listeners can also aggregate many endpoints under one client address. security products may sinkhole suspicious domains to loopback or private addresses with short ttls. confirm the domain, resolver placement, and client identity before adding an exception, and scope exceptions by registered domain or client rather than globally.
split-tunnel or dual-homed devices can present a new microsoft 365 egress for tooling clients. confirm the ip belongs to the enrolled device before treating the event as cookie theft.
split-tunnel or dual-homed devices may present different egress ips for wam versus azure cli. confirm both ips belong to the same physical device before raising severity.
ssh connections may be made directly to internet destinations in order to access linux cloud server instances but such connections are usually made only by engineers. in such cases, only ssh gateways, bastions or jump servers may be expected internet destinations and can be exempted from this rule. ssh may be required by some work-flows such as remote access and support for specialized software products and servers. such work-flows are usually known and not unexpected. usage that is unfamiliar to server or network owners can be unexpected and suspicious.
ssh over ports apart from the traditional port 22 is highly uncommon. this rule alerts the usage of the such uncommon ports by the ssh service. tuning is needed to have higher confidence. if this activity is expected and noisy in your environment, consider adding exceptions - preferably with a combination whitelisted ports for such legitimate ssh activities.
ssh usage may be legitimate depending on the environment. access patterns and follow-on activity should be analyzed to distinguish between authorized and potentially malicious behavior.
startup, helm, or controllers may legitimately touch many secrets in one window; tune by client.user.email, namespace, or ip allowlists when baselined.
static website hosting configurations may intentionally use a public-read acl on s3 buckets that serve web content. validate that the target bucket is a known public-facing asset and that the change was authorized. consider adding exclusions for specific bucket names used for static hosting.
storage administrators may legitimately delete snapshots during routine maintenance, storage optimization, or cleanup of old backup data. verify that the deletion was expected and follows organizational data retention policies. consider exceptions for approved maintenance windows or automated retention management tools.
storage administrators may legitimately delete storage accounts during decommissioning, resource cleanup, or infrastructure optimization. verify that the deletion was expected and follows organizational change management processes. consider exceptions for approved maintenance windows.
storage administrators may legitimately enable public access for specific business requirements such as hosting public content or cdn integration. verify that the configuration change was expected and follows organizational policies. consider exceptions for approved storage accounts.
storage bucket configuration may be modified by system administrators. verify that the configuration change was expected. exceptions can be added to this rule to filter expected behavior.
storage bucket permissions may be modified by system administrators. verify that the configuration change was expected. exceptions can be added to this rule to filter expected behavior.
storage buckets may be deleted by a system or network administrator. verify whether the user email, resource name, and/or hostname should be making changes in your environment. bucket deletions by unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
strace is a dual-use tool that can be used for benign or malicious activity. some normal use of this command may originate from developers or sres engaged in debugging or system call tracing.
stress tests, fault-injection exercises, fuzzing, and authorized vulnerability testing may intentionally trigger segmentation faults or access violations.
subscription creations may be done by a system or network administrator. verify whether the user email, resource name, and/or hostname should be making changes in your environment. subscription creations by unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
subscription deletions may be done by a system or network administrator. verify whether the user email, resource name, and/or hostname should be making changes in your environment. subscription deletions by unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
support engineers and iot operators may run localproxy on field devices or jump hosts that legitimately use aws iot secure tunneling. confirm the host is an approved device-management asset, the parent process and binary path are expected, and the destination mapping points at an authorized local service. allowlist by host, user, or signed install path where that use is documented.
support engineers, infrastructure-as-code, and vm health automation may legitimately retrieve boot diagnostics during troubleshooting. the first occurrence per principal will alert; baseline expected support users, service principals, and managed identities and exclude them if the activity is verified as authorized.
suppression rules can be created legitimately by a system administrator. verify whether the user identity, user agent, and/or hostname should be making changes in your environment. suppression rules created by unfamiliar users should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
suspending the recording of a trail may be done by a system or network administrator. verify whether the user identity, user agent, and/or hostname should be making changes in your environment. trail suspensions from unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
system or platform administrators may legitimately use the serial console to troubleshoot a vm that is unreachable over the network (boot failures, misconfigured firewall/nsg, lost ssh/rdp access). the first connection per identity and source asn will alert; baseline expected break-glass principals and their corporate/vpn networks and exclude them if verified as authorized.
system updates, scheduled backups, or misconfigured services may trigger this alert.
teams enable approved mcp connectors for data platforms, ticketing systems, and internal tools during claude rollouts. validate the server name, actor, and whether the integration matches an approved request.
teams external access may be enabled by a system or network administrator. verify that the configuration change was expected. exceptions can be added to this rule to filter expected behavior.
teams guest access may be enabled by a system or network administrator. verify that the configuration change was expected. exceptions can be added to this rule to filter expected behavior.
teams intentionally publish gpts or skills for approved internal or partner use under change management.
telnet can be used for both benign or malicious purposes. telnet is included by default in some linux distributions, so its presence is not inherently suspicious. the use of telnet to manage devices remotely has declined in recent years in favor of more secure protocols such as ssh. telnet usage by non-automated tools or frameworks may be suspicious.
temporarily allowing pats during a documented migration off github apps, then re-enabling the restriction. confirm with organization owners.
terraform running from an asn other than amazon, google, microsoft, verizon, or at&t is still in scope. a large apply or refresh can exceed 20 instances.
testing updates to compliance policies.
testing workflows that verify a sandbox email address and then clean it up may trigger this rule. confirm that the email identity verified and deleted corresponds to a planned test rather than a production or attacker-controlled domain.
the build engine is commonly used by windows developers but use by non-engineers is unusual. it is quite unusual for this program to be started by an office application like word or excel.
the copied-title check looks for the english text \"copy of \". workspace locales that translate that prefix will not match.
the deletionprotection feature must be disabled as a prerequisite for deletion of a db instance or cluster. ensure that the instance should not be modified in this way before taking action.
the guardduty detector may be deleted by a system or network administrator. verify whether the user identity, user agent, and/or hostname should be making changes in your environment. detector deletions by unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
the html help executable program (hh.exe) runs whenever a user clicks a compiled help (.chm) file or menu item that opens the help file inside the help viewer. this is not always malicious, but adversaries may abuse this technology to conceal malicious code.
the number of okta user password reset or account unlock attempts will likely vary between organizations. to fit this rule to their organization, users can duplicate this rule and edit the schedule and threshold values in the new rule.
the same automation identity may legitimately trigger a first-seen-ip alert and unrelated medium-or-higher findings in the same window (for example, a noisy compliance rule). review sibling `kibana.alert.rule.name` values, rule tags, and cloudtrail context for the access key before escalating.
the ssm agent may invoke short-lived utilities (for example identity or environment probes) during session setup. additional exclusions may be required in your environment.
the vast majority of vm writes are benign: provisioning, resizing, tagging, extension/identity changes, autoscale, and configuration management by users, service principals, and managed identities. this rule is informational only and is intended for correlation and baselining, not standalone alerting.
there is a potential for false positives if direct kubernetes api requests are used for legitimate purposes, such as debugging or troubleshooting. it is important to investigate any alerts generated by this rule to determine if they are indicative of malicious activity or part of legitimate container activity.
there is a potential for false positives if socks proxies are used for legitimate purposes, such as debugging or troubleshooting, or if the \"curl\" command-line tool is used to download files from a known benign source. it is important to investigate any alerts generated by this rule to determine if they are indicative of malicious activity or part of legitimate container activity.
there is a potential for false positives if the \"env\" or \"printenv\" commands are used for legitimate purposes, such as debugging or troubleshooting. it is important to investigate any alerts generated by this rule to determine if they are indicative of malicious activity or part of legitimate container activity.
there is a potential for false positives if the \"id\", \"whoami\", \"capsh\", \"getcap\", or \"lsns\" commands are used for legitimate purposes, such as debugging or troubleshooting. for example, an operator may use the \"id\" command to verify the identity of the current user, or the \"whoami\" command to verify the current user. it is important to investigate any alerts generated by this rule to determine if they are indicative of malicious activity or part of legitimate container activity.
there is a potential for false positives if the \"jq\" command is used for legitimate purposes, such as debugging or troubleshooting. it is important to investigate any alerts generated by this rule to determine if they are indicative of malicious activity or part of legitimate container activity.
there is a potential for false positives if the \"which\" command is used for legitimate purposes, such as debugging or troubleshooting. it is important to investigate any alerts generated by this rule to determine if they are indicative of malicious activity or part of legitimate container activity.
there is a potential for false positives if the access to the service account token or certificate is used for legitimate purposes, such as debugging or troubleshooting. it is important to investigate any alerts generated by this rule to determine if they are indicative of malicious activity or part of legitimate container activity.
there is a potential for false positives if the container is used for legitimate administrative tasks that require the use of container management utilities, such as deploying, scaling, or updating containerized applications. it is important to investigate any alerts generated by this rule to determine if they are indicative of malicious activity or part of legitimate container activity.
there is a potential for false positives if the direct interactive kubernetes api requests are used for legitimate purposes, such as debugging or troubleshooting. it is important to investigate any alerts generated by this rule to determine if they are indicative of malicious activity or part of legitimate container activity.
there is a potential for false positives if the dns enumeration tools are used for legitimate purposes, such as debugging or troubleshooting. it is important to investigate any alerts generated by this rule to determine if they are indicative of malicious activity or part of legitimate container activity.
there is a potential for false positives if the files are downloaded for legitimate purposes, such as debugging or troubleshooting, or if the files are downloaded from a known benign source. it is important to investigate any alerts generated by this rule to determine if they are indicative of malicious activity or part of legitimate container activity.
there is a potential for false positives if the processes are killed for legitimate purposes, such as debugging or troubleshooting. it is important to investigate any alerts generated by this rule to determine if they are indicative of malicious activity or part of legitimate container activity.
there is a potential for false positives if the reading of the service account namespace file is used for legitimate purposes, such as debugging or troubleshooting. it is important to investigate any alerts generated by this rule to determine if they are indicative of malicious activity or part of legitimate container activity.
there is a potential for false positives if the service account token or certificate is used for legitimate purposes, such as debugging or troubleshooting. it is important to investigate any alerts generated by this rule to determine if they are indicative of malicious activity or part of legitimate container activity.
there is a potential for false positives if the tools are installed for legitimate purposes, such as debugging or troubleshooting. it is important to investigate any alerts generated by this rule to determine if they are indicative of malicious activity or part of legitimate container activity.
there is a potential for false positives when the command line arguments looked for in this rule are used for legitimate purposes, such as debugging or troubleshooting. it is important to investigate any alerts generated by this rule to determine if they are indicative of malicious activity or part of legitimate container activity.
there is a risk of false positives if there are several containers named the same, as the rule may correlate the request to the wrong container.
there is no known legitimate reason for padding policies with white spaces to the extent it would take to trigger cloudtrail's logging constraints. any instance of this should be investigated.
there is no known legitimate workflow that adds iam access keys or console login profiles to a bedrock api key phantom user. any match should be investigated. confirm the actor in \"aws.cloudtrail.user_identity.arn\" and the target user in \"aws.cloudtrail.request_parameters\", and remove the credential if it was not expected.
there is usually no reason to remove modules, but some buggy modules require it. these can be exempted by username. note that some linux distributions are not built to support the removal of modules at all.
these programs may be used by windows developers but use by non-engineers is unusual.
third-party saas applications with sharepoint integration may appear as new app ids when users first authorize access.
this is an intentional action taken by aws in the event of compromised credentials. follow the instructions specified in the support case created for you regarding this event.
this is meant to run only on datasources using elastic agent 7.14+ since versions prior to that will be missing the necessary field, resulting in false positives.
this is very uncommon behavior and should result in minimal false positives, ensure validity of the triggered event and include exceptions where necessary.
this pattern may occur during legitimate device switching or roaming between networks (e.g., corporate to mobile). developers or power users leveraging multiple environments may also trigger this detection if session persistence spans ip ranges. still, this behavior is rare and warrants investigation when rapid ip switching and graph access are involved.
this rule could generate false positives if the process arguments leveraged by the exploit are shared by custom scripts using the sudo or sudoedit binaries. only sudo versions 1.8.2 through 1.8.31p2 and 1.9.0 through 1.9.5p1 are affected; if those versions are not present on the endpoint, this could be a false positive.
this rule could identify benign domains that are formatted similarly to fin7's command and control algorithm. alerts should be investigated by an analyst to assess the validity of the individual observations.
this rule does not differentiate by itself whether the same policy also includes deny statements that restrict public access. if a policy includes both effect=allow and effect=deny with principal:\"*\", this rule may still trigger. such cases should be manually analyzed to verify whether the deny statement effectively negates the public exposure.
this rule does not indicate that a sql injection attack occurred, only that the `sqlmap` tool was used. security scans and tests may result in these errors. if the source is not an authorized security tester, this is generally suspicious or malicious activity.
this rule is not looking for threat activity. disable the rule if you're already familiar with alerts.
this rule may trigger in cases where a user has routine work patterns that result in infrequent authentications.
this rule should be tailored to either exclude systems, as sources or destinations, in which this behavior is expected.
this rule should be tailored to exclude systems, either as sources or destinations, in which this behavior is expected.
this rule uses matches regex patterns for common ransom note file names. ensure that the uploaded file is not part of a legitimate operation before taking action.
this rule was tuned using the following baseline: https://raw.githubusercontent.com/microsoft/css-exchange/main/security/baselines/baseline_15.2.792.5.csv from microsoft. depending on version, consult https://github.com/microsoft/css-exchange/tree/main/security/baselines to help determine normalcy.
to tune this rule, add exceptions to exclude any event.code which should not trigger this rule.
to tune this rule, add exceptions to exclude any google_workspace.alert.type or rule.name which should not trigger this rule.
topic creations may be done by a system or network administrator. verify whether the user email, resource name, and/or hostname should be making changes in your environment. topic creations by unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
topic deletions may be done by a system or network administrator. verify whether the user email, resource name, and/or hostname should be making changes in your environment. topic deletions by unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
tor client activity is uncommon in managed enterprise networks but may be common in unmanaged or public networks where few security policies apply. because these ports are in the ephemeral range, this rule may false under certain conditions such as when a nated web server replies to a client which has used one of these ports by coincidence. in this case, such servers can be excluded if desired.
traffic may leave the cluster via corporate proxies, vpns, or non-aws nat providers that populate a non-amazon asn organization name while still being legitimate. aws ip ranges are also labeled with other organization strings (for example `amazon-02`); this rule only excludes `amazon.com, inc.` per the match condition—tune with additional approved asns, cidrs, or known automation identities if needed.
traffic mirroring may be done by a system or network administrator. verify whether the user identity, user agent, and/or hostname should be making changes in your environment. traffic mirroring from unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
trail creations may be made by a system or network administrator. verify whether the user identity, user agent, and/or hostname should be making changes in your environment. trail creations by unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
trail deletions may be made by a system or network administrator. verify whether the user identity, user agent, and/or hostname should be making changes in your environment. trail deletions by unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
trail updates may be made by a system or network administrator. verify whether the user identity, user agent, and/or hostname should be making changes in your environment. trail updates from unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
trufflehog is a legitimate open-source tool used by security professionals and developers to search for sensitive information, such as passwords, api keys, and other secrets, within code repositories. it is commonly employed during security assessments and code reviews to identify potential vulnerabilities.
trusted applications for managing calendars and reminders.
trusted applications persisting via launchagent
trusted applications persisting via launchdaemons
trusted domains may be added by system administrators. verify that the configuration change was expected. exceptions can be added to this rule to filter expected behavior.
trusted finder sync plugins
trusted openssh executable updates. it's recommended to verify the integrity of openssh binary changes.
trusted solarwinds child processes. verify process details such as network connections and file writes.
trusted system module updates or allowed pluggable authentication module (pam) daemon configuration changes.
trusted system or adobe acrobat related processes.
trusted webdav content when the command namespace, parent, utility identity, signer, user/host scope, and child/artifact/destination evidence align with a recognized workflow
unauthorized requests from service accounts are normal and expected behavior. analyze the user agent, pod and other node information to determine if the request is legitimate.
uncommon compiler activity can be due to an engineer running a local build on a production or staging instance in the course of troubleshooting or fixing a software issue.
uncommon sudo activity can be due to an engineer logging onto a server instance in order to perform manual troubleshooting or reconfiguration.
uncommon user activity can be due to an administrator or help desk technician logging onto a workstation or server in order to perform manual troubleshooting or reconfiguration.
uncommon user activity can be due to an engineer logging onto a server instance in order to perform manual troubleshooting or reconfiguration.
uncommon user command activity can be due to an engineer logging onto a server instance in order to perform manual troubleshooting or reconfiguration.
uncommon user privilege elevation activity can be due to an administrator, help desk technician, or a user performing manual troubleshooting or reconfiguration.
uncommon username activity can be due to an engineer logging onto a server instance in order to perform manual troubleshooting or reconfiguration.
unexpected system errors
uninstall or manual deletion of a legitimate printing driver files. verify the printer file metadata such as manufacturer and signature information.
unmanaged or imaged windows 10 20h1 hosts may legitimately report the `10.0.19041.928` build with a default \"desktop-\" host name. validate against your device inventory and patch baseline before escalating.
unmanaged or never-patched windows 10 22h2 hosts may legitimately report the `10.0.19045.2006` build with a default \"desktop-\" host name. validate against your device inventory and patch baseline before escalating.
updates to approved and trusted ssh executables can trigger this rule.
user accounts can be used as service accounts and have their password set never to expire. this is a bad security practice that exposes the account to credential access attacks. for cases in which user accounts cannot be avoided, microsoft provides the group managed service accounts (gmsa) feature, which ensures that the account password is robust and changed regularly and automatically.
user accounts that are rarely active, such as a site reliability engineer (sre) or developer logging into a production server for troubleshooting, may trigger this alert. under some conditions, a newly created user account may briefly trigger this alert while the model is learning.
user group access may be modified by an administrator to allow external access for community purposes. doing so for a user group whom has access to sensitive information or operational resources should be monitored closely.
user using a new mail client or mobile application to access their mailbox.
users accessing their accounts from anonymized ip addresses, such as vpns or tor, may trigger this rule. if this is expected behavior in your environment, consider adjusting the rule or adding exceptions for specific users or ip ranges.
users accessing their mailboxes using custom or third-party applications that are authorized by the organization, such as crm or erp systems.
users accessing their mailboxes using first-party microsoft applications that are not typically used by the user, such as outlook on the web or outlook mobile app.
users and administrators can create inbox rules for legitimate purposes. verify if it complies with the company policy and done with the user's consent. exceptions can be added to this rule to filter expected behavior.
users authenticating from multiple devices and using the devicecode protocol or the visual studio code client.
users browsing many stale or revoked shared chat links during incident response or legal review can produce bursts of access failures. confirm whether the activity matches an approved investigation before escalating.
users calling aad graph from corporate office networks or home isps with custom tooling. tune the excluded asn organisation list to your environment.
users delete memories during privacy cleanup or troubleshooting.
users downloading many attachments during legitimate research or migration work.
users drafting security guidance, runbooks, or support replies that quote rotate or revoke advice without an in-chat exposure. confirm the assistant is reacting to a secret in the conversation.
users enrolling or joining devices while on corporate vpns, consumer vpns, or cloud egress that map to the listed asns may match. legitimate mobile device management or bulk provisioning that uses the broker against device registration service from the same networks can also trigger alerts. baseline `source.as.organization.name` and successful broker-to-drs sign-ins before tuning exclusions for approved asns or user groups.
users exporting or reviewing many drive files through chatgpt during approved research, ediscovery, or migration work.
users intentionally share conversations for collaboration within the organization.
users launching azure storage explorer (including the installer) for the first time on a host.
users legitimately accessing microsoft graph api using the specified client application id and tenant id. this may include authorized applications or services that interact with microsoft graph on behalf of users.
users legitimately asking chatgpt to send mail through an approved gmail connector.
users legitimately connect approved apps during onboarding.
users legitimately deleting mfa notification emails after reviewing them.
users legitimately switching networks (e.g., vpn connect/disconnect, office to home) may trigger ip-based detection. review the geographic distance and time between ip changes to assess legitimacy.
users may legitimately access aws systems manager (ssm) parameters using the getparameter, getparameters, or describeparameters api actions with credentials in the request parameters. ensure that the user has a legitimate reason to access the parameters and that the credentials are secured.
users may share an endpoint related to work or personal use in which separate okta accounts are used.
users mistype passwords repeatedly or sso misconfiguration can generate clusters of failed logins.
users on vpn or proxy egress that geo-resolves through a region distant from the user's physical location. mobile clients on cellular carrier networks that peer through regional hubs may geo-resolve to a different region than the user's physical location.
users on vpn or proxy egress that geo-resolves through multiple regions in a short window.
users on vpns or privacy relays that rotate exit countries. corroborate with asn and user agent before acting.
users on vpns, carrier nat, or cloud egress that map to flagged asns may match. legitimate bulk enrollment or scripted onboarding that uses the same oauth client can also produce the sequence. baseline `source.as.organization.name` and successful registration sources before adding exclusions.
users or administrators purging old chats during workspace hygiene, retention exercises, or gdpr-related cleanup can exceed the daily threshold legitimately.
users or system administrator cleaning out folders.
users publish artifacts intentionally for demos, documentation, or external collaboration. validate the artifact, actor, and business justification before escalating.
users purging old chats during workspace hygiene or retention cleanup.
users running scripts in the course of technical support operations of software upgrades could trigger this alert. a newly installed program or one that runs rarely as part of a monthly or quarterly workflow could trigger this alert.
users testing new model deployments or updated compliance policies without amazon bedrock guardrails.
users who frequently travel or access their accounts from different geographic locations may trigger this rule due to the unlikely travel detection mechanism. if this is expected behavior, consider adjusting the rule or adding exceptions for specific users.
users who have recently changed their passwords may trigger this rule due to the password spray detection mechanism. if this is expected behavior, consider adjusting the rule or adding exceptions for specific users.
users with legitimate multi-location access (mobile + home + office) experiencing concurrent login issues.
users working from a new network such as travel, a new isp, or a mobile hotspot. confirm the location with the user.
users working late, or logging in from unusual time zones while traveling, may trigger this rule.
valid clusters may be created by a system or network administrator. verify whether the user identity, user agent, and/or hostname should be making changes in your environment. cluster creations by unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
valid clusters or instances may be stopped by a system administrator. verify whether the user identity, user agent, and/or hostname should be making changes in your environment. cluster or instance stoppages from unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
vendor onboarding or reconfiguration where a consented third-party management or backup application is deliberately granted a directory role by its own setup workflow. confirm with the application owner and the change record, then exclude the specific application id.
verify whether the user identity should be making changes in your environment. policy updates from unfamiliar users should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
verify whether the user identity should be using the sts getcalleridentity api. if known behavior is causing false positives, it can be exempted from the rule.
verify whether the user identity should be using the triggered api. if known behavior is causing false positives, it can be exempted from the rule. the \"history_window_start\" value can be modified to reflect the expected frequency of known activity within a particular environment.
verify whether the user identity, user agent, and/or hostname should be making changes in your environment. flow log deletions by unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
verify whether the user identity, user agent, and/or hostname should be using getsecretstring api for the specified secretid. if known behavior is causing false positives, it can be exempted from the rule.
virtual machine process kills also happen during planned maintenance, host upgrades, and troubleshooting of a stuck vm. confirm the world id, the account, and whether the same session also enumerates `/vmfs/volumes` or removes snapshots.
virtual network device modification or deletion may be performed by a system administrator. verify whether the user identity, user agent, and/or hostname should be making changes in your environment. virtual network device modification or deletion by unfamiliar users should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
virtual private cloud networks may be deleted by system administrators. verify that the configuration change was expected. exceptions can be added to this rule to filter expected behavior.
virtual private cloud routes may be created by system administrators. verify that the configuration change was expected. exceptions can be added to this rule to filter expected behavior.
virtual private cloud routes may be deleted by system administrators. verify that the configuration change was expected. exceptions can be added to this rule to filter expected behavior.
vm export and ec2 image creation may be done by system administrators, devops or migration teams as part of planned maintenance, disaster-recovery or known backup methods. verify whether the user identity, user agent, and/or hostname should be making changes in your environment. exports from unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
vm exports may be done by a system or network administrator. verify whether the user identity, user agent, and/or hostname should be making changes in your environment. vm exports from unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
vnc connections may be made directly to linux cloud server instances but such connections are usually made only by engineers. vnc is less common than ssh or rdp but may be required by some work flows such as remote access and support for specialized software products or servers. such work-flows are usually known and not unexpected. usage that is unfamiliar to server or network owners can be unexpected and suspicious.
vnc connections may be received directly to linux cloud server instances but such connections are usually made only by engineers. vnc is less common than ssh or rdp but may be required by some work-flows such as remote access and support for specialized software products or servers. such work-flows are usually known and not unexpected. usage that is unfamiliar to server or network owners can be unexpected and suspicious.
vpn or cloud egress that geolocates incorrectly or jumps between distant pops. validate the ip locations before rotating credentials.
vpn or proxy egress that geo-resolves through hubs far from the caller's physical location. corroborate with asn and user-agent diversity before rotating credentials.
vpn, proxy, or cloud egress that geolocates incorrectly or jumps between distant points of presence. validate the ip locations and asns before rotating credentials.
web activity that is uncommon, like security scans, may trigger this alert and may need to be excluded. a new or rarely used program that calls web services may trigger this alert.
web activity that occurs rarely in small quantities can trigger this alert. possible examples are browsing technical support or vendor urls that are used very sparsely. a user who visits a new and unique web destination may trigger this alert when the activity is sparse. web applications that generate urls unique to a transaction may trigger this when they are used sparsely. web domains can be excluded in cases such as these.
web servers or administrators may create php files in the wordpress plugin directory during maintenance.
web-server, runtime, module, extension, or application defects can legitimately crash a worker after an upgrade, configuration change, or unusual request.
werfault.exe will legitimately spawn when dns.exe crashes, but the dns service is very stable and so this is a low occurring event. denial of service (dos) attempts by intentionally crashing the service will also cause werfault.exe to spawn.
while this can be normal behavior, it should be investigated to ensure validity. verify whether the user identity should be using the iam `attachrolepolicy` api operation to attach the `administratoraccess` policy to the target role.
windows firewall can be disabled by a system administrator. verify whether the user identity, user agent, and/or hostname should be making changes in your environment. windows profile being disabled by unfamiliar users should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
winrm is a dual-use protocol that can be used for benign or malicious activity. it's important to baseline your environment to determine the amount of noise to expect from this tool.
workloads or operators that change client libraries after a deploy may introduce a new user agent for an otherwise known identity; baseline after validation.