LoFP LoFP / t1539

t1539

TitleTags
a user running azure cli, azure powershell, vs code, graph cli, or visual studio on a jump host, cloud shell, or vpn egress that differs from the workstation's windows sign-in ip can match if that activity still presents a compliant or managed workstation deviceid. validate whether the graph client ran on the enrolled device before treating the event as cookie theft.
a user who runs azure cli, azure powershell, vs code, graph cli, or visual studio from a new egress (vpn, hotel, cloud shell, jump host) while wam still attaches a compliant or managed workstation deviceid will match on first sight of that ip. exception: add known developer and cloud shell ranges after confirming the client ran there.
applications will tag the operating system as null when the device is not recognized as a managed device. in environments where users frequently switch between managed and unmanaged devices, this may lead to false positives.
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.
developers performing browsers plugin or extension debugging.
legitimate automation, sdks, or custom applications that obtain tokens through the microsoft authentication broker against graph, azure ad, or device registration service may use non-browser user agents. baseline approved service principals, managed identities, and developer tooling before tuning exclusions for known automation patterns.
legitimate node.js or undici-based automation, health checks, or internal services that use the microsoft authentication broker or the same first-party application ids against graph or exchange may match. developers using axios or undici with delegated flows can also resemble this pattern.
legitimate users may appear in multiple countries within the window when using vpns or proxies with exit nodes in different countries, when traveling near borders, or when mobile networks geolocate to different countries. verify the source ips and asns in \"esql.source_ip_values\", confirm whether the locations are consistent with the user's expected activity, and exclude known vpn egress patterns after validation. shared iam users (an anti-pattern) used by multiple people will also match.
legitimate webproxy settings modification
microsoft teams, microsoft office, onedrive syncengine, microsoft authentication broker, outlook mobile, bing, azure portal, adibizaux, and office 365 management are omitted. the rest of the secureworks known-foci-clients.csv family (edge, onedrive, intune company portal, windows search, authenticator, sharepoint, planner, power bi, and similar) is omitted for the same reason: routine workstation or mobile graph whose microsoft 365 egress often differs from the windows sign-in ip without cookie theft. hunt those app_ids separately if harvest is already confirmed.
microsoft teams, office, onedrive syncengine, authentication broker, outlook mobile, bing, azure portal, and office 365 management are omitted because first sight of a mobile or m365 egress ip for those clients is routine.
mobile users switching between wifi and cellular may show ip address changes. correlate with device type and typical user behavior patterns.
split-tunnel or dual-homed devices can present a new microsoft 365 egress for tooling clients. confirm the ip belongs to the enrolled device before treating the event as cookie theft.
split-tunnel or dual-homed devices may present different egress ips for wam versus azure cli. confirm both ips belong to the same physical device before raising severity.
unknown
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.