You read the title right, there is an easy way to gain access to a user’s Office 365 mailbox, attachments, and OneDrive data without stealing a username and password. This kind of attack is starting to appear more and more to replace the traditional phishing of credentials. In this blog post, I will demonstrate how this process works, and what you can do to prevent it in your Office 365 tenant.

When you look at ways to gains access to Office 365, attackers still use a lot of traditional credential phishing methods. Using a link to a malicious form and get the victim to enter their credentials is still the common way to go. But there is another method to achieve access without having to grab those credentials. With the use of an Azure app, we can trick our victim into consenting to the access our app wants. This way the victim grants the app permission on the Office 365 resources without the need for a password. In case they suspect access to the account, and reset the password, our app still stays authorized to the user’s Office 365 account.

Let’s take a look at how we can use this kind of attack to not only gain access to the Office 365 account but also automatically grab the loot. For this blog post I used the script and website created by Altered Security, called: 365-Stealer. You can download it from GitHub.

Setting up the malicious app and webserver

The first step in the process is to create a new App registration in my Azure tenant. Just click New registration to get started.

For the app registration, it is important to select the right setting for Supported account types, provide the URL of the 365-stealer location (localhost in my case) and give this puppy a name. After that, just click Register to create the app registration.

When the registration is successful, you will see the Application (client ID), which you will need later on. Make sure to store the Client ID.

Even though the registration is finished, it needs some extra configuration on the Authentication page. Activate both options for Implicit grant and save the configuration.

Now that we have our App registration up and running, it is time to fire up the server running the malicious website and 365-stealer script. I use a virtual Windows 10 client for this, but you can choose any webserver of your liking. I have installed the following requirements to set this up:

• Python 3
• Pip
• XAMPP (for Apache on Windows)

When everything is installed, it only a matter of starting Apache.

With the webserver running, I download the 365-stealer from Github and extract the contents to the c:\xampp\htdocs folder.

There is only one more thing that needs to be done, and that is configuring the index.php file to have the correct $client_id. We need to replace it with the Client ID we generated within Azure.

// Following varaibles need to edited
$client_id = "f813e35c-068a-47c0-8c0e-3219a91b4fc1";
$redirect_uri = "http://localhost/";

The 365-stealer.py file includes some parameters you can change to match the action you want. For example what kind of rule you want to create within the mailbox, or which filetypes to look for within OneDrive.

Gaining access to the O365 User data

Having everything set up, It is now time to see how we can grab the data for a user within this O365 tenant.

First, let’s assume the user receives an email with a link to our malicious website at http://localhost/. The user is already logged in to O365 since he or she does that every morning. So there is an authenticated session present. After opening the email he or she clicks the link and gets sent to this fake Microsoft website. All links on this page have been rigged to trigger the user consent process.

Now when the user clicks on one of the links, a pop-up will show up asking the user for consent. As you can see, the name of the app is the same one as we registered earlier. It does state that it is not published by Microsoft, but I guess a lot of users won’t even read this part. Even though it is in Dutch, you get the picture. You are signing over your soul to the devil! Maybe not really, but at least the permissions to your mailbox 🙂

After the consent, the website returns to the starting page and does not serve any purpose after that. Now the question is, what loot did we get from the user?

Viewing the loot

The 365-stealer tool has a build-in website to view the loot you grabbed from the user. By visiting http://localhost/yourVictims, I can see all the compromised accounts and deep-dive into the grabbed stuff.

With the default configuration, it searches for email attachments en file on OneDrive which contain the word “password” and grabbed all emails. The script stores this on the webserver.

As you can see, grabbing all the emails paid off. One email with credentials and one Pincode.

• 

• 

All the files on the victims OneDrive got checked, and the files with “password” in it are stored. The passwords.docx file was created for testing the tool and got grabbed successfully.

As you can see, this is the loot we are looking for. A bunch of fake passwords!

A very powerful action that the script can do, is creating mailbox rules. A good and much-used way to keep persistence in a mailbox and start things like conversation hijacking or grabbing business intel. I configured the script to create a mailbox rule to forward all messages containing the word “password” to me. Nice, isn’t it?

Prevent this kind of attack on your Office 365 tenant

Knowing that these kinds of attacks exist gives you an advantage. But how can you protect your tenant from attacks like these? Well, you have to take into consideration that in a default configured tenant, all users have the permission to consent to an app having access to their data. And this is where you want to put some restrictions in place.

Within your Azure Portal, you can change the user permissions so that an administrator has to approve consent requests. Yes, this does give the admin some more work, but at least it is less than having yourself a data breach. By turning off the ability for users to consent to apps having access to data on their behalf, the risk is mitigated on the user part and admins have to check and approve the consent.

Hopefully, this helps you to not only spot the threat in your organization but also mitigate the risk by preventing the user consent.

[box type=”warning” align=”” class=”” width=””]All information in this post is for educational use only! Do not use it at others when you do not have explicit approval to do so. I am not responsible for your actions. Using this knowledge for illegal activities could land you in jail![/box]