LoFP LoFP / t1078

t1078

TitleTags
a legitimate new admin account being created
a non malicious user is unaware of the proper process
a self-hosted runner is automatically removed from github if it has not connected to github actions for more than 14 days.
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 team has configured an ec2 instance to use instance profiles that grant the option for the ec2 instance to talk to other aws services
a user experiencing legitimate login issues (forgotten password, typos) may trigger credential attack alerts before successfully authenticating.
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 may report suspicious activity on their okta account in error.
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.
account disabled or blocked in error
actual admin using pim.
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 adding a legitimate temporary access pass
administrator disabling pim alerts as an active choice.
administrator powershell scripts
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 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 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 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 that use the runas command or scheduled tasks
administrators using service principal credentials to manage arc-connected clusters during maintenance windows may trigger this rule. correlate with change management records.
allowed administrative activities.
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.
an okta admnistrator may be logged into multiple accounts from the same host for legitimate reasons.
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.
application migrations or reconfigurations that switch from certificate/secret authentication to federated credentials will appear as new behavior. confirm with application owners.
applications that are being used as part of automated testing or a legacy application that cannot use any other modern authentication flow
applications that are input constrained will need to use device code flow and are valid authentications.
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 third-party applications or services that use the specified client application id to access microsoft graph api resources for legitimate purposes.
automated password reset flows where a user fails multiple times then succeeds after resetting their password.
automated processes for infrastructure setup may trigger this alert.
automated processes may need to take these actions and may need to be filtered.
automated processes that uses terraform may lead to false positives.
automated processes using tools like terraform may trigger this alert.
automated workflows might assume root to perform periodic administrative tasks.
automation account has been blocked or disabled
aws administrators or automated processes might regularly assume roles for legitimate administrative purposes and to perform periodic tasks such as data backups, updates, or deployments.
aws administrators or automated processes might regularly assume root for legitimate administrative purposes.
aws credentials legitimately shared between github actions and another microsoft/azure service may trigger this rule. verify whether the non-ci/cd source ip is expected for the workload.
aws 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
azure kubernetes admissions controller may be done by a system administrator.
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.
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.
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.
business travelers who roam to new locations may trigger this alert.
carrier-grade nat or load-balanced corporate egress that occasionally routes through alternate asns.
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.
connecting to a vpn, performing activity and then dropping and performing additional activity.
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.
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.
custom network security rules that triggers on a proxy or gateway used by users to access azure or o365.
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.
deletions by unfamiliar users should be investigated. if the behavior is known and expected, it can be exempted from the rule.
developers may leverage third-party applications for legitimate purposes in google workspace such as for administrative tasks.
developers testing new applications or oauth flows in non-production tenants may generate alerts during development cycles.
false positives may occur when users are using a vpn or when users are traveling to different locations for legitimate purposes.
federation settings being modified or deleted may be performed by a system administrator.
federation settings modified from unfamiliar users 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.
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 cloud kubernetes admission controller may be done by a system administrator.
google workspace administrators may renew a suspended user account if the user is expected to continue employment at the organization after temporary leave. suspended user accounts are typically used by administrators to remove access to the user while actions is taken to transfer important documents and roles to other users, prior to deleting the user account and removing the license.
google's risk engine occasionally flags legitimate sign-ins as suspicious when the user is on a new device, on a vpn egress that geo-resolves to a different region, or after extended time away. validate by checking the user's recent sign-in history and confirming with the user.
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.
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.
if known behavior is causing false positives, it can be exempted from the rule.
if this was approved by system administrator or confirmed user action.
if this was approved by system administrator.
increase of users in the environment
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.
investigate if licenses have expired.
investigate if potential generic account that cannot be removed.
investigate if threshold setting in pim is too low.
investigate if user is performing mfa at sign-in.
investigate where if active time period for a role is set too short.
investigate where users are being assigned privileged roles outside of privileged identity management and prohibit future assignments from there.
ipv4-to-ipv6 mapped ips
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.
known legacy accounts
legit administrative action
legit administrative pim setting configuration changes
legitimate administration activities
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 administrative tasks modifying these attributes.
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 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 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 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 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 logins
legitimate logon attempts over the internet
legitimate or intentional inbound connections from public ip addresses on the rdp port.
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 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 user wrong password attempts.
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.
legtimate administrator actions of adding members from a role
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.
misconfigured systems
mobile access may also result in false positives, as users may log in from various locations while on the go.
modifying the kubernetes admission controller may need to be done by a system administrator.
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 legitimate applications or integrations recently deployed in the environment may trigger this detection during initial setup or rollout phases.
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 workload identity federation configurations for legitimate automation will trigger on first use.
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.
pim (privileged identity management) generates this event each time 'eligible role' is enabled.
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.
role chaining can be used as an access control. ensure that this behavior is not part of a legitimate operation 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 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 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 testing or red team exercises using proxy infrastructure.
service account misconfigured
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.
shared or reused service principal secrets across teams may register as new paths when first used from another site.
shared systems such as kiosks and conference room computers may be used by multiple users.
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.
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 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.
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.
third-party saas applications with sharepoint integration may appear as new app ids when users first authorize access.
this detection cloud be noisy depending on the environment. it is recommended to keep a check on the new secrets when created and validate the \"actor\".
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 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 may trigger in cases where a user has routine work patterns that result in infrequent authentications.
to tune this rule, add exceptions to exclude any event.code which should not trigger this rule.
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.
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 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.
unknown
unlikely
unlikely. except due to misconfigurations
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 changing to a new device, location, browser, etc.
user has been put in acception group so they can use legacy authentication
user using a disabled account
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 actually login but miss-click into the deny button when mfa prompt.
users authenticating from multiple devices and using the devicecode protocol or the visual studio code client.
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 may share an endpoint related to work or personal use in which separate okta accounts are used.
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 working late, or logging in from unusual time zones while traveling, may trigger this rule.
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 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.
vulnerability scanners
we recommend investigating the sessions flagged by this detection in the context of other sign-ins from the user.
when an admin begins using the admin console and one of okta's heuristics incorrectly identifies the behavior as being unusual.
when and administrator is making legitimate appid uri configuration changes to an application. this should be a planned event.
when and administrator is making legitimate uri configuration changes to an application. this should be a planned event.