LoFP LoFP / t1550

t1550

TitleTags
a user may have multiple sessions open at the same time, such as on a mobile device and a laptop.
administrative or automated tasks that involve accessing microsoft graph api using the specified client application id and tenant id, such as provisioning or managing resources.
administrator activity
application migrations or reconfigurations that switch from certificate/secret authentication to federated credentials will appear as new behavior. confirm with application owners.
assumerole from unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
assumerole 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.
authorized third-party applications or services that use the specified client application id to access microsoft graph api resources for legitimate purposes.
automated integrations or scripts using service accounts with session cookies may trigger user-agent based detection. consider excluding known automation accounts by okta.actor.alternate_id.
automated processes that uses terraform may lead to false positives.
aws administrators or automated processes might regularly assume roles for legitimate administrative purposes. aws services might assume roles to access aws resources as part of their standard operations. automated workflows might assume roles to perform periodic tasks such as data backups, updates, or deployments.
creating specific groups via the exchange online powershell module will make exchange use an actor token on your behalf. the rule excludes group operations and directory feature operations to reduce false positives from these legitimate administrative activities.
custom applications may leverage the kerberos protocol. filter as needed.
developers may leverage third-party applications for legitimate purposes in google workspace such as for administrative tasks.
environments that use ntlmv1
getsessiontoken is widely used by legitimate automation, cli users, and administrative scripts to acquire temporary credentials. frequent, authorized usage is expected in most environments, especially where iam users authenticate with mfa or use short-lived tokens. review iam and ci/cd users, sdks, and service accounts that regularly perform this action and document them in an allowlist. suppress or tune accordingly to reduce noise.
getsessiontoken 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. getsessiontoken from unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
getsignintoken events will occur when using aws sso portal to login and will generate false positives if you do not filter for the expected user agent(s), see filter. non-sso configured roles would be abnormal and should be investigated.
go utilities that use staaldraad awesome ntlm library
http traffic on a non standard port. verify that the destination ip address is not related to a domain controller.
if key credentials are regularly assigned to users, these events will need to be tuned out.
legacy hosts
legitimate device registrations using microsoft authentication broker may occur during corporate enrollment scenarios or bulk provisioning, but it is uncommon for multiple source ips to register the same identity across microsoft graph, device registration service (drs), and azure active directory (aad) in a short time span.
legitimate federation workflows, admin portals, sso helpers, ci/cd jobs, or internal scripts that create one-click console links, commonly invoke getsignintoken and may generate frequent benign events.
legitimate remote administration activity
legitimate users may encounter access denied errors during permission testing, role transitions, or when service permissions are being reconfigured. access denials may also happen when automated processes are using outdated credentials or when new bedrock features are being explored.
mobile users switching between wifi and cellular may show ip address changes. correlate with device type and typical user behavior patterns.
new ci/cd pipeline deployments using github actions, azure devops, or kubernetes oidc will trigger this rule when federated authentication is first used. validate the issuer url against approved identity providers.
new workload identity federation configurations for legitimate automation will trigger on first use.
role chaining can be used as an access control. ensure that this behavior is not part of a legitimate operation before taking action.
runas command-line tool using /netonly parameter
saml provider being updated from unfamiliar users should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
there is a potential for false positives if the access to the service account token or certificate is used for legitimate purposes, such as debugging or troubleshooting. it is important to investigate any alerts generated by this rule to determine if they are indicative of malicious activity or part of legitimate container activity.
there is a potential for false positives if the direct interactive kubernetes api requests are used for legitimate purposes, such as debugging or troubleshooting. it is important to investigate any alerts generated by this rule to determine if they are indicative of malicious activity or part of legitimate container activity.
there is a risk of false positives if there are several containers named the same, as the rule may correlate the request to the wrong container.
this is very uncommon behavior and should result in minimal false positives, ensure validity of the triggered event and include exceptions where necessary.
this pattern may occur during legitimate device switching or roaming between networks (e.g., corporate to mobile). developers or power users leveraging multiple environments may also trigger this detection if session persistence spans ip ranges. still, this behavior is rare and warrants investigation when rapid ip switching and graph access are involved.
unlikely
users authenticating from multiple devices and using the devicecode protocol or the visual studio code client.
users legitimately accessing microsoft graph api using the specified client application id and tenant id. this may include authorized applications or services that interact with microsoft graph on behalf of users.
users legitimately switching networks (e.g., vpn connect/disconnect, office to home) may trigger ip-based detection. review the geographic distance and time between ip changes to assess legitimacy.
web browsers and third party application might generate similar activity. an initial baseline is required.