Skip to content

Commit 67102dc

Browse files
committed
a
1 parent 8080082 commit 67102dc

File tree

1 file changed

+1
-0
lines changed

1 file changed

+1
-0
lines changed

src/pentesting-cloud/azure-security/az-basic-information/az-tokens-and-public-applications.md

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -227,6 +227,7 @@ From an attackers perspective it's very interesting to know where is it possible
227227
- In Windows this just generates id tokens.
228228
- Possible to see if Az PowerShell was used in Linux and macSO checking is `$HOME/.local/share/.IdentityService/` exists (although the contained files are empty and useless)
229229
- If the user is **logged inside Azure with the browser**, according to this [**post**](https://www.infosecnoodle.com/p/obtaining-microsoft-entra-refresh?r=357m16&utm_campaign=post&utm_medium=web) it's possible to start the authentication flow with a **redirect to localhost**, make the browser automatically authorize the login, and receive the resh token. Note that there are only a few FOCI applications that allow redicet to localhost (like az cli or the powershell module), so these applications must be allowed.
230+
- Another option explained in the blog is to use the tool [**BOF-entra-authcode-flow**](https://github.com/sudonoodle/BOF-entra-authcode-flow) which can use any application because it'll **get the OAuth code to then get a refresh token from the title of the final auth** page using the redirect URI `https://login.microsoftonline.com/common/oauth2/nativeclient`.
230231

231232
## References
232233

0 commit comments

Comments
 (0)