LoFP LoFP / t1526

t1526

TitleTags
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 self-hosted runner is automatically removed from github if it has not connected to github actions for more than 14 days.
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, 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).
allowed self-hosted runners changes in the environment.
an ephemeral self-hosted runner is automatically removed from github if it has not connected to github actions for more than 1 day.
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 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.
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.
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
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.
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.
legacy tooling may still be using aad graph. validate and add exceptions on the calling app id after review.
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 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 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.
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.
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.
unknown
unlikely