Disclaimer: All information contained within this post is common knowledge, given you grasp basic concepts of AAD default behavior, OAuth2 Authorizations and how Javascript works in browsers.

There is new demo available here done for HelSec 12.2019

https://securecloud.blog/2019/12/17/helsec-azure-ad-write-up-phishing-on-steroids-with-azure-ad-consent-extractor/

How does it work?

Attacker creates multi-tenant app, and adds non-admin requiring API permissions for the desired API’s. Attacker then delivers the link to end user, which after clicking the link only has to consent (Approve) the API permissions for the attacker.

Attacker has then access to user mail, this happens because attacker exfiltrates in the background the Access Token and uses it against the Exchange Online API

Down below I describe why it might be hard for the user to discern good app from the bad app.

Why it works?

Multi-tenants app by default have access to end users data, unless your Azure AD Admin have disabled the particular defaults that enable this behavior.

PoC

Create multi-tenant Azure AD Web-App/API + Azure Web App that delivers the JS. client side code to browser from Node.JS Web App
I am using minified ADAL.JS as <script src in the code. Other than that, I’ve just added few custom functions to the code, and studied wide variety of existing Vanilla ADAL JS Apps in GitHub
- https://secure.aadcdn.microsoftonline-p.com/lib/1.0.11/js/adal.min.js
Figure out a way to deliver the link to the victim/victims in other AAD / Office 365 tenants
I’ve opted to forge existing Microsoft Newsletter with link to malicious Azure Web App to
When user clicks the link consent dialog is prompted.

Consent – This as any other dialog, you would get prompted for when consent framework kicks in (This is where the confidence part happens)

The process is same for benign apps, so there is superficially nothing to separate the good app from the bad (except caution, which is often unheeded, if you consider how often an mobile application presenting similar dialog is approved for multiple permissions in mobile phone)

User is redirected to the malicious app with seemingly benign OIDC-Flow (response_type=id_token)… no mention here of the OAuth2 Implicit Grant Flow (yet)

Redir

Hidden iFrame executes the OAuth2 Implicit Grant Flow, and gains Access Token to resource

Tokens

AJAX HTTP is used to post the Access Token as Payload to external exfil service
- In case you wonder, that I’d left the function key there :)… Just try

JAX

User is redirected to the original link requested in the mail

<- Users timeline stops here

– >Perpetrators timeline begins here

Token is copied by the malicious actor from Azure Functions where it was posted

Exfil

JWTIO

A Separate Powershell session running in some dark corner of the world is now searching users mail content for several keywords, and playing with the Access Token for the next 3600 seconds

Passwords