A web application framework for launching and managing OAuth abuse campaigns.
Created By Doug Bienstock (@doughsec) while at Mandiant/FireEye
- An Internet accessible server (tested running Ubuntu 16.04)
- Docker (apt install docker.io)
- Docker-Compose (newest version from docker website)
- A Valid SSL certificate
- Clone the repository onto your server
Dockerfilecustomize the settings to your site:
DJANGO_SITEto match the FQDN or IP address you will use to access the PwnAuth App.
- Change the
SECRET_KEYto a new random value.
devdepending on if you are in production or not.
- Configure your SSL certificates and NGINX. I have provided a sample NGINX configuration in
setup.shas root. This will build the docker services for the OAuth application as well as setup an initial Django administrator for you to use the application with.
- Login to the app. Navigate to
/auth/loginin your browser to login to the application with the account you just created.
For more first use instructions see the wiki
PwnAuth is designed to be modular. A new Identity Provider can easily be supported by developing the necessary database models and views to interact with the Resource Server. As long as you follow the module implementation guidelines, the GUI will automatically detect the module and it will be ready for use.
- You must create a new OAuth application with microsoft at the Microsoft App Portal
- You must create a "Web" or "Server-Side Web App" platform with a proper Redirect URL. The default configuration for PwnAuth is
- Be sure to create a secret password and ensure your delegated scopes include
- Import the application settings into the application using the GUI
- Send out your phishing emails using the
authorization_url_fulllink and wait for responses!
PwnAuth is designed to be interacted with inside of a browser. There is also an API available available for power users. To learn more about using PwnAuth see the wiki.
Logs are written to
/var/log/oauth on your host system where docker is running. The
audit log records all actions taken in the application and by whom.
Detection can be quite difficult due to the limited amount of information on these applications that is exposed. In general the best bet is to hunt for specific scopes that would be suspicious (i.e. offline access, sending/reading of mail) as well as apps that have redirect URLs (the URL that receives the token) that are strange. This issue is further compounded by the large number of "legitimate" applications out there that request incredibly wide scopes.
See my related repository of hunting scripts, OAuthHunting