Entra script client sign-in
A human user account authenticating through a scripting client — python-requests, curl, a bare HTTP library — rather than a browser or a mail client.
What it detects
A human user account authenticating through a scripting client — python-requests, curl, a bare HTTP library — rather than a browser or a mail client.
People use apps; scripts use libraries. When an account that has always signed in from Outlook and a browser suddenly authenticates as python-requests/2.31, the credential is being driven by code. That is the normal shape of a compromised account being automated, and of the tooling that follows a successful phish.
WinHttp was deliberately left OUT of the list. It is a scripting-adjacent stack and would widen the net, but legitimate Microsoft first-party components use it, so it would fire on ordinary tenant traffic. It matched nothing in the attack corpus, so there is no evidence it buys detection — only cost.
This is the sibling of the named-tool rule: that one catches clients that identify themselves as attack tools, and this one catches the generic libraries those tools are built from and that custom scripts use.
MITRE ATT&CK mapping
False positives and triage
Automation is legitimate and common: integrations, backup tools, monitoring and in-house scripts all authenticate this way, and in most tenants a handful of accounts do it constantly. That is why this is medium — the useful signal is a HUMAN account doing it for the first time, not the existence of scripted access. Allowlist the service accounts that are supposed to behave this way rather than raising the threshold, and check whether the same account also signs in interactively from a browser; an account that does both is either a person running a script or an attacker using a person's credential, and the timing usually says which.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 55%. Source: rules/cloud/entra_script_client_signin.yaml, licensed under the Apache License 2.0.
id: cloud.identity.entra_script_client_signin
version: 1.0.0
status: stable
severity: medium
confidence: 0.55
platforms: [application]
mitre_techniques: [T1078.004, T1071.001]
description: |
A human user account authenticating through a scripting client — python-requests,
curl, a bare HTTP library — rather than a browser or a mail client.
People use apps; scripts use libraries. When an account that has always signed in
from Outlook and a browser suddenly authenticates as `python-requests/2.31`, the
credential is being driven by code. That is the normal shape of a compromised
account being automated, and of the tooling that follows a successful phish.
`WinHttp` was deliberately left OUT of the list. It is a scripting-adjacent stack
and would widen the net, but legitimate Microsoft first-party components use it,
so it would fire on ordinary tenant traffic. It matched nothing in the attack
corpus, so there is no evidence it buys detection — only cost.
This is the sibling of the named-tool rule: that one catches clients that identify
themselves as attack tools, and this one catches the generic libraries those tools
are built from and that custom scripts use.
match:
event_category: authentication
user_agent_contains_any:
- "python-requests"
- "python-urllib"
- "curl/"
- "Wget/"
- "Go-http-client"
- "okhttp"
- "axios/"
- "PostmanRuntime"
correlation_keys: [user_name, source_ip]
false_positive_guidance: |
Automation is legitimate and common: integrations, backup tools, monitoring and
in-house scripts all authenticate this way, and in most tenants a handful of
accounts do it constantly. That is why this is medium — the useful signal is a
HUMAN account doing it for the first time, not the existence of scripted access.
Allowlist the service accounts that are supposed to behave this way rather than
raising the threshold, and check whether the same account also signs in
interactively from a browser; an account that does both is either a person running
a script or an attacker using a person's credential, and the timing usually says
which.
Related detections
Run this rule on your own logs — offline
KIROSEC runs this rule and the rest of the library over Windows, Linux, macOS and cloud audit logs on the analyst's own machine. Every alert links to the events that raised it, and nothing leaves the device.