Overview

Microsoft Exchange users have the power to grant other users various levels of access to their mailbox folders. For example, a user can grant other users access to read emails from their Inbox. If a user (or Exchange administrator) isn’t careful and sets permissions incorrectly they might grant access to their mailbox to everyone at an organization. This creates a situation where any user at the organization can now read email from the mailbox with too broad permissions.

Using MailSniper, it is possible to quickly enumerate mailboxes like this that are accessible by any user. In this blog post, I’ll be describing how this problem can occur, how to locate mailboxes with permission issues, and ultimately how to read email from these mailboxes without the need for the mailbox owner’s credentials.

Setting Mailbox Permissions with Outlook

Changing permissions on a mailbox is a relatively easy thing for a user to accomplish on their own using the Microsoft Outlook client. If a user right clicks a folder such as the “Inbox”, then clicks Properties…”, a folder properties menu will open.

Clicking on the “Permissions” tab one can see the current settings for the folder. This is where things get a bit interesting. By clicking the “Add…” button this allows a user to specify a certain account to grant various permissions to. This would be ideal because a user can limit access to specific people. However, you will notice there are “Default”, and “Anonymous” items already included in Permissions. The “Default” item essentially includes every user at an organization with access to email.

If a user mistakenly sets the permission level for the “Default” item to anything other than “None” (besides Contributor), they are potentially allowing every employee at an organization access to that mailbox folder.

Setting permissions on mailbox folders can also be set by an Exchange administrator. Using the Set-MailboxFolderPermission cmdlet on the Exchange server directly, these mailbox permissions settings can be modified.

Invoke-OpenInboxFinder

As a penetration tester, finding mailboxes that are essentially world-readable can be extremely valuable. They could allow for a number of interesting attack vectors. For one, we could search through another user’s emails for certain things like passwords or sensitive data without having their credentials. Another attack vector could be that if the user’s email address is tied to a password reset system an attacker could trigger the password reset, then access the user’s email containing the password reset link.

I’ve added a function into MailSniper called Invoke-OpenInboxFinder to help find mailboxes with permissions set to allow other users access. To use it though we first need to gather a list of email addresses from the target environment. MailSniper has a module called Get-GlobalAddressList that can be used to retrieve the Global Address List from an Exchange server. It will try methods for both Outlook Web Access (OWA), and Exchange Web Services (EWS). This command can be used to gather an email list from Exchange:

Get-GlobalAddressList -ExchHostname mail.domain.com -UserName domain\username -Password Spring2017 -OutFile global-address-list.txt

If you are on a system that can communicate with the target organization’s internal Active Directory domain it is also possible to use Harmj0y’s PowerView to gather an email list. Import the PowerView script into a PowerShell session and run this to get an email list:

Get-NetUser | Sort-Object mail | ForEach-Object {$_.mail} | Out-File -Encoding ascii emaillist.txt

After gathering an email list, the Invoke-OpenInboxFinder function can check each mailbox one at a time to determine if the current user has access. It also will check to see if there are any public folders in Exchange that could potentially be accessed as well.

To use Invoke-OpenInboxFinder import the MailSniper PowerShell script into a PowerShell session with:

Import-Module MailSniper.ps1

Next, run the Invoke-OpenInboxFinder function with:

Invoke-OpenInboxFinder -EmailList .\emaillist.txt

Invoke-OpenInboxFinder will attempt to Autodiscover the mail server-based off of the first entry in the email address list. If this fails, you can manually set the Exchange server location with the -ExchHostname flag.

In the below example the command terminal is running as a domain user called ‘jeclipse’. After running Invoke-OpenInboxFinder against a list of email addresses from the domain two public folders were discovered. Also, the Inbox of “maximillian.veers@galacticempireinc.com” is accessible to ‘jeclipse’. Invoke-OpenInboxFinder will print out the permission levels for each item. It can be seen in the output that the “Default” item is set to “Reviewer”.

Searching Other User’s Mailboxes with MailSniper

After discovering that a mailbox has broad permissions that allows a user to access it, MailSniper could then be used to read and search through the messages in the target mailbox. The Invoke-SelfSearch function of MailSniper previously was purposed for primarily searching the mailbox of the user who was running it. I’ve modified it slightly to allow for checking another user’s email. A new flag called “OtherUserMailbox” needs to be specified to access other mailboxes. An example command would be the following:

Invoke-SelfSearch -Mailbox target-email-address@domain.com -OtherUserMailbox

In the screenshot below I am using the “jeclipse” account to search maximillian.veers@galactiempireinc.com’s mailbox. Three results were found where the subject or body of his emails contained the terms password, creds, or credentials.

Office365 and Externally Facing Exchange Servers

Invoke-OpenInboxFinder also works across the Internet against Office365 and externally facing Exchange servers if Exchange Web Services (EWS) is accessible. Unless, Autodiscover is set up externally it is likely you will need to manually specify the target hostname with -ExchHostname. For connecting to Office365 the hostname would be “outlook.office365.com”. Specify the -Remote flag to have Invoke-OpenInboxFinder prompt for credentials that can be used to authenticate to the remote EWS service.

An example command for checking mailboxes hosted on Office365 for broad permissions would be the following:

Invoke-OpenInboxFinder -EmailList .\emaillist.txt -ExchHostname outlook.office365.com -Remote

Below is a screenshot from an actual real-world assessment where the customer utilized Office365. We had access to a single user’s credentials at the organization. By running Invoke-OpenInboxFinder using an email list gathered from the Global Address List we were able to determine that three separate accounts at the organization allowed our user to read their email.

Recommendations

Obviously, preventing an attacker from gaining access to a valid user account would be the first step in defending against this. The problem though is that it doesn’t prevent your current employees from using this technique to see what other users’ ur’ mailboxes they have access to. Also note that it does appear that you must have a valid domain account that also has a mailbox in Exchange associated with it to check permissions on other uss’ mailboxes.

If possible, restricting these types of changes from being made on the Outlook client would be helpful. I’ve found a few older (2010) posts stating the permissions tab can be locked down with a GPO. I have not personally tried any of the solutions offered on these pages but it might be worth checking out. You can find those here , and here.

Use the Invoke-OpenInboxFinder function in MailSniper, or the Get-MailboxFolderPermission cmdlet on Exchange to audit these settings for all accounts at an organization.

Conclusion

Mailbox permissions are something that should be looked at by both blue and red teams. With the way Outlook includes the “Default” permission item in folder properties, it makes it far more likely that a user mistakenly grants everyone at an organization access to their mailbox. On the red team side this could provide an opportunity to find passwords or other sensitive data within emails that might further access on the network. Blue teams should worry about that but they also have other things to worry about. Some other things blue teams should worry about are high-profile accounts (C-Suite types) accidentally sharing their mailboxes out with the company, corporate employees snooping on other employees, or even the legalities of mailbox modification through these avenues.

______

You can download MailSniper from Github here: https://github.com/dafthack/mailsniper

Special thanks to ‘doomguy’ for opening an issue in the MailSniper repository on Github asking if this capability would be possible!

This is a cross-post from the Black Hills Information Security blog here: http://www.blackhillsinfosec.com/?p=5871

I’ve added in a few modules to MailSniper that will assist in remote attacks against organizations that are hosting an externally facing Exchange server (OWA or EWS). Specifically, the modules are Get-GlobalAddressList, Invoke-PasswordSprayOWA, and Invoke-PasswordSprayEWS.

Very often on external penetration tests we perform a reconnaissance phase that might yield us some email addresses or usernames of an organization. If we can successfully find valid credentials for any one of them, and the organization has an Outlook Web Access or Exchange Web Services portal it is possible to download the entire Global Address List from the Exchange server. So, from one valid credential we can now have access to all email addresses for every employee of an organization.

Additionally, I wrote in two modules for password spraying Outlook Web Access and Exchange Web Services to MailSniper. Password spraying is an attack where instead of trying to brute force many password attempts for a single user account we try one password across many user accounts. This helps avoid account lockout and will still result in us obtaining valid credentials as users still pick passwords like “Fall2016”. Both of the functions are multi-threaded. Just pass the -Threads option and specify a number of threads (15 seems to be a pretty good starting point).

This is a cross-post from the Black Hills Information Security blog. You can read it here: http://www.blackhillsinfosec.com/?p=4975

Overview

The traditional methodology of a remote attacker who has no preconceptions of a target network used to be fairly static. With organizations moving to “the cloud”, the approach attackers are taking is going to change drastically if it hasn’t already. In this blog post I am going to detail why, if your organization has moved its assets to the cloud, an attacker is likely going to make that their primary attack focus. They will likely succeed, and you will likely not know that it happened.

Cloud Computing Primer

Scalable storage, easy collaboration between employees, and cost savings by eliminating the need for a data center are all benefits that organizations see in “the cloud”. From a security perspective there are definitely some added benefits of cloud computing, but I am going to discuss a few shortfallings. One very common misconception is that “the cloud” is some mystical flying entity that protects your data, saves you valuable hard drive space, and shades you from the sun.

This is the definition of ‘cloud computing’:

Cloud Computing: n. the practice of using a network of remote servers hosted on the Internet to store, manage, and process data, rather than a local server or a personal computer.

This is a cross-post from the Black Hills Information Security blog. You can read it here: http://www.blackhillsinfosec.com/#!Password-Spraying-Outlook-Web-Access-How-to-Gain-Access-to-Domain-Credentials-Without-Being-on-a-Targets-Network-Part-2/c1592/56c1f10e0cf2365fef58cce1

This is part two of a series of posts (See part 1 here) where I am detailing multiple ways to gain access to domain user credentials without ever being on a target organization's network. The first method involves exploiting password reuse issues where a user might have reused the same password they used for their corporate domain account on another external service. The second method is what I think is a far more interesting way of gathering user credentials that involves discovering a target organization's username schema, followed by password spraying user accounts against an externally facing service that is hosted by the target organization (for example an Outlook Web Access portal). Other methods will follow these posts.

In part 2, I will detail how an attacker can discover a target organization’s username schema and perform password spraying attacks against an externally facing service. 

The Dangers of Metadata and Publicly Facing Authentication Services 

Very commonly on assessments we tend to look for documents that are hosted by a target organization, and are publicly available to download. The reason we do this is because we find that very commonly organizations do a very bad job of scrubbing the metadata attached to the items they post publicly. Some very interesting things can be found in the metadata that gets attached to files.

For example, if you take a photo with your cell phone and you have GPS enabled, many times that GPS location information will be attached to the picture itself. From an operational security perspective if you were to take a photo of a secure location and have GPS enabled, then posting that picture online might reveal the actual coordinates of the location you took the photo.

When we look at analyzing metadata of Word documents, Excel files, PDFs, PowerPoint  presentations, and more that organizations post publicly,  we find very often that we can actually gain access to computer names, folder structures, as well as user names of those that created the files themselves. A great tool for quickly finding metadata and analyzing it in publicly available files of a target organization is called FOCA.

You can download FOCA here: https://www.elevenpaths.com/labstools/foca/index.html

FOCA simply performs Google and Bing searches with the “filetype” parameter. You can provide Google with a search like the following to search for all of the PDF files associated with the “targetorganization.net” domain: “site:targetorganization.net filetype:doc”. If you provide FOCA a target domain it starts with the top level domain and will subsequently find other subdomains where potential files are located. FOCA will then download any of these files and analyze the metadata attached to the files.

On a recent engagement I ran FOCA against the domain of the target organization that I was testing. When I looked at the metadata that FOCA was able to gather from the files that were being hosted publicly I found a large number of what appeared to be user names. In fact, I was able to discover what appeared to be their actual naming convention. This naming convention did not appear to be a random or hard to guess at all. What I mean by that is that I was able to very easily craft a list of every possible combination of their username schema.

For example, imagine a username schema that starts out each username with the word ‘emp’, and then simply appends the three letter initials of the employee (abc). So a possible full username would be ‘empabc’. The total number of three-character permutations of the letters ‘a’ through ‘z’ is 17,576. So, to hit every possible username combination from ‘empaaa’ through ‘empzzz’ is 17,576. I generated a list containing each of the possible permutations.

Password Spraying Outlook Web Access

So, now that I had a list of possibly every username combination for the target organization what could I do next as an external attacker? Next, an external attacker would have to locate some sort of external service that performs domain-based authentication. One such service that does this that we find very often is Microsoft’s Outlook Web Access (OWA). Organization’s provide the ability for their employees to access their email remotely through services like OWA. The authentication that happens when a user logs into OWA is typically domain-based, meaning that the credential used to authenticate is checked against the domain for validity.

After locating an external OWA portal an attacker could brute force passwords, but will quickly lockout accounts if a lockout threshold is in place. A far more superior way of performing password attacks is called password spraying. Password spraying involves attempting to login with only one (very strategically chosen) password across all of the domain accounts. This allows an attacker to attempt many more authentication attempts without locking out users. For example, if I were to attempt to login to every account with the password ‘Winter2016’ it is very likely that someone at the target organization used that password and I will now have access to their account.

Some things to consider when performing an external password spray attack:

I once again used Burp Suite’s Intruder functionality to submit one login attempt for each possible username using one password. Performing a password attack in this manner limits the risk of locking out accounts as only a single login attempt is performed for each account. For example BHIS submitted the userID ‘targetorg\empaaa’ with a password of ‘Winter2015’. After this attempt the same password would be tried with ‘targetorg\empaab’, and continue on all the way to ‘targetorg\empzzz’.

To do this I first setup Burp Suite to intercept all of the requests leaving my browser. I attempted to login to the OWA portal with a userID of ‘targetorg\test’ and a password of ‘Testing123’. The POST request to the OWA portal looked like the following:

I then sent this request to Intruder. For this first example we will leave the attack type as ‘Sniper’. In Burp Intruder I specified only one payload position. The username is all that is going to change during the attack so this is where we add the payload position. The password will remain ‘Testing123’ or whatever you set it to be (I highly recommend season and year like ‘Winter2015’).

On the payloads tab I now imported the list of probable usernames I generated.

One thing I noticed was that Outlook Web Access responds to the POST request by simply setting a cookie in the browser and redirecting to the root “/” page. OWA did this for every login attempt regardless of whether the login was valid or not. So, in order for Burp to follow through with the authentication process we need to set one more setting before launching the attack. On the Options tab of Burp Intruder at the very bottom select the option to “Follow redirections” for “On-Site only”. Also, click the checkbox to “Process cookies in redirections”.

Starting the attack now one can see where Burp Intruder is following each of the redirects that occur during the authentication process to OWA. The only thing left to do is to sort by the length of the response as valid authentication attempts responded with a shorter response length. In the screenshot below OWA redirects four times before hitting a page indicating a successful login.

I ultimately was able to gain access to a large number of accounts via this technique. As can be seen in the screenshot below the requests that generated a response length of around 4371, and 1630 were valid user credentials. The requests that generated a response length of 12944 were failed login attempts.

In the scenario I’ve demonstrated above I was utilizing the ‘Sniper’ functionality in Burp. This was mainly to avoid account lockout and only change the userID field. Being in close contact with my target organization I knew what the actual lockout threshold was as well as the observation window. In order to maximize the effectiveness of my password spraying I utilized Burp Intruder’s “Cluster Bomb” attack. With the Cluster Bomb attack you can specify two payload positions. I selected the username and password fields as my payload positions.

Cluster Bomb will also allow you to specify two lists to use with each payload position. So I left the username position the same as previously with my list of potential users. I then crafted a list of 10 or so passwords that I thought would work nicely to password spray with.

 The Cluster Bomb attack will now iterate through all of the usernames with one of these passwords at a time. Once the spray is done for one password it will move onto the next. For example the spray would go through the entire username list with a password of Winter15, then after that spray is finished it would move onto Winter16. With my list of 17575 usernames the time it took to spray the entire list with one password was far out of the observation window in terms of lockout so I didn’t have anything to worry about there.

In the example I gave above I was currently assigned to perform an external network assessment and an internal pivot assessment for the target organization. After password spraying externally over the weekend before I was scheduled to begin the internal pivot assessment I gained access to a total of 130 valid user credentials. The target organization did not detect any of the password spraying activity through their external portal. It is probably safe to say that an attacker could password spray for weeks on end gaining access to many more accounts via this technique.

In this post I focused on password spraying against OWA specifically. There are many other services that this same type of attack could apply to. For example, an attacker can perform password spraying attacks against Microsoft RDP servers, SMTP servers, SSL VPN’s, and more. A great tool for doing this against most of these services is called Patator and can be found here: https://github.com/lanjelot/patator

Just to recap, the steps of this approach to gathering user credentials follow:

Recommendations: