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. adding an spn and quickly deleting it is less common but may be part of legitimate action. 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 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 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.
application owners may be added for legitimate reasons, filter as needed.
approved activity performed by an administrator.
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.
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.
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.
legitimate administrative activities
legitimate administrative activities changing the access levels for an application
legitimate administrative script
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
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.
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.
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.
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.
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 not common, administrators may enable accounts and reset their passwords for legitimate reasons. 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 `createaccesskey` for the targeted user.