LoFP LoFP / t1078

t1078

TitleTags
a computer account name change event inmediately followed by a kerberos tgt request with matching fields is unsual. however, legitimate behavior may trigger it. filter as needed.
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 single public ip address servicing multiple legitmate users may trigger this search. in addition, the threshold of 5 distinct users may be too low for your needs. you may modify the included filter macro `multiple_okta_users_with_invalid_credentials_from_the_same_ip_filter` to raise the threshold or except specific ip adresses from triggering this search.
a user may have accidentally entered the wrong credentials during the mfa challenge. if the user is new to mfa, they may have trouble authenticating. ensure that the user is aware of the mfa process and has the correct credentials.
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.
administrative users will likely use powershell commandlets to troubleshoot and maintain the environment. filter as needed.
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 legitimately create azure runbook webhooks. filter as needed.
administrators that use the runas command or scheduled tasks
allowed self-hosted runners changes in the environment.
although not recommended, certain users may be exempt from multi-factor authentication. adjust the filter as necessary.
although not recommended, certain users may be required without multi-factor authentication. filter as needed
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 that uses terraform may lead to false positives.
automation account has been blocked or disabled
automation executing authentication attempts against your splunk infrastructure with outdated credentials may cause false positives.
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.
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. it is recommended to fine-tune okta settings and the analytic to ensure high fidelity. adjust the risk score as necessary.
false positives should be minimal, given the high fidelity of this detection. marker.
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.
fidelity of this is high as it is okta threatinsight. filter and modify as needed.
fidelity of this is high as okta is specifying malicious infrastructure. filter and modify as needed.
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 is possible that a legitimate user is experiencing an issue causing multiple account login failures leading to lockouts.
it is possible that some accounts do not have mfa enabled for the aws account however its agaisnt the best practices of securing aws.
it's possible that a new user will start to modify ec2 instances when they haven't before for any number of reasons. verify with the user that is modifying instances that this is the intended behavior.
it's possible that a user will start to create compute instances for the first time, for any number of reasons. verify with the user launching instances that this is the intended behavior.
it's possible that a widely used system, such as a kiosk, could cause a large number of account lockouts.
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 logon attempts over the internet
legitimate or intentional inbound connections from public ip addresses on the rdp port.
legitimate user wrong password attempts.
legitimate users may miss to reply the mfa challenge within the time window or deny it by mistake.
legtimate administrator actions of adding members from a role
many service accounts configured within a cloud infrastructure are known to exhibit this behavior. please adjust the threshold values and filter out service accounts from the output. always verify if this search alerted on a human user.
many service accounts configured within an aws infrastructure are known to exhibit this behavior. please adjust the threshold values and filter out service accounts from the output. always verify if this search alerted on a human user.
misconfigured systems
multiple failed mfa requests may also be a sign of authentication or application issues. filter as needed.
none.
none. account lockouts should be followed up on to determine if the actual user was the one who caused the lockout, or if it was an unauthorized actor.
not all permanent key creations are malicious. if there is a policy of rotating keys this search can be adjusted to provide better context.
o365 security and compliance may also generate false positives or trigger on legitimate behavior, filter as needed.
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.
renaming a computer account name to a name that not end with '$' is highly unsual and may not have any legitimate scenarios.
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.
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.
there may be a faulty config preventing legitmate users from accessing apps they should have access to.
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 a strictly behavioral search, so we define \"false positive\" slightly differently. every time this fires, it will accurately reflect the first occurrence in the time period you're searching within, plus what is stored in the cache feature. but while there are really no \"false positives\" in a traditional sense, there is definitely lots of noise. this search will fire any time a new ip address is seen in the **geoip** database for any kind of provisioning activity. if you typically do all provisioning from tools inside of your country, there should be few false positives. if you are located in countries where the free version of **maxmind geoip** that ships by default with splunk has weak resolution (particularly small countries in less economically powerful regions), this may be much less valuable to you.
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 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 have tested this detection logic with ~2 million 4769 events and did not identify false positives. however, they may be possible in certain environments. filter as needed.
we recommend investigating the sessions flagged by this detection in the context of other sign-ins from the user.
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.
whenever an admin starts using new features of the admin console.