LoFP LoFP / aws instance

TitleTags
after a new ami is created, the first systems created with that ami will cause this alert to fire. verify that the ami being used was created by a legitimate user.
based on the values of`datapointthreshold` and `deviationthreshold`, the false positive rate may vary. please modify this according the your environment.
it is possible that an admin will create a new system using a new instance type never used before. verify with the creator that they intended to create the system with the new instance type.
it is possible that there are legitimate user roles making new or infrequently used api calls in your infrastructure, causing the search to trigger.
it's likely that you'll find activity detected by users/service accounts that are not listed in the `identity_lookup_expanded` or ` aws_service_accounts.csv` file. if the user is a legitimate service account, update the `aws_service_accounts.csv` table with that entry.
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 has legitimately deleted a network acl.
it's possible that a user has unknowingly started an instance in a new region. please verify that this activity is legitimate.
it's possible that a user will start to create ec2 instances when they haven't before for any number of reasons. verify with the user that is launching instances that this is the intended behavior.
it's possible that an admin has created this acl with all ports open for some legitimate purpose however, this should be scoped and not allowed in production environment.
many service accounts configured with your aws infrastructure are known to exhibit this behavior. please adjust the threshold values and filter out service accounts from the output. always verify whether 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.
many service accounts configured within an aws infrastructure do not have multi factor authentication enabled. please ignore the service accounts, if triggered and instead add them to the aws_service_accounts.csv file to fine tune the detection. it is also possible that the search detects users in your environment using single sign-on systems, since the mfa is not handled by aws.
none.
the false-positive rate may vary based on the values of`datapointthreshold` and `deviationthreshold`. please modify this according the your environment.
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.
using multiple aws accounts and roles is perfectly valid behavior. it's suspicious when an account requests privileges of an account it hasn't before. you should validate with the account owner that this is a legitimate request.
when a legitimate new user logins for the first time, this activity will be detected. check how old the account is and verify that the user activity is legitimate.