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 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 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.
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.
aws api keys legitimate exchange workflows
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.
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.
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 groups (least privilege).
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.