LoFP LoFP / t1528

t1528

TitleTags
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.
administrators using service principal credentials to manage arc-connected clusters during maintenance windows may trigger this rule. correlate with change management records.
authorized third-party applications or services that use the specified client application id to access microsoft graph api resources for legitimate purposes.
automation, ci runners, and platform engineering scripts may legitimately print tokens or dump kubeconfig across providers in one session. baseline approved identities and runner images before tuning thresholds.
carrier-grade nat or load-balanced corporate egress that occasionally routes through alternate asns.
ci/cd pipelines that authenticate as a service principal and then access arc clusters as part of deployment workflows will trigger this rule. identify and exclude known automation service principal app ids.
google's risk engine occasionally flags legitimate sign-ins as suspicious when the user is on a new device, on a vpn egress that geo-resolves to a different region, or after extended time away. validate by checking the user's recent sign-in history and confirming with the user.
initial sso configuration issues or first-time federation setup errors for legitimate users may trigger this detection. temporary federation service outages affecting multiple users simultaneously.
legitimate backup, compliance scanners, or admin scripts that enumerate paths under /home or /var/run/secrets may match. tune by parent process, image, or automation identity.
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 first-time use of a new network: isp change, new vpn provider, travel to a region using a different mobile carrier, new home office.
legitimate use of device code flow where a user authenticates via browser for a cli tool or headless application. common legitimate scenarios include azure cli, azure powershell, or vs code remote development. review the user agent combinations - browser + known cli tool from the same user may be expected behavior.
security researchers, sandbox detonations, or red team engagements that intentionally run the kali365 client against a monitored tenant may generate this user agent. document approved research activity and exclude the associated principals, source ips, or tenants if expected.
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 risk of false positives if there are several containers named the same, as the rule may correlate the request to the wrong container.
this detection is low-volume and is seen infrequently in most organizations. when this detection appears it's high risk, and users should be remediated.
unknown
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.
we recommend investigating the sessions flagged by this detection in the context of other sign-ins from the user.
when and administrator is making legitimate uri configuration changes to an application. this should be a planned event.
when the permission is legitimately needed for the app