LoFP LoFP / t1580

t1580

TitleTags
a newly installed program or one that runs very rarely as part of a monthly or quarterly workflow could trigger this detection rule.
administrators listing buckets, it may be necessary to filter out users who commonly conduct this activity.
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.
automated tools or scripts that query for deprecated amis as part of a security assessment.
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
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.
it is possible to start this detection will need to be tuned by source ip or user. in addition, change the count values to an upper threshold to restrict false positives.
legitimate administrative or security assessment activities may use these user-agents, especially in environments where teamfiltration is employed for authorized audits. if this is expected behavior, consider adjusting the rule or adding exceptions for specific user-agents or ip addresses.
legitimate 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 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 use of deprecated amis for testing or development purposes.
legitimate use of the `describeinstances` api call by an aws resource that requires information about instances in multiple regions.
legitimate users may encounter multiple failures during permission testing, role transitions, or when service permissions are being reconfigured. high volumes of api errors may also occur during automated processes with misconfigured iam policies or when new bedrock features are being explored through api testing.
misconfigured applications or services that rely on deprecated amis for compatibility reasons.
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 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.
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.
scheduled tasks or scripts that require information about instances in multiple regions.
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.
this detection will require tuning to provide high fidelity detection capabilties. tune based on src addresses (corporate offices, vpn terminations) or by groups of users.