OAuth 2.0 Abuse

What Is OAuth 2.0

OAuth 2.0 allows third-party application to access services via access token without disclosing credentials.

OAuth 2 is an authorization framework that enables applications — such as Facebook, GitHub, and DigitalOcean — to obtain limited access to user accounts on an HTTP service. It works by delegating user authentication to the service that hosts a user account and authorizing third-party applications to access that user account. OAuth 2 provides authorization flows for web and desktop applications, as well as mobile devices.

Attack

Attackers can create malicious OAuth phishing and app impersonations to trick account owners into giving them access to their accounts via stealing their access token.

Powerful advantages:

  • Can bypass MFA.

  • Even if password is reset, access token is still valid.

How to steal 0Auth 2 Tokens:

  1. Start webserver by running 'app.py'. This will start a Flask based web server. (Securing the server is up to you. Recommend putting behind a HTTPS redirector if open to the internet)

  2. Have a user open the configured link to sign-in to the portal

  3. An access and refresh token will be returned and written to a pickle file. Currently, only one set of tokens can be stored per user.

  4. Once tokens have been collected, run 'mainAPI.py' and choose the action you wish to take

Link given to victim for fake sign-in page.

  • Identifies client_Id

  • Redirect URL to malicious website

  • Permissions application wants access to.

Page the user sees when they click the link.

What the victim sees after they click accept.

Successful token theft.

Once the token is granted to us, we can pass it into GraphAPI and leverage it however we want.

Detect

Gather hunting information from the malicious link that the user clicked.

  • Client_ID - Identifies client_Id (can be in attacker's tenant or YOUR tenant)

  • Redirect_URL - Redirect URL to malicious website

  • Scope - API permissions application wants access to.

    • User.Read - Allows app to read user information and basic company info.

    • User.ReadWrite - Allows app to read and update user profile information

    • User.ReadWrite.All - Read/write/update full user profile. Can create/delete/reset user passwords.

    • Mail.ReadWrite - Allows app to read and write emails

    • Files.ReadWrite - Allows app to read/write files

    • Calenders.ReadWrite - Allows app to read write calender. (TA can hunt for incident response bridge call and join).

    • User.Export.All - App can request to export user's personal data

Detection - Audit Logs

Log location:

  • Active Directory > Monitoring > Audit Logs

For every application consent, three corresponding audit log entries will be created.

  • Consent to application

  • Add app role assignment grant to user

    • Application scope the app is requesting

  • Add delegated permissions grant

Consent to application

  • Initiated by <TA>: <malicious clientID of app>

  • Target Display Name: <malicious app name>

"Add app role assignment grant to user"

  • Activity

    • Status: successful/unsuccessful

    • ObjectID - malicious app objectID/clientID

    • Target Display Name: <malicious app name>

Within "Add delegated permissions grant" you can see what permissions were granted in New Value.

  • New Value: <permissions granted to malicious app>

Detection Sign-In logs

Log location:

  • Active Directory > Monitoring > User sign-in logs (interactive)

Information Displayed:

  • IP address: <TA IP used>

  • Application: <display name of malicious app>

  • User ID: <objectID of malicious app>

  • User: <victim account name>

  • Authentication Required: <always single factor because it's logging in with access token>

    • If it's single factor, it is an indicator that this is a access token related attack.

Mitigate

Application Administrator and Global Administrator should be required to approve applications.

  • Entra ID > Enterprise Applications > Consent and Permissions

If this option is set to yes, then users may add any app which supports password single-sign on to appear in My Apps, without an admin needing to pre-integrate that application. If this option is set to no, then admins must manually integrate these applications in order for users to see them on My Apps.

  • Entra ID > Enterprise Applications > User Settings

  • Malicious apps can still be "verified". Verification requires a TA to have an MPN ID account and has performed the verification process and other things.

Microsoft Entra ID > Enterprise Applications > Consent and permissions

  • Can assign groups of Admins who can approve consent for end-users.

The more you limit the scope of the groups, the better.

How to see what apps the user consented to:

  • Entra ID > Users > [Select User] > Applications

  • Limit the permissions and follow least priv on permissions that users have the ability to consent to.

Last updated