LoFP LoFP / aws

aws rule

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 domain may be transferred to another aws account by a system or network administrator. verify whether the user identity, user agent, and/or hostname should be making changes in your environment. domain transfers from unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
a domain transfer lock may be disabled by a system or network administrator. verify whether the user identity, user agent, and/or hostname should be making changes in your environment. activity from unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
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 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 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 s3 configuration change 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. s3 configuration change from unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
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 single port being opened for a new service that is known to be deploying
a team has configured an ec2 instance to use instance profiles that grant the option for the ec2 instance to talk to other aws services
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.
adding user keys to their own accounts (the filter cannot cover all possible variants of user naming)
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 closing unused ports to reduce the attack surface
administrators listing buckets, it may be necessary to filter out users who commonly conduct this activity.
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 upload ssh public keys to ec2 instances for legitimate purposes.
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 who are unaware of the deprecation status of amis they are using.
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 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.
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 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.
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.
assumerole from unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
assumerole 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.
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 changes to the aws account's identity provider
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.
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 deployment tools (e.g. terraform) managing guardduty state.
automated processes for infrastructure setup may trigger this alert.
automated processes that attempt to authenticate using expired credentials and unbounded retries may lead to false positives.
automated processes that uses terraform may lead to false positives.
automated processes using tools like terraform may trigger this alert.
automated tools or scripts that query for deprecated amis as part of a security assessment.
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 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.
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 administrator legitimately disabling bucket versioning
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 api keys legitimate exchange workflows
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.
aws tasks that require aws account root user credentials https://docs.aws.amazon.com/general/latest/gr/aws_tasks-that-require-root.html
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.
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 changes to a db instance
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.
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.
changes to security groups to allow for new services to be deployed
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 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.
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 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.
confirm if the modification or deletion was part of a planned change or maintenance activity.
creating a lambda function url configuration from unfamiliar users should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
creating a lambda function url configuration may be performed by a system administrator. verify whether the user identity, user agent, and/or hostname should be making changes in your environment.
creation of a new database that needs new security group rules
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.
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.
deletions by unfamiliar users should be investigated. if the behavior is known and expected, it can be exempted from the rule.
dev, uat, sat environment. you should apply this rule with prod account only.
dev, uat, sat environment. you should apply this rule with prod environment only.
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, operators, and ci/cd or automation identities legitimately invoke functions directly for testing, operations, and deployments. new automation roles or first-time operators will generate this alert. verify the principal in `aws.cloudtrail.user_identity.arn`, the function, and the source before treating it as malicious, and exclude known operational identities after validation.
development or deployment pipelines that update static frontends frequently (e.g., react/vue apps) may trigger this. verify the user agent, source ip, and whether the modification was expected.
development or testing environments that simulate external key management scenarios. even in these cases, such activity is typically infrequent and should not add significant noise.
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.
during maintenance operations or testing, authorized administrators may delete s3 buckets as part of routine data management or cleanup activities.
eks cluster being created or deleted may be performed by a system administrator.
eks cluster created or deleted from unfamiliar users should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
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.
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.
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.
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.
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.
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.
getsessiontoken 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. getsessiontoken from unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
getsignintoken events will occur when using aws sso portal to login and will generate false positives if you do not filter for the expected user agent(s), see filter. non-sso configured roles would be abnormal and should be investigated.
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.
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.
glue development endpoint activity may be performed by a system administrator. verify whether the user identity, user agent, and/or hostname should be making changes in your environment.
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.
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.
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.
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 known behavior is causing false positives, it can be exempted from the rule.
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.
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.
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.
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.
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.
lambda layer being attached from unfamiliar users should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
lambda layer being attached may be performed by a system administrator. verify whether the user identity, user agent, and/or hostname should be making changes in your environment.
legitimate administrative actions by authorized system administrators could cause this alert. verify the user identity, user agent, and hostname to ensure they are expected.
legitimate administrative actions by authorized users importing keys for valid purposes.
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 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 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 share an s3 bucket with an external account may be identified as false positives.
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 detector deletion by an admin (e.g., during account decommissioning).
legitimate failed login attempts by authorized users. investigate the source of repeated failed login attempts.
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-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 internal security scanning or key validation that intentionally uses trufflehog. authorize and filter known scanner roles, ip ranges, or assumed roles as needed.
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 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 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 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 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 cases for imported key material are rare, but may include, organizations with hybrid cloud architectures that import external key material for compliance requirements.
legitimate use of acls to enable customer and staff access from the public internet into a public vpc
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 server-side encryption with customer-provided keys (sse-c) to encrypt objects in an s3 bucket.
legitimate use of the enableregion command by authorized administrators.
legitimate use of trufflehog by security teams for credential scanning.
legitimate user account administration
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 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 have to use ssm to perform actions against machines in the cloud to update or maintain them
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.
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.
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.
misconfigured applications or services that rely on deprecated amis for compatibility reasons.
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.
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.
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 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 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 subnets added requiring routing setup
new users or roles may legitimately publish messages to sns topics for authorized purposes. ensure that the action is authorized before taking action.
new vpc creation requiring setup of a new route table
new vpcs and subnets being setup requiring a different security profile to those already defined
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
repurposing of an elb or alb to serve a different or additional application
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.
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.
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 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 being updated from unfamiliar users should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
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.
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, 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.
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.
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 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 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 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.
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 administrator activities
system or network administrator behaviors
task definition being modified to request credentials from the task metadata service for valid reasons
temporary disablement for troubleshooting (verify via change management tickets).
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 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.
there are legitimate uses of ssm to send commands to ec2 instances
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.
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 very uncommon behavior and should result in minimal false positives, ensure validity of the triggered event and include exceptions where necessary.
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 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.
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.
unknown
unlikely
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.
valid change in a trail
valid change in aws config service
valid change in the guardduty (e.g. to ignore internal scanners)
valid change to a snapshot's permissions
valid changes to the startup script
valid usage of s3 browser for iam loginprofile listing and/or creation
valid usage of s3 browser for iam user and/or accesskey creation
valid usage of s3 browser with accidental creation of default inline iam policy without changing default s3 bucket name placeholder value
verify if the modification or deletion was performed by an authorized administrator.
verify the user identity, user agent, and source ip address to ensure they are expected.
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.
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.
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.