A while back I wrote a post detailing a technique for pillaging .pst files. A .pst is a “personal storage folder” created by Microsoft Outlook containing email messages, contacts, appointments, and other information, and may be stored locally or on a centralized server. The approach I detailed in that post involved dropping a small binary on the machine hosting the .pst files, using it to convert the .pst to searchable text, and then using Windows shell commands to quickly search through the converted files for strings of interest.
So how might one pillage email in a Microsoft environment that uses Outlook but does not back up email to .pst files? Today we’ll explore some means to pillage Exchange using built-in functionality and management tools. The advantage provided by these techniques is that they are native to Exchange installations and don’t require or involve any outside software or tools. The disadvantage, as we shall see, is that they are fairly noisy.
Like the .pst blog, this post assumes that you have compromised the network and have moved on to the pillaging phase. It also presupposes that you are searching for a particular trophy or piece of information. Even after we have obtained domain administrator credentials, there are, at times, trophies that can elude the most experienced of pentesters. This could take the form of credentials to access a purpose-built system outside the Windows domain or the password to an encrypted file or database. Chances are good that those credentials have been stored or transmitted via email, especially when our target is a shared resource. The two approaches demonstrated in this post will allow you to search promising email accounts without having to acquire the credentials of the individual users to which they are tied.
The Setup
The simple portable lab I used for this example consists of a Windows Server 2012 R2 domain controller, an Exchange 2013 server, and a Windows 7 workstation. The basic techniques I outline will work in previous versions of exchange, though the specific location of the options or the management interfaces in use have changed in Exchange 2013. This example also assumes the target organization does not use “split permissions,” which divide the responsibilities (and privileges) for administering Active Directory and Exchange. However, using split permissions is uncommon in small-to-medium-sized organizations.
For our scenario, let’s assume our client has designated employee PII as a trophy. We have identified the HR Director (“User1”) via LinkedIn, and we have access to a file called “Employee Census.” However, the file is password-protected, and, thus far, our attempts to guess the password have failed. Perhaps “User1” has sent or received the password via email. We’ll use two techniques to search through mailboxes of interest. The first is to give ourselves full access to the targeted user’s mailbox; the second is to use built-in management features to search through a mailbox of our choosing.
Step 1: Add (or commandeer) a Mailbox
As noted above, these techniques leave a footprint, but are useful, especially when working under a time crunch. Both the options we’ll explore will require you to have control of a mailbox. Of course, this could be a mailbox to which you have credentials, but I don’t want to contaminate an actual user’s mailbox, so I’ll create a new one. How you approach this will depend on your scope and methodology.
Exchange 2013 relies pretty heavily on the web-based Exchange Admin Center (EAC), so I’ll use that here. The “mailboxes” section allows us to add a new user mailbox. The user receiving the mailbox can come from the list of Active Directory users, or the Administrator can create a new user right here. I’ll do the latter and create a new mailbox:
Notice that this user is automatically added to Active Directory:
If a client’s current configuration is not logging or alerting on this, then knowing what to look for in their logs will be useful for them going forward.
Step 2: Mailbox Delegation
Once our user’s mailbox is created, we can give ourselves full access to another users mailbox. However, this will be done from that user’s account options rather than our own. So we’ll back out to the account of “User1,” select the edit option, select “mailbox delegation,” and add our new user to the “Full Access” section:
Once that’s complete, we can log in to our recently created mailbox with the username and password we set, then open another mailbox without being required to enter any credentials. In Exchange 2013’s web interface, the default behavior is to load this new mailbox in a new window. Once its loaded, we can use the search function to quickly hone in on what we’re looking for.
Remember, the advantage of this approach is that we could do it immediately upon getting domain administrator credentials. If we thought combing through this user’s email would be useful, we didn’t have to locate their computer and use mimikatz to extract their credentials, or guess/crack their password. It’s also worth noting that giving yourself full access to another user’s mailbox is transparent to that user (what’re they going to do, receive an email notification?). However, when you interact with their mailbox, it’s as if they are doing it, so emails previously marked as unread will be marked as read after being opened, etc. Keep in mind that it may take a little while for this to propagate, and you can actually open the mailbox.
Alternate Step 2: The Search-Mailbox cmdlet
Now we’ll explore the second approach, which I think is cooler but may rely more on the environment you’re attacking and the way users and their roles have been established. When Exchange Management Tools are installed on a machine, they include the Exchange Management Shell, which is a version of Powershell with specific features for administering exchange. One of these, “Search-Mailbox,” allows us to make specific search queries on mailboxes of interest without manually giving ourselves full-access and logging in.
However, this powerful cmdlet is not, by default, available to just any old domain administrator. It belongs to administrators with the “Discovery Management” role. I endowed myself with this role within EAC by going to “permissions,” “admin roles” and editing the “Discovery Management” to add the administrative account I had compromised.
Now, when I log in to the Exchange Server (or any computer used to manage exchange with the Exchange Management Shell installed), I will have access to the “Search-Mailbox” cmdlet.
Using the cmdlet is straightforward. Its syntax is as follows:
Search-Mailbox -Identity “First Last” -SearchQuery “String” -TargetMailbox “DiscoveryMailbox” -TargetFolder “Folder” -LogLevel Full
Where Identity is the Active Directory username, SearchQuery is the string of text we’re looking for, TargetMailbox is the mailbox where emails containing that string will be sent (hence the need to control a mailbox), TargetFolder is the folder in that mailbox where they’ll go.
In this screen capture, I’m searching User1’s mailbox for any emails containing the string password. If discovered, they will be sent to my mailbox for perusal:
And the output upon successful completion:
Now we simply pop back over to the mailbox of the user we created and inspect the newly arrived email(s):
As you can see, we’re logged in as the user I created (RSM), but the email is from User1 to User3. It contains a password that I would never guess, nor could I brute force in less than several dozen years (which generally exceeds the amount of time we have allotted for an assessment anyway). And upon obtaining DA credentials, we were able to obtain that password within minutes, without bothering to identify that users workstation and obtain his or her credentials.
Happy pillaging.
digby sends.
