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 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 may report suspicious activity on their okta account in error.
a user sending emails using personal distribution folders may trigger the event.
account disabled or blocked in error
accounts with high risk roles should be reduced to the minimum number needed, however specific tasks and setups may be simply expected behavior within organization
actual admin using pim.
administrator adding a legitimate temporary access pass
administrator disabling pim alerts as an active choice.
administrator powershell scripts
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 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
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 single endpoint authenticating to a large number of hosts is not common behavior. possible false positive scenarios include but are not limited to vulnerability scanners, jump servers and missconfigured systems.
an single endpoint requesting a large number of computer service tickets is not common behavior. possible false positive scenarios include but are not limited to vulnerability scanners, administration systeams and missconfigured systems.
an single endpoint requesting a large number of kerberos service tickets is not common behavior. possible false positive scenarios include but are not limited to vulnerability scanners, administration systems and missconfigured systems.
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.
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.
attach to policy can create a lot of noise. this search can be adjusted to provide specific values to identify cases of abuse (i.e status=failure). the search can provide context for common users attaching themselves to higher privilege policies or even newly created policies.
attacks using a golden saml or saml assertion hijacks or forgeries are very difficult to detect as accessing cloud providers with these assertions looks exactly like normal access, however things such as source ip sourceipaddress user, and principal targeted at receiving cloud provider along with endpoint credential access and abuse detection searches can provide the necessary context to detect these attacks.
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.
automation account has been blocked or disabled
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.
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.
business travelers who roam to new locations may trigger this alert.
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.
createrole is not very common in common users. this search can be adjusted to provide specific values to identify cases of abuse. in general aws provides plenty of trust policies that fit most use cases.
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.
false positives may be generated by normal provisioning workflows for user device registration.
false positives may occur when users are using a vpn or when users are traveling to different locations.
false positives will be limited to the number of events generated by the analytics tied to the stories. analytics will need to be tested and tuned, and the risk score reduced as needed based on the organization.
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.
gcp oauth token abuse detection will only work if there are access policies in place along with audit logs.
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.
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.
high risk permissions are part of any gcp environment, however it is important to track resource and accounts usage, this search may produce false positives.
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
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 logon attempts over the internet
legitimate or intentional inbound connections from public ip addresses on the smb port.
legitimate user wrong password attempts.
legtimate administrator actions of adding members from a role
misconfigured systems
modifying the kubernetes admission controller may need to be done by a system administrator.
none.
not all permanent key creations are malicious. if there is a policy of rotating keys this search can be adjusted to provide better context.
payload.request.function.timeout value can possibly be match with other functions or requests however the source user and target request account may indicate an attempt to move laterally accross acounts or projects
pim (privileged identity management) generates this event each time 'eligible role' is enabled.
rapid authentication from the same user using more than 5 different user agents and 3 application ids is highly unlikely under normal circumstances. however, there are potential scenarios that could lead to false positives.
saml provider being updated from unfamiliar users should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
service account misconfigured
service accounts may be responsible for the creation, deletion or modification of accounts for legitimate purposes. filter as needed.
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 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.
sts:assumerole can be very noisy as it is a standard mechanism to provide cross account and cross resources access. this search can be adjusted to provide specific values to identify cases of abuse.
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.
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\".
to tune this rule, add exceptions to exclude any event.code which should not trigger this rule.
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 username activity can be due to an engineer logging onto a server instance in order to perform manual troubleshooting or reconfiguration.
unlikely
unlikely. except due to misconfigurations
updating a saml provider or creating a new one may not necessarily be malicious however it needs to be closely monitored.
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
user using a new mail client.
user using a vpn may lead to false positives.
users actually login but miss-click into the deny button when mfa prompt.
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, user agent, and/or hostname should be requesting changes in your environment. password reset attempts 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.