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
OAuth authorization code phishing is a technique where an attacker abuses the OAuth authorization code flow to obtain authorization codes generated during a legitimate authentication process. In Microsoft Entra ID environments, an attacker can craft a malicious authorization request and distribute it through phishing or social engineering to convince a victim to initiate the OAuth authentication flow. After the victim successfully authenticates and grants consent, the identity provider issues an authorization code and redirects the user’s browser to the specified redirect URI. If the attacker obtains this authorization code before it is redeemed by the intended client application, they can exchange it at the token endpoint to obtain an access token representing the victim’s identity, allowing access to APIs and services such as Microsoft Graph or Azure Resource Manager depending on the granted permissions.
17
+
OAuth authorization code phishing is a technique where an attacker abuses the
18
+
OAuth authorization code flow to obtain authorization codes generated during a
19
+
legitimate authentication process. In Microsoft Entra ID environments, an
20
+
attacker can craft a malicious authorization request and distribute it through
21
+
phishing or social engineering to convince a victim to initiate the OAuth
22
+
authentication flow.
23
+
24
+
25
+
After the victim successfully authenticates and grants consent, the identity
26
+
provider issues an authorization code and redirects the user’s browser to the
27
+
specified redirect URI. If the attacker obtains this authorization code before
28
+
it is redeemed by the intended client application, they can exchange it at the
29
+
token endpoint to obtain an access token representing the victim’s identity,
30
+
allowing access to APIs and services such as Microsoft Graph or Azure Resource
31
+
Manager depending on the granted permissions.
18
32
19
33
## Technical Background
20
34
21
35
22
36
### OAuth
23
37
24
-
OAuth is a foundational protocol used by modern identity platforms to enable **secure authorization between users and applications**. It allows a user to grant an application limited access to resources without sharing credentials directly with the application.
38
+
OAuth is a foundational protocol used by modern identity platforms to enable
39
+
**secure authorization between users and applications**. It allows a user to
40
+
grant an application limited access to resources without sharing credentials
41
+
directly with the application.
25
42
26
-
Instead of providing a password, the identity provider authenticates the user and issues **tokens that represent the user’s authorized permissions**. These tokens can then be used by the application to access APIs on behalf of the user.
43
+
Instead of providing a password, the identity provider authenticates the user
44
+
and issues **tokens that represent the user’s authorized permissions**. These
45
+
tokens can then be used by the application to access APIs on behalf of the user.
27
46
28
-
In Microsoft Entra ID environments, OAuth is commonly used to authorize applications to access services such as:
47
+
In Microsoft Entra ID environments, OAuth is commonly used to authorize
48
+
applications to access services such as:
29
49
30
50
- Microsoft Graph
31
51
- Azure Resource Manager
32
52
- Exchange Online
33
53
- SharePoint
34
54
35
-
This model allows applications to access resources while authentication and authorization decisions remain centralized within the identity provider.
55
+
This model allows applications to access resources while authentication and
56
+
authorization decisions remain centralized within the identity provider.
36
57
37
58
---
38
59
39
60
### OAuth Authorization Code Flow
40
61
41
-
One of the most common OAuth implementations is the **Authorization Code Flow**. This flow is designed for applications that can securely perform server-side communication with the identity provider.
62
+
One of the most common OAuth implementations is the **Authorization Code Flow**.
63
+
This flow is designed for applications that can securely perform server-side
64
+
communication with the identity provider.
42
65
43
-
In this model, the client application redirects the user to the identity provider for authentication. After the user successfully authenticates and grants consent, the identity provider issues a temporary **authorization code**. The client application then exchanges this code for an **access token**.
66
+
In this model, the client application redirects the user to the identity
67
+
provider for authentication. After the user successfully authenticates and
68
+
grants consent, the identity provider issues a temporary **authorization code**.
69
+
The client application then exchanges this code for an **access token**.
44
70
45
71
```
46
72
User
@@ -66,13 +92,15 @@ Access Token
66
92
API (Graph / Gmail / Slack)
67
93
```
68
94
69
-
The authorization code is designed to be **short-lived** and is intended to be redeemed only by the client application that initiated the request.
95
+
The authorization code is designed to be **short-lived** and is intended to be
96
+
redeemed only by the client application that initiated the request.
70
97
71
98
---
72
99
73
100
### Authorization Endpoint
74
101
75
-
The authorization flow begins when the client application directs the user’s browser to the identity provider’s **authorization endpoint**.
102
+
The authorization flow begins when the client application directs the user’s
103
+
browser to the identity provider’s **authorization endpoint**.
76
104
77
105
In Microsoft Entra ID, this endpoint typically appears as:
After the user authenticates and grants consent, the identity provider redirects the browser to the specified `redirect_uri`, including the authorization code as a parameter.
131
+
After the user authenticates and grants consent, the identity provider redirects
132
+
the browser to the specified `redirect_uri`, including the authorization code as
133
+
a parameter.
104
134
105
135
---
106
136
107
137
### Redirect URI Behavior
108
138
109
-
The **redirect URI** defines where the authorization server sends the authorization code after authentication.
139
+
The **redirect URI** defines where the authorization server sends the
140
+
authorization code after authentication.
110
141
111
-
The authorization code is delivered through a browser redirect and typically appears in the query parameters of the redirected URL.
142
+
The authorization code is delivered through a browser redirect and typically
143
+
appears in the query parameters of the redirected URL.
The client application is expected to receive this authorization code and immediately exchange it with the identity provider's token endpoint.
151
+
The client application is expected to receive this authorization code and
152
+
immediately exchange it with the identity provider's token endpoint.
120
153
121
154
In some cases, redirect URIs may reference local addresses such as:
122
155
123
156
```
124
157
http://localhost:3000/
125
158
```
126
159
127
-
When the redirect URI points to a local host that is not actively running the client application, the OAuth authorization flow cannot complete normally. However, the identity provider may still generate the authorization code and include it in the redirected URL.
160
+
When the redirect URI points to a local host that is not actively running the
161
+
client application, the OAuth authorization flow cannot complete normally.
162
+
However, the identity provider may still generate the authorization code and
163
+
include it in the redirected URL.
128
164
129
-
This behavior can expose the authorization code within the browser session prior to it being redeemed by a client application.
165
+
This behavior can expose the authorization code within the browser session prior
166
+
to it being redeemed by a client application.
130
167
131
168
---
132
169
133
170
### Token Exchange
134
171
135
-
Once the client receives the authorization code, it sends a request to the identity provider’s **token endpoint** to exchange the code for an access token.
172
+
Once the client receives the authorization code, it sends a request to the
173
+
identity provider’s **token endpoint** to exchange the code for an access token.
136
174
137
175
In Microsoft Entra ID, the token endpoint typically appears as:
If the request is valid, the identity provider issues an **access token** representing the authenticated user and the permissions granted during the authorization request.
181
+
If the request is valid, the identity provider issues an **access token**
182
+
representing the authenticated user and the permissions granted during the
183
+
authorization request.
144
184
145
-
The client application can then use this token to access APIs such as Microsoft Graph.
185
+
The client application can then use this token to access APIs such as Microsoft
186
+
Graph.
146
187
147
188
---
148
189
149
190
### First-Party Applications
150
191
151
-
Microsoft Entra ID includes a number of **first-party applications**, which are applications developed and maintained by Microsoft.
192
+
Microsoft Entra ID includes a number of first-party applications, which are
193
+
applications developed and maintained by Microsoft.
152
194
153
-
These applications are often pre-registered and trusted within enterprise environments. As a result, authorization requests associated with these applications may appear more legitimate to users and administrators during OAuth authorization flows.
195
+
These applications are often pre-registered and inherently trusted within
196
+
enterprise environments. Because of this, they typically already have
197
+
established permissions and do not require the same user consent experience as
198
+
newly registered third-party applications.
154
199
155
-
Understanding the behavior of first-party applications is important when analyzing OAuth authorization patterns within Microsoft Entra ID environments.
200
+
In the context of this technique, first-party applications play a critical role
201
+
by removing the need for a traditional consent prompt. Instead of convincing a
202
+
user to approve a malicious application, an attacker can leverage an existing
203
+
trusted application and initiate the OAuth authorization flow directly.
204
+
205
+
As a result, the interaction appears legitimate, and the user is not presented
206
+
with a suspicious consent screen. This allows the attack to bypass the consent
207
+
phase entirely and focus on capturing the authorization code during the
208
+
authentication process.
209
+
210
+
Understanding the behavior and trust model of first-party applications is
211
+
important when analyzing OAuth authorization patterns within Microsoft Entra ID
212
+
environments, as they can be leveraged to make malicious activity appear
213
+
indistinguishable from normal authentication flows.
156
214
157
215
158
216
## Procedures
@@ -163,9 +221,14 @@ Understanding the behavior of first-party applications is important when analyzi
163
221
164
222
### Procedure A: ConsentFix
165
223
166
-
In this procedure, the attacker abuses the OAuth authorization code flow in Microsoft Entra ID by manipulating the authorization request and redirect behavior in order to obtain the authorization code generated during the authentication process.
224
+
In this procedure, the attacker abuses the OAuth authorization code flow by
225
+
manipulating the authorization request and redirect behavior in order to obtain
226
+
the authorization code generated during the authentication process.
167
227
168
-
The attacker crafts an OAuth authorization request directed at the Microsoft identity platform authorization endpoint. This request contains parameters defining the client application, requested scopes, and the redirect URI where the authorization code will be returned.
228
+
The attacker crafts an OAuth authorization request directed at the Microsoft
229
+
identity platform authorization endpoint. This request contains parameters
230
+
defining the client application, requested scopes, and the redirect URI where
The attacker then delivers this request to the victim through a phishing page or social engineering technique designed to encourage the victim to initiate the OAuth authentication process.
245
+
The attacker then delivers this request to the victim through a phishing page or
246
+
other social engineering technique designed to encourage the victim to initiate
247
+
the OAuth authentication process.
183
248
184
-
When the victim follows the link, the Microsoft identity platform processes the request and prompts the user to authenticate. After successful authentication and consent, the identity provider generates an authorization code and redirects the browser to the specified redirect URI.
249
+
When the victim follows the link, the identity provider (IdP) processes the
250
+
authorization request and prompts the user to authenticate. Upon successful
251
+
authentication and consent, the IdP generates an authorization code and
252
+
redirects the browser to the specified redirect URI.
185
253
186
-
Because the redirect URI references a local address such as `localhost`, the OAuth flow cannot complete normally. However, the redirect still occurs and the authorization code is included in the URL returned to the browser.
254
+
The attacker intentionally specifies a redirect URI that points to a local or
255
+
unreachable destination (such as localhost). Because no legitimate client
256
+
application is available to receive and redeem the authorization code, the OAuth
257
+
flow cannot complete as intended.
187
258
188
-
Example redirect:
259
+
However, the redirect still occurs, and the authorization code is included in
260
+
the URL returned to the browser.
189
261
190
-
```
191
-
http://localhost:3000/?code=AUTHORIZATION_CODE
192
-
```
262
+
Example redirect:
193
263
194
-
The attacker then obtains the authorization code from the victim and redeems it at the token endpoint. Once redeemed, the identity provider issues an access token representing the victim’s identity and the permissions granted during the authorization request.
264
+
`http://localhost:3000/?code=AUTHORIZATION_CODE`
195
265
196
-
The attacker can then use this access token to access APIs such as Microsoft Graph or Azure Resource Manager depending on the scopes granted during the authorization process.
266
+
At this stage, the authorization code is exposed within the browser context. The
267
+
attacker then uses social engineering to convince the victim to copy and share
268
+
the URL or the authorization code itself, often under the pretense of
269
+
troubleshooting or completing the sign-in process.
197
270
198
-
#### Detection Data Model
271
+
Once the attacker obtains the authorization code, they redeem it at the token
272
+
endpoint of the IdP. The IdP validates the authorization code and, if valid,
273
+
issues an access token representing the victim’s identity and granted
274
+
permissions.
199
275
276
+
The attacker can then use this access token to access protected resources and
277
+
APIs, depending on the scopes granted during the authorization process.
200
278
201
-
```mermaid
202
-
flowchart LR
203
-
U[User]
204
-
AR[OAuth Authorization Request]
205
-
AS[Microsoft Authorization Endpoint]
206
-
AC[Authorization Code]
207
-
TE[Token Endpoint]
208
-
AT[Access Token]
209
-
API[Azure API / Microsoft Graph]
210
-
211
-
PX[Proxy Telemetry]
212
-
AZ[Entra Sign-In Logs]
213
-
214
-
U --> AR
215
-
AR --> AS
216
-
AS --> AC
217
-
AC --> TE
218
-
TE --> AT
219
-
AT --> API
220
-
221
-
AR -. observable in .-> PX
222
-
AT -. observable in .-> AZ
223
-
```
279
+
#### Detection Data Model
224
280
225
-
Detection opportunities for this technique are limited because much of the OAuth authorization flow occurs within trusted Microsoft identity infrastructure. One potential observation point is network or proxy telemetry capturing requests to the Microsoft authorization endpoint. Although these requests often appear legitimate, a notable indicator may be the presence of `localhost` within the `redirect_uri` parameter of the OAuth authorization request, which is uncommon for most production applications.
Detection opportunities for this technique are limited because much of the OAuth
284
+
authorization flow occurs within trusted Microsoft identity infrastructure. One
285
+
potential observation point is network or proxy telemetry capturing requests to
286
+
the Microsoft authorization endpoint. Although these requests often appear
287
+
legitimate, a notable indicator may be the presence of `localhost` within the
288
+
`redirect_uri` parameter of the OAuth authorization request, which is uncommon
289
+
for most production applications.
290
+
291
+
This signal may be more meaningful when correlated with Microsoft Entra ID
292
+
sign-in telemetry, such as events recorded in `NonInteractiveUserSignInLogs`.
293
+
Following a suspicious authorization request, defenders may observe a token
294
+
issuance or application sign-in event associated with the same application
295
+
identifier present in the request. These events may originate from an unexpected
296
+
IP address, device context, or location compared to the user’s normal
297
+
authentication patterns, particularly if the authorization code is redeemed from
298
+
a different environment than the one used during the initial authentication.
226
299
227
-
This signal may be more meaningful when correlated with Microsoft Entra ID sign-in telemetry, such as events recorded in `NonInteractiveUserSignInLogs`. Following a suspicious authorization request, defenders may observe a token issuance or application sign-in event associated with the same application identifier present in the request. These events may originate from an unexpected IP address, device context, or location compared to the user’s normal authentication patterns, particularly if the authorization code is redeemed from a different environment than the one used during the initial authentication.
228
300
## Available Emulation Tests
229
301
230
302
| ID | Link |
@@ -234,12 +306,16 @@ This signal may be more meaningful when correlated with Microsoft Entra ID sign-
0 commit comments