LoFP LoFP / t1098

t1098

TitleTags
a domain may be transferred to another aws account by a system or network administrator. verify whether the user identity, user agent, and/or hostname should be making changes in your environment. domain transfers from unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
a domain transfer lock may be disabled by a system or network administrator. verify whether the user identity, user agent, and/or hostname should be making changes in your environment. activity from unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
a new role may be assigned to a management group by a system or network administrator. verify that the configuration change was expected. exceptions can be added to this rule to filter expected behavior.
a private hosted zone may be asssociated with a vpc by a system or network administrator. verify whether the user identity, user agent, and/or hostname should be making changes in your environment. if known behavior is causing false positives, it can be exempted from the rule.
a service principal name should only be added to an account when an application requires it. while infrequent, this detection may trigger on legitimate actions. filter as needed.
adding user keys to their own accounts (the filter cannot cover all possible variants of user naming)
adding users to a specified group may be done by a system or network administrator. verify whether the user identity, user agent, and/or hostname should be making changes in your environment. user additions from unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
administrative activity
administrative activity that must be investigated
administrator may legitimately add new owners for service principals. filter as needed.
administrator or network operator can create file in ~/.ssh folders for automation purposes. please update the filter macros to remove false positives.
administrator or network operator can use this commandline for automation purposes. please update the filter macros to remove false positives.
administrator roles could be assigned to users or group by other admin users.
administrator roles may be assigned to okta users by a super admin user. verify that the behavior was expected. exceptions can be added to this rule to filter expected behavior.
administrators may legitimately assign the application administrator role to a user. filter as needed.
administrators may legitimately assign the privileged roles to service principals as part of administrative tasks. filter as needed.
administrators may upload ssh public keys to ec2 instances for legitimate purposes.
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 will legitimately assign the privileged roles users as part of administrative tasks. filter as needed.
application owners may be added for legitimate reasons, filter as needed.
approved activity performed by an administrator.
as part of legitimate administrative behavior, users may activate pim roles. filter as needed
as part of legitimate administrative behavior, users may be assigned pim roles. filter as needed
assignment of rights to a service account.
automated workflows might assume root to perform periodic administrative tasks.
aws administrators or automated processes might regularly assume root for legitimate administrative purposes.
aws api keys legitimate exchange workflows
aws iam roles anywhere trust anchors are legitimate profiles that can be created by administrators to allow access from any location. ensure that the trust anchor is created by a legitimate administrator and that the external certificate authority is authorized.
aws roles anywhere profiles are legitimate profiles that can be created by administrators to allow access from any location. ensure that the profile created is expected and that the trust policy is configured securely.
aws services might assume root to access aws resources as part of their standard operations.
business approved changes by known administrators.
consider adding exceptions to this rule to filter false positives if the mfa factors for okta user accounts are regularly reset in your organization.
custom google workspace admin roles may be created by system administrators. verify that the configuration change was expected. exceptions can be added to this rule to filter expected behavior.
disaster recovery events.
domain-wide delegation of authority may be granted to service accounts by system administrators. verify that the configuration change was expected. exceptions can be added to this rule to filter expected behavior.
fullaccess mailbox delegation may be assigned for legitimate purposes, filter as needed.
genuine activity
global administrator additions may be done by a system or network administrator. verify whether the username, hostname, and/or resource name should be making changes in your environment. global administrator additions from unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
google workspace admin role assignments may be modified by system administrators. verify that the configuration change was expected. exceptions can be added to this rule to filter expected behavior.
google workspace admin role privileges, may be modified by system administrators.
google workspace admin roles may be modified by system administrators. verify that the configuration change was expected. exceptions can be added to this rule to filter expected behavior.
google workspace administrators may adjust change which organizational unit a user belongs to as a result of internal role adjustments.
initial installation of a domain controller.
it is possible that the user has legitimately added a new device to their account. please verify this activity.
legitimate administrative activities
legitimate administrative activities changing the access levels for an application
legitimate administrative script
legitimate applications may be granted tenant wide consent, filter as needed.
legitimate exchange system administration activity.
legitimate extension of domain structure
legitimate remote account administration.
legitimate user account administration
legitimate user activity.
legtimate administrator actions of removing members from a role
mailbox folder permissions may be configured for legitimate purposes, filter as needed.
master password change is a legitimate means to regain access to a db instance in the case of a lost password. ensure that the instance should not be modified in this way before taking action.
new domain controller computer account, check user sids within the value attribute of event 5136 and verify if it's a regular user or dc computer account.
new members can be added to the dnsadmins group as part of legitimate administrative tasks. filter as needed.
password policies may be modified by system administrators. verify that the configuration change was expected. exceptions can be added to this rule to filter expected behavior.
pim (privileged identity management) generates this event each time 'eligible role' is enabled.
privilege roles may be assigned for legitimate purposes, filter as needed.
resetting the dsrm password for legitamate reasons, i.e. forgot the password. disaster recovery. deploying ad backdoor deliberately.
service account key deletions 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. key deletions by unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
service account keys may be created by system administrators. verify that the configuration change was expected. exceptions can be added to this rule to filter expected behavior.
service accounts may be responsible for the creation, deletion or modification of accounts for legitimate purposes. filter as needed.
service principal client credential modifications may be part of legitimate administrative operations. filter as needed.
teams external access may be enabled by a system or network administrator. verify that the configuration change was expected. exceptions can be added to this rule to filter expected behavior.
teams guest access may be enabled by a system or network administrator. verify that the configuration change was expected. exceptions can be added to this rule to filter expected behavior.
the sourceanchor (also called immutableid) azure ad attribute has legitimate uses for directory synchronization. investigate and filter as needed.
there are legitimate scenarios in wich an application registrations requires mailbox read access. filter as needed.
this detection will require tuning to provide high fidelity detection capabilties. tune based on src addresses (corporate offices, vpn terminations) or by groups of users. not every user with aws access should have permission to delete policies (least privilege). in addition, this may be saved seperately and tuned for failed or success attempts only.
user accounts can be used as service accounts and have their password set never to expire. this is a bad security practice that exposes the account to credential access attacks. for cases in which user accounts cannot be avoided, microsoft provides the group managed service accounts (gmsa) feature, which ensures that the account password is robust and changed regularly and automatically.
user group access may be modified by an administrator to allow external access for community purposes. doing so for a user group whom has access to sensitive information or operational resources should be monitored closely.
users may register mfa methods legitimally, investigate and filter as needed.
valid change
validate the actor if permitted to access the repo.
validate the multifactor authentication changes.
we recommend investigating the sessions flagged by this detection in the context of other sign-ins from the user.
when an admin creates a new, authorised identity provider.
when credentials are added/removed as part of the normal working hours/workflows
when remote authentication is in place, this should not change often
when the permission is legitimately needed for the app
while infrequent, the applicationimpersonation role may be granted for leigimate reasons, filter as needed.
while not common, administrators may enable accounts and reset their passwords for legitimate reasons. filter as needed.
while there are legitimate scenarios for these permissions, such as an executive assistant needing access to an executive's mailbox, there are also malicious scenarios. investigate and filter as needed.
while this can be normal behavior, it should be investigated to ensure validity. verify whether the user identity should be using the iam `attachrolepolicy` api operation to attach the `administratoraccess` policy to the target role.