Casting into the Current

Microsoft OAuth Device Flow Phishing

Overview

As an educational exercise aimed at exploring some of the nuances of automating and understanding Azure/M365 OAuth-related attacks, particularly device code phishing and illicit consent grant attacks, a custom lab was built. This simulated environment consisted of a Flask application, an Azure Registered Web application, and an Azure tenant with a Microsoft 365 subscription, facilitating an exploration of the intricacies of these cyber threats.

Hook, Line and Sinker

The simulated scenario involves a malicious website, the URL which could have been sent via a phishing email, leading to a convincingly branded company login portal. The socially engineered victim, unaware of the ruse, clicks on the link and inadvertently provides their login credentials. The malicious actor successfully deceived the user by utilizing device code phishing, and in this example, could further be exploited to obtain the user’s access token after consenting to a malicious registered Azure application. For further information on these types of attacks and the references that inspired or provided guidance in creating the lab environment, please refer to the “References and Resources” section at the end of the blog.

Custom Lab

There were three main components in the custom lab setup: a Flask application, an Azure Registered Application, and an Azure tenant including a Microsoft 365 subscription. The Flask application served as the operational core, managing dynamic device codes due to OAuth’s token expiration constraints, refreshing expiring access tokens and performing exploitation including uploading malicious files to OneDrive and data exfiltration from OneDrive and Outlook. The Azure Registered Application played a pivotal role in simulating illicit consent grant attacks, highlighting the importance of scrutinizing application permissions. Lastly, the integration with the Microsoft 365 Developer Program provided a realistic and safe environment to understand these interactions and vulnerabilities.

The Flask application for this project was developed and run on a local Kali Linux machine within my home lab environment, on a VMware virtual machine. It’s important to note that the simulated phishing page was not hosted on a public website, ensuring that it remained isolated within the controlled lab environment.

Flask Application

What is Flask?

Flask is a micro web framework for Python. It’s designed to be lightweight and easy to use, making it a popular choice for developing web applications and APIs in Python.

Key components

Phishing Page and Redirection: The Flask application hosted a phishing page, convincingly mimicking a legitimate corporate portal displaying a Device Token for the victim to use for verification. Upon user interaction, it redirected victims to a malicious Azure Registered Application, effectively capturing their authentication details.

Dynamic Device Code Management: Due to the 15-minute expiration of OAuth device code tokens, the Flask app was essential for dynamically managing these. It kept the phishing operation continuous and effective by handling the short-lived nature of these tokens.

Database Integration for Token Management: The application used a SQLite database to store and manage phished tokens, including access, refresh tokens and expiration. This allowed for efficient tracking of tokens and ensured timely refresh of tokens nearing expiration, maintaining extended access.

Refresh Token Management: A key functionality was managing the lifecycle of refresh tokens. The application could automatically renew access tokens using these refresh tokens, thereby prolonging unauthorized access without user awareness.

Exfiltration Capabilities: The application was equipped to exploit the phished victim by exfiltrating data from the users’ OneDrive and email. This involved downloading sensitive files and emails, providing a stark demonstration of how phishing attacks can lead to significant data breaches.

Uploading Malicious Files to OneDrive: Another alarming capability of the application was its ability to upload malicious files to a victim’s OneDrive. This could facilitate further attacks, such as spreading malware or deploying ransomware in subsequent social engineering attacks.

Modular Design: The application features a modular design, enabling the seamless integration of new capabilities, such as the ability to launch attacks targeting Teams and calendar.

Azure Registered Application:

Utilizing an Azure Registered Application in this lab setup provided a realistic environment for understanding how attackers can misuse legitimate cloud services. It demonstrated the importance of scrutinizing application permissions and the potential dangers of overprivileged applications in cloud ecosystems.

Conclusion

In conclusion, this exercise has been useful in improving understanding of OAuth, the Microsoft Graph API, and the intricacies of Azure/Microsoft 365 attack vectors. While the aim of this post was not to unveil a new GitHub tool, it’s important to acknowledge the existence of superior tools already available. For those interested in exploring these tools or delving further into the types of attacks discussed, highly recommend visiting the resources and references section. There, one will find a wealth of information.