There is new demo available here done for HelSec 12.2019
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.
- 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
- 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)
- Hidden iFrame executes the OAuth2 Implicit Grant Flow, and gains Access Token to resource
- 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
- 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
- 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
See it live:
Microsoft has issued multiple items in Secure Score controls about the scenario
Stay tuned for PT2 (How to defend against it)