You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: src/pentesting-cloud/azure-security/az-basic-information/az-tokens-and-public-applications.md
+78Lines changed: 78 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -38,6 +38,83 @@ Entra ID is Microsoft's cloud-based identity and access management (IAM) platfor
38
38
- Cannot securely authenticate to the authorization server.
39
39
-**Security Implication:** An attacker can impersonate a public client application when requesting tokens, as there is no mechanism for the authorization server to verify the legitimacy of the application.
40
40
41
+
### ROPC / Password Grant
42
+
43
+
The OAuth2 **Resource Owner Password Credentials** (**ROPC**) flow uses a direct `POST` to `https://login.microsoftonline.com/<tenant>/oauth2/v2.0/token` with `grant_type=password`, a **username**, **password**, a **client_id**, and the requested **scope**. In Entra ID this is mainly interesting for **public clients** because the attacker can reuse Microsoft first-party client IDs or any other allowed public client without needing a secret.
44
+
45
+
```bash
46
+
curl -X POST "https://login.microsoftonline.com/<tenant>/oauth2/v2.0/token" \
If the credentials are valid and the flow is allowed, Entra can return **access tokens** and sometimes **refresh tokens** that are immediately usable against Microsoft Graph or the target resource.
57
+
58
+
### Entra ID Sign-In Log Bypass Classes
59
+
60
+
Some historical Entra ID bugs allowed **password validation** or even **full token issuance** without generating the expected **Entra ID sign-in log** entry. These cases were fixed, but the techniques are still useful to understand how auth pipelines can fail in ways that leave **downstream token use visible** while the **upstream sign-in telemetry is absent**.
61
+
62
+
#### 1. Foreign-tenant endpoint for stealth password validation
63
+
64
+
If the request is sent to the token endpoint of a **different tenant GUID**, Entra may still validate whether the submitted password is correct for the supplied username before the flow fails because the user does not exist in that foreign tenant. Historically this allowed:
65
+
66
+
-**Password spraying / credential validation** without a corresponding sign-in log in the victim tenant
67
+
- A response difference that reveals whether the password step succeeded
68
+
- No token issuance, but less telemetry than a normal failed logon
69
+
70
+
#### 2. Force a post-password failure
71
+
72
+
If a parameter used **after** credential validation is invalid, such as an invalid `client_id`, the overall transaction may fail even though the password was already correct. Historically this produced a **failed** login view while hiding that the password guess succeeded.
73
+
74
+
The pattern to remember is:
75
+
76
+
-**Password check succeeds**
77
+
- A later validation step fails
78
+
- The log represents the final transaction state but not the successful password-validation step
79
+
80
+
#### 3. Trigger logging failure with oversized-but-valid values
81
+
82
+
The most dangerous class is when the request remains syntactically valid, authentication succeeds, **tokens are returned**, but some **logged field** is large enough to break the logging pipeline. Reported examples included:
83
+
84
+
- Repeating valid scopes thousands of times, such as `openid openid openid ...`
85
+
- Supplying an excessively long but still accepted **User-Agent** header
86
+
87
+
This suggests a general class of issues where:
88
+
89
+
1. Entra validates credentials and request syntax
90
+
2. The token is issued successfully
91
+
3. Logging attempts to persist a raw user-controlled field
92
+
4. The logging write fails because of length or schema assumptions
93
+
5. The user obtains a valid token with no corresponding sign-in record
94
+
95
+
Example of the repeated-scope pattern:
96
+
97
+
```bash
98
+
curl -X POST "https://login.microsoftonline.com/${TENANT_ID}/oauth2/v2.0/token" \
--data-urlencode "scope=$(for num in {1..10000};doecho -n 'openid '; done)"
106
+
```
107
+
108
+
#### Hunting / defensive note
109
+
110
+
Do not assume that every valid token use will have a matching Entra sign-in event. When investigating suspicious Graph activity, correlate:
111
+
112
+
-**Non-interactive sign-in logs**
113
+
-**Graph Activity Logs**
114
+
-**IP address**, **user/object ID**, **session/correlation identifiers**, and **time windows**
115
+
116
+
One practical validation method is to bracket a suspected invisible success between two normal failed logons and then verify whether the expected sequence `Failed -> Successful -> Failed` is missing the middle event after ingestion delay. If downstream Graph activity exists but the sign-in log does not, treat it as a potential **sign-in logging gap** or **token replay** condition.
117
+
41
118
## Authentication Tokens
42
119
43
120
There are **three types of tokens** used in OIDC:
@@ -566,5 +643,6 @@ From an attackers perspective it's very interesting to know where is it possible
0 commit comments