LoFP LoFP / elastic

elastic

TitleTags
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 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 vba for outlook is usually configured interactively via outlook.exe.
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 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.
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 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 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 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 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 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 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 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.
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.
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 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 legitimately enabling external sharing for a new collaboration site or project.
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 enable hostipc for legitimate debugging. exclude trusted users or namespaces after baselining.
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 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 reading kubeconfig or cloud profiles during migration can match; correlate with change tickets and bastion sessions.
administrators routinely exec into pods for troubleshooting. baseline expected users and target pods, then exclude known break-glass identities.
administrators using service principal credentials to manage arc-connected clusters during maintenance windows may trigger this rule. correlate with change management records.
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).
ami sharing is a common practice in aws environments. ensure that the sharing is authorized before taking action.
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 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 migrations or reconfigurations that switch from certificate/secret authentication to federated credentials will appear as new behavior. confirm with application owners.
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. 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 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 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 tickets and identity scope before treating as compromise.
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.
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 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 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 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 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 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 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 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 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 and unbounded retries 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. applications integrated with aws might assume roles to access aws resources. automated workflows might assume roles 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, 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 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.
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 against privileged targets may match. map expected callers and expand client.user.email exclusions as needed.
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.
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, 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\"
carrier-grade nat or load-balanced corporate egress that occasionally routes through alternate asns.
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/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 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.
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 modified 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.
corporate proxy or vpn exit nodes may aggregate traffic from multiple legitimate users.
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 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 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 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.
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.
delegation by first-party applications that require mailbox access.
deletion of a resource group 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. resource group deletions from unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
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.
deletion of diagnostic settings 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. diagnostic settings deletion from unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
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 against aad graph for prototyping. rare in production tenants and typically low-volume; the burst threshold limits exposure.
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 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 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 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 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 performing browsers plugin or extension debugging.
developers testing new applications or oauth flows in non-production tenants may generate alerts during development cycles.
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.
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 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.
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, 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.
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 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 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 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.
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 for legitimate purposes.
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.
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 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.
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, 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.
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 workspace users typically share drive resources with a shareable link where parameters are edited to indicate when it is viewable or editable by the intended recipient. it is uncommon for a user in an organization to manually copy a drive object from an external drive to their corporate drive. this may happen where users find a useful spreadsheet in a public drive, for example, and replicate it to their drive. it is uncommon for the copied object to execute a container-bound script either unless the user was intentionally aware, suggesting the object uses container-bound scripts to accomplish a legitimate task.
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.
http traffic on a non standard port. verify that the destination ip address is not related to a domain controller.
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.
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 `esql.source_ip_values` / `esql.source_asn_names` 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.
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, 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, 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.
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.
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.
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 searching for configuration or infrastructure documentation.
it administrators using pnp powershell for site management, migration, or backup operations.
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.
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 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 administrative activity
legitimate administrative activity related to shadow copies.
legitimate administrative or security assessment activities may use these user-agents, especially in environments where bloodhound 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 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 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.19041.928` build (windows 10 20h1) 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 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 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 paths may match. baseline approved operators and automation identities after review.
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 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 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 site-to-site or client vpns that use ipsec nat traversal will establish outbound tunnels on udp port 4500. where these tunnels are expected, the internal source hosts or external vpn gateway ip addresses can be excluded. requiring both the source and destination port to be 4500 already removes alerts caused by an external server coincidentally replying to an ephemeral udp source port of 4500.
legitimate software or scripts using cron jobs for recurring tasks.
legitimate spikes in usage due to business processes
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 windows defender configuration changes
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.
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.
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 windows installers leveraging rundll32 for installation.
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.
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.
mobile access may also result in false positives, as users may log in from various locations while on the go.
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.
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 monitoring or management products may have a web server component that runs shell commands as part of normal behavior.
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 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, 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 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 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 workload identity federation configurations for legitimate automation will trigger on first use.
node agents and observability daemonsets commonly mount host paths like /proc or /var/log. controller ownerreferences exclusions reduce noise; add image exceptions if needed.
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.
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 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.
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.
organizational policy changes that intentionally broaden sharing capabilities across sites.
organizational restructuring where site ownership is being transferred to new administrators.
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 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.
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 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 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 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 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 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 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.
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.
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.
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 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.
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.
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.
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.
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 or compliance teams using ediscovery or content search for legitimate investigations.
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 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.
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 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.
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 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 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 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 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.
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.
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.
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.
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, 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 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.
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.
testing updates to compliance policies.
the build engine is commonly used by windows developers but use by non-engineers is unusual.
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 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 calling aad graph from corporate office networks or home isps with custom tooling. tune the excluded asn organisation list to your environment.
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 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 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 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. corporate aws workspaces / vdi deployments where employees interactively sign in from a cloud-provider asn.
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 system administrator cleaning out folders.
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 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.
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 getsecretvalue or batchgetsecretvalue apis for the specified secretid. if known behavior is causing false positives, it can be exempted from the rule.
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.
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.
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 `createaccesskey` for the targeted user.
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.