MailSniper is an awesome tool written by dafthack for attacking Microsoft Exchange environments, including Outlook Web Access (OWA). I won’t get into all of the features here since there’s a ton of information on the GitHub page, including a cheat sheet.
Instead, what I wanted to cover in this post was how to use one of MailSniper’s most useful features, Get-GlobalAddressList, with cookies. This is especially useful when a client’s OWA is behind some other authentication portal that you need to first authenticate to, before being directed to their OWA.
These “gatekeepers” can also protect other areas of OWA that require authentication such as autodiscover and EWS. MailSniper requires unfettered access to OWA in order to attack it effectively. This obviously won’t be the case if it’s being redirected elsewhere to authenticate first.
If you haven’t used MailSniper before, Get-GlobalAddressList is a module in MailSniper that will attempt to grab an organization’s Global Address List (GAL) in one of two ways – the “FindPeople” method which only exists on Exchange 2013 and higher, or Exchange Web Services (EWS). Grabbing the GAL can be beneficial in many ways on an engagement since they contain valid usernames. For instance, the names can be used in a password spraying campaign to discover other users using weak passwords, but are also part of a VPN or RDP group.
What follows is a scenario that I ran into on an engagement where the client was using KEMP LoadMaster in front of their OWA. Even though the write-up is specific to KEMP LoadMaster, the same method should apply to other systems that rely on a valid cookie to redirect traffic to the actual server hosting the service.
A few months back, I was on an engagement where a client’s OWA portal was behind a KEMP LoadMaster load balancer with Edge Security Pack (ESP) enabled. What all this means is that traffic requesting a particular service (OWA in this instance) will need to authenticate to the authentication provider prior to hitting the OWA portal. Once authenticated, a cookie is set (if using form-based authentication) and included in the header of future requests to allow all subsequent traffic access to the real server.
KEMP has a nice technical break down of the entire process here. What we’re most interested in is this part:
Capturing the cookie is simple enough to do through Burp, Zap, etc. Once you have valid creds, proxy the authentication request, then take note of the set-cookie in the response:
Make a copy of MailSniper.ps1 and open the copy in your favorite editor. Do a search for Get-GlobalAddressList and scroll down a bit until you see the try statement. Between the $FindPeopleURL and Write-Output in the try clause, insert the following snippet of code (replacing the blue parts with the cookie name, value, and domain:
$owasession = New-Object Microsoft.PowerShell.Commands.WebRequestSession $cookie = New-Object System.Net.Cookie $cookie.Name = "lmdata99999999999999999" $cookie.Value = "x" $cookie.Domain = "mail.client.com" $owasession.Cookies.Add($cookie);
Then modify the $owalogin variable so that it reads:
$owalogin = Invoke-WebRequest -Uri $OWAURL -Method POST -WebSession $owasession -Body $POSTparams -MaximumRedirection 0 -ErrorAction Ignore
Like so:
Save and import the modified MailSniper.ps1 into PowerShell. When you dump the GAL using the modified script, MailSniper should now use the cookie you captured as part of its request. If all goes well, it should redirect MailSniper’s request to the real OWA server where MailSniper can do its little GAL dance.
Just a side note – in most cases, the cookie will expire in a short amount of time. If you’re running into issues, proxy the authentication request again, capture the new cookie, and modify the script with the new cookie.
Be First to Comment