Threat Research Blog December 1, 2020

MailSniper – You Can Teach an Old Dog New Tricks: Pwn O365-based Organizations by Leveraging PRT-based SSO

By Yan Linkov

MailSniper is a penetration testing tool for searching through email in a Microsoft Exchange environment for specific terms (passwords, insider intel, network architecture information, etc.). It can be used as a non-administrative user to search their own email, or by an Exchange administrator to search the mailboxes of every user in a domain.

This blog post will describe how we upgraded the notorious penetration testing tool. The upgrade allows red teamers to use a stealthier attack approach on O365 users without the need for admin credentials or knowing the victim’s password.

Our improvements include the following features:

  1. Authenticate to exchange online 365 by leveraging Microsoft’s azure single sign-on capabilities while bypassing multi factor authentication requirements.
  2.  Add oauth2.0 access token authentication support.

Also, we’ll go over some attack scenarios:

  1. Scraping an O365 mailbox by leveraging SSO
  2. Abusing O365 Admin credentials to impersonate multiple mailboxes
  3. A stealthy attack scenario which will significantly decrease attackers’ chance of being detected by AV\EDR solutions.



In the past few months, we’ve seen some interesting blog posts and tool releases regarding Microsoft’s Azure AD SSO capabilities. Yep, all those PRT articles and tweets by dirkjan, Benjamin Delpi, Lee Christensen and NestoriSyynimaa you’ve been reading about.

In this blog post, we hope to offer you some practical red team capabilities to leverage these findings – in the form of an upgraded MailSniper.

What is a Primary Refresh Token?

Since many of the other blogs already cover this section, we’ll keep it simple:

PRT is a token that makes SSO possible in azure ad joined\azure ad hybrid and azure ad registered devices (yep those too).

If you want the bits and bytes you can read Microsoft’s documentation here.

Azure AD Registered – let’s see we’re on the same page here

“The goal of Azure AD registered devices is to provide your users with support for the Bring Your Own Device (BYOD) or mobile device scenarios. In these scenarios, a user can access your organization’s Azure Active Directory controlled resources using a personal device.”

Yep, even if it’s your home computer, and you’ve innocently signed in to one of the office suite apps with your work account, you’ve probably registered the device with your organizations azure tenant, and Azure AD SSO capabilities are now enabled on your personal device.

So yeah, the PRT is secured via a different mechanism, and it’s even missing the “is_primary: true” field, but it’s still wrapped up in the same ribbon – you can still get the proof of possession cookie via the same methods mentioned below.

Side note: you may want to check Mimikatz’s command dpapi::cloudapreg

Getting our proof of possession cookie

The proof of possession cookie is a token the SSO mechanism uses for authentication when requesting application-specific access tokens.

Basically, it’s a signed JWT (JSON Web Token) that contains the PRT and a request nonce which proves the token was generated based on the current authentication request (now that Microsoft fixed their bug).

To get the cookie you can either use Proof of possession cookie API as described in this great article, or you can use BrowserCore as described in this great article.

We chose to use the BrowserCore method since it was easier to implement in PowerShell, we used a modified version of Get-UserPRTToken by @NestoriSyynimaa which is part of AADintenals to do so.

Getting an access token with EWS permissions

Once we got our proof of possession cookie, we can make our access token request.

MailSniper relies on Exchange EWS in its Invoke-SelfSearch function.

So, we need to get ourselves an access token with delegated EWS credentials…

Fortunately, Microsoft’s public office application (identified by “d3590ed6-52b3-4102-aeff-aad2292ab01c”), has all the delegated EWS permissions we need 😊

Now we can use the proof possession cookie we got, to request that access token.

We place the token we extracted from our proof of possession cookie in the x-ms-RefreshTokenCredential HTTP header and make an access token request to the previously discussed public office application.

To do so we used a modified version of NestoriSyynimaa’s Get-AccessTokenWithPRT which is part of AADintenals.

Great, now we have our access token, let the scrapings begin(don’t forget the access token is valid for 2 hours).

What about MFA?

By now, you are probably wondering about MFA, not to worry, as described in previous blog posts and in Microsoft’s documentation:” A PRT can get a multi-factor authentication (MFA) claim in specific scenarios. When an MFA-based PRT is used to request tokens for applications, the MFA claim is transferred to those app tokens. This functionality provides a seamless experience to users by preventing MFA challenge for every app that requires it.”

MailSniper changes

List of new\updated functions:

  1. Get-UserPRTToken – generates a PRT cookie
  2. Get-AccessTokenWithPRT – gets an access token based on the PRT cookie
  3. Get-ExchangeAccessToken – gets an access token with EWS permissions
  4. Get-ExoPsAccessToken – gets an access token with exchange online remote PowerShell permissions
  5. Invoke-GlobalO365MailSearch – O365 based version of Invoke-GlobalMailSearch to leverage SSO and modern authentication
  6. we’ve added 2 new parameters to the Invoke-SelfSearch, Get-MailboxFolders, Invoke-OpenInboxFinder functions:
    1. UsePrt – uses the PRT to get an access token to the public office app
    2. AccessToken – you can provide your own access token with EWS credentials


Attack Scenarios


Scraping O365 mailbox by leveraging SSO

You’ve landed on a victims’ machine, and you want to do some mail scraping.

Unfortunately, it’s an o365 based organization with MFA enabled – no worries:

Just run the good old Invoke-SelfSearch with the new “UsePrt” flag and enjoy it.

Invoke-SelfSearch -ExchHostname -UsePrt

Abusing O365 Exchange Admin credentials to impersonate multiple mailboxes

You’ve landed on victim’s machine, and you want to do some mail scraping, but wait – it’s an exchange administrator, you hit the jackpot!, then you realize: MFA is enabled and MailSniper doesn’t support O365 and modern authentication – no worries:

Just run the new and improved Invoke-GlobalO365MailSearch and enjoy it.

Invoke-GlobalO365MailSearch -ImpersonationAccount -UsePrtImperonsationAccount -ExchHostname -AdminUserName -UsePrtAdminAccount

Stealthy attack scenario

As you may have noticed, MailSniper is sometimes detected as malware by your AV\EDR, which usually leads to its detection and deletion.

Also, since many organizations moved their exchange to the cloud, MailSniper can’t use Invoke-SelfSearch without the “Remote” switch, which prompts for credentials.

And, finally, some CISO’s enforce MFA on their beloved users.

So, Sure, you can always bypass MFA, elevate yourself to admin, bypass AV\EDR, dump or phish user’s credentials and maybe bypass EDR again, or, you can just follow these 5 simple steps:

  1. Separate our 4 access token related functions to a new PowerShell script
  2. Run the new script on the victims’ machine to get an access token
  3. Since we are dealing with O365, you can pass the access token in any way you want to your own AV-less machine
  4. Run the modified Invoke-SelfSearch function with AccessToken parameter
  5. Enjoy 😊

BTW, you can combine this scenario with the Exchange admin scenario if you’ve been struck by lady luck.

$newAccessToken = “eyJ0eXAiOiJKV1QiLCJub25jZSI6Il84VnNuTjJ…”

Invoke-SelfSearch -ExchHostname -AccessToken $newAccessToken


What can you do about it?

Even though there is no magic pill, there are some general actions you can consider taking to detect and maybe prevent PRT abuse (some of them are already covered in the blog posts mentioned above).

  1. Monitor anomalous access attempts to BrowserCore:
    1. Why would an unprivileged user run a PowerShell script that accesses BrowserCore?
  2. Leverage your end point solution to detect anomalous usage of Proof of possession cookie API
  3. Consider disabling outlook OWA access to help reduce some browser based attack surface
  4. Monitor Azure and O365 authentication logs and look for:
    1. user agent discrepancies
    2. geolocation based anomalies



To sum things up, SSO always had its downsides (which were usually upsides for us 😊).

We can leverage its capabilities in many ways, this time we choose to do it by upgrading MailSniper.

Using our upgraded version of MailSniper you can easily and safely scrape mailboxes while avoiding:

  • getting admin access
  • phishing\dumping credentials
  • running known tools on Victims Machine
  • bypassing MFA
  • dealing with AV\EDR
  • creating your own PRT and singing it as described in previous blog posts


GitHub link

Link to our upgraded MailSniper: