Abusing Exchange Mailbox Permissions with MailSniper

posted May 18, 2017, 11:46 AM by Beau Bullock


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.



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 -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 “” 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 -OtherUserMailbox


In the screenshot below I am using the “jeclipse” account to search’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 “”. 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 -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.


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.


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:

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:

HostRecon: A Situational Awareness Tool

posted Apr 19, 2017, 10:30 AM by Beau Bullock


HostRecon is a tool I wrote in PowerShell to assist with quickly enumerating a number of items that I would typically check after gaining access to a system. It can assist in providing situational awareness to a penetration tester during the reconnaissance phase of an engagement. It gathers information about the local system, users, and domain information. Probably the most important thing about it is that it does not use any ‘net’, ‘ipconfig’, ‘whoami’, ‘netstat’, or other system commands. I’ve had some security products alert on the use of those common commands/tools. Instead, those commands have been replaced with PowerShell and WMI queries.

On many pentests we are still seeing Windows 7 systems that only have PowerShell version 2.0 installed. To assist with backward compatibility for these systems I’ve avoided using many of cmdlets available in PowerShell version 3.0 and up that would have provided the functionality I needed.

Common Security Product Detection

I wanted a tool that had the ability to help quickly identify security products in use on a system. HostRecon attempts to enumerate common security products on the system including AV, IDS, AppWhitelisting, Behavioral Analysis, etc. This will be an ever-changing/ever-growing list that I will attempt to keep as updated as possible. I’ve asked my colleagues at BHIS to help me grow this list of security products by sending me any new processes and product names they see on pentests.

Situational Awareness

HostRecon provides information from a target system that will assist a pentester in crafting further attacks. Prior to blindly running payloads on a system it’s good to know what security protections are in place. Is the system running application whitelisting? Is there a web proxy in use for Internet traffic? Is the local administrator’s password possibly randomized? HostRecon will attempt to answer some of these questions. Having a good situational awareness prior to moving forward should increase your chances of success.

Here is a full list of things it currently checks:

  • Current Hostname – Gathers the hostname of the local system
  • IP Information – Gathers IP info; Alternative for ‘ipconfig’
  • Current Username – Gathers current username; Alternative for ‘whoami’
  • Current Domain Name – Gathers current domain name
  • All Local Users – Gathers local users from the system; Alternative for ‘net users’
  • Local Admins Group – Gathers local admins group members; Alternative for ‘net localgroup administrators’
  • Netstat Information – Gathers listening and established connection info; Alternative for ‘netstat’
  • DNS Cache Information – Gathers DNS cache information; Alternative for ‘ipconfig /displaydns’
  • Shares – Gathers Share info; Alternative for ‘net use’
  • Scheduled Tasks – Gathers any scheduled tasks from the system; Alternative for ‘schtasks’
  • Web Proxy Information – Determines if a web proxy is in use
  • Process Listing – Lists out all current running processes on the system
  • AntiVirus Information – Checks if AV is enabled and what product is running
  • Firewall Status – Determines if the local firewall is enabled or not
  • Local Admin Password Solution (LAPS) – Attempts to locate the DLL used when installing LAPS.
  • Domain Password Policy – Gathers the domain account password policy
  • Domain Admins Group Members – Lists the members of the Domain Admins group
  • Domain Controllers – Lists any Domain Controllers
  • Checks for Common Security Products – Analyzes the process listing for common security product processes and names

Egress Filter Check

Invoke-HostRecon also includes a functionality for assessing egress filtering from the system. The -Portscan flag can be passed to initiate an outbound portscan against to help determine open ports allowed through an egress firewall. (Credit for the Portscan module goes to Joff Thyer). By running ‘Invoke-HostRecon -Portscan’ it will perform an egress check against as well.

HostRecon can be downloaded here:

Start a PowerShell session on a system
C:>powershell.exe -exec bypass
Import the script
PS C:>Import-Module HostRecon.ps1
Run HostRecon
PS C:>Invoke-HostRecon

To perform an egress filter check on the top 100 ports run the following command:

PS C:> Invoke-HostRecon -Portscan -TopPorts 100

If you have any other ideas that you would like added into HostRecon please shoot me an email, contact me on Twitter (@dafthack), or open an issue on Github. Please keep in mind I am avoiding the use of any system tools (‘ipconfig’, ‘net’, ‘netstat’, ‘arp’, etc…) and also avoiding any PowerShell 3.0 and up cmdlets.

This is a cross-post from the Black Hills Information Security blog here:

Bypassing Two-Factor Authentication on OWA and Office365 Portals

posted Nov 7, 2016, 5:52 AM by Beau Bullock


UPDATE as of 3pm MST 11/2/16: This blog post demonstrates a two-factor authentication bypass technique against Microsoft Outlook Web Access where the third-party 2FA vendor was DUO Security. It should be stated that this is NOT a vulnerability in DUO Security’s product. It is a problem in which Microsoft Exchange server exposes the Exchange Web Services interface unprotected by 2FA alongside OWA. 

UPDATE as of 11:15am EST on 11/4/16 BHIS has retested the portion of this article detailing a bypass against Office365 Multi-Factor Authentication and it does indeed appear to not work. Some individuals have pointed out that they were getting 401 Unauthorized error messages when connecting in via EWS with MFA fully enabled on a user. When testing against the initial test user BHIS tested against EWS on O365 it now produces the same 401 error results when using a password to authenticate. BHIS believes that the results obtained previously were due to a delay in which Office365 MFA was denying access to Exchange Web Services after recently enabling it for a user. A video demonstrating this has been put together here:

Additionally, a very detailed post regarding the various protocols of Exchange has been put together here:

ORIGINAL POST: At DerbyCon 6.0 I released a tool called MailSniper for searching mailboxes for sensitive data in a Microsoft Exchange environment. MailSniper utilizes Exchange Web Services (EWS) when connecting to an Exchange server to retrieve messages from a user’s inbox. EWS is a web-based API enabled on Exchange servers that Microsoft recommends customers use when developing client applications that need to interface with Exchange. The API allows for applications to have the ability to interact with email messages, contacts, calendar, and more from user’s mailboxes.

While at DerbyCon I sat in on a talk called “Outlook & Exchange for the Bad Guys” by Nick Landers. It was an awesome talk that I highly recommend checking out. During his talk Nick received a question from the audience in regards to whether two-factor authentication (2FA) would stop the attacks he mentioned during the talk. Nick replied with a statement I found very interesting. He said “I’ve seen some organizations lockdown 2FA on OWA. So when you go to the Outlook Web Access you have to supply a token before you can finish logging in. That wouldn’t stop a lot of these attacks because two-factor auth doesn’t apply to EWS or the NTLM auth on the Autodiscover page.”

...Continue reading on the Black Hills Blog here:

Attacking Exchange With MailSniper

posted Oct 7, 2016, 9:15 AM by Beau Bullock

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).

...Continue reading on the Black Hills Blog here:

Introducing MailSniper: A Tool For Searching Every User's Email for Sensitive Data

posted Sep 29, 2016, 6:52 AM by Beau Bullock

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.

MailSniper is available for download here:

Oftentimes, on penetration tests we find ourselves having elevated access (Domain Admin) within an organization. Some firms stop there thinking that DA is the end goal. But it’s not. “Getting DA” means nothing to most members of the C-suite level if you can’t provide a picture of what that means in terms of risk. One of the best ways to demonstrate risk to an organization is to show the ability to gain access to sensitive data. Sensitive data to an organization varies greatly from company to company. Some common examples of sensitive data are: customer information, credit card numbers, Social Security numbers, employee information, intellectual property, industrial control systems/SCADA, health care data, etc.

According to the 2016 Mandiant M-Trends Report (PDF) in 2015 the median number of days organizations were compromised before they detected the breach was 146. Having that much time inside of any network allows attackers to slowly and stealthily gain operational awareness, determine what the organization deems sensitive data, locate sensitive data on the network, compromise sensitive data, and ultimately exfiltrate it. How do we as pentesters go about providing that same illustration in terms of risk to an organization when we typically only have less than 5 days to complete an assessment?

In this blog post I will detail a new tool I have developed to assist in the location of sensitive data on a network by searching through every employee’s email for specific terms. The tool is called MailSniper.

...Continue reading on the Black Hills Blog here:

How to Build Your Own Penetration Testing Drop Box

posted Sep 29, 2016, 6:48 AM by Beau Bullock

I compared three single-board computers (SBC) against each other with a specific goal of finding which one would serve best as a “penetration testing drop box”, and maintain an overall price of around $110. Spoiler Alert: At the time I tested these Hardkernel’s ODROID-C2 absolutely destroyed the competition in this space. If you want to skip the SBC comparison and jump right to building your own pentest drop box you can find the instructions below and also here.

A few weeks ago I was scheduled for an upcoming Red Team exercise for a retail organization. In preparation for that assessment I started gathering all the gear I might need to properly infiltrate the organization, and gain access to their network. Social engineering attacks were explicitly removed from the scope for this engagement. This meant I wasn’t going to be able ask any employees to plug in USB devices, let me in certain rooms, or allow me to “check my email” on their terminals (yes this works).

Essentially, what were left at that point were physical attacks. Could I get access to a terminal left unlocked and perform a HID-based (think Rubber Ducky) attack? If the system wasn’t unlocked, perhaps a USB-Ethernet adapter (like the LAN Turtle) could be placed in line with the system to give me a remote shell to work from. Even if I could get physical access, without any prior knowledge of the network’s egress filtering setup, was I going to be able to get a shell out of the network? So this led me down the path of building a pentest drop box that I could place on a network, could command over a wireless adapter, automatically SSH out of a network, and just be an all-around pentesting box.

...Continue reading on the Black Hills Blog here:

Storm Chasing: How We Hacked Your Cloud

posted Jun 2, 2016, 11:53 AM by Beau Bullock

This is a cross-post from the Black Hills Information Security blog. You can read it here:


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 essentially means that your data that previously would have been on your own system is just on someone else’s system now, and you are renting space from them. There are many considerations that must come to mind when you look at handing your data over to a cloud provider.

  • Is the cloud provider doing their own due diligence when it comes to network security? Many people see the likes of Google, Microsoft, and Amazon and immediately believe that because these services are so popular and widespread that they must be secure. If one of these organizations had a breach it would be bad for a lot of people.

  • Is the data physically secure? Your data is physically sitting on a hard drive somewhere inside one of the data centers of the cloud provider you choose. What are they doing to protect physical access to those?

  • One concern I’m not going to get into in this post but is definitely one many have is this: Are the cloud providers themselves being ethical when it comes to the handling of your data? Are they able to access whatever they want of yours? If so, would you know if they do? …And what about if a government entity requests data from them?

Sure, cloud computing is convenient. But sacrificing security for convenience is a fatal mistake.

External Network Pentest Forecast

When it comes to an external network architecture most organizations think that there are only two possible attack vectors for an attacker to gain access to internal resources. Most think that an attacker must either find a remotely exploitable flaw in an externally exposed system, or they must phish an employee of the organization.

Of course there are a multitude of other ways an attacker might gain access to an organization’s internal network but these typically involve some sort of physical access. For example, many organizations offer wireless networks and occasionally do a poor job at segmenting guest networks from corporate networks. There is also the risk of a malicious insider who already has physical access to an internal asset of an organization. With organizations moving more and more of their internal data systems, assets, and communication architecture to the cloud this adds a new attack vector for remote attackers.

In two other blog posts I’ve written I detailed ways an external attacker can gain access to domain credentials without being on a target network. In part 1 I discussed how employees are reusing the same passwords on personal accounts as corporate accounts and how attackers can find these. In part 2 I discuss password spraying Outlook Web Access portals.

Both of these techniques can result in an attacker gaining access to domain credentials, but an attacker who wants to compromise an organization’s assets would still need access of some kind to a target network. This would historically mean the attacker would still need to find some sort of VPN access, or phish an internal employee. With more movement of corporate assets to cloud infrastructures it is becoming more likely that an attacker simply needs a valid credential and a web browser to access sensitive corporate data.

Case Study: Let’s Go Hack A Cloud

Very recently a coworker of mine Derek Banks (0xderuke) and myself were performing a “Blackbox External Network Assessment”. The blackbox nature of this assessment means that we had no scoping information. No target ranges were provided to us so we were on our own to perform recon and discover where this company’s external assets were. Through our recon we found a few external hosts, but the attack surface was very slim.

Through bruteforcing of subdomains we discovered an ‘autodiscover’ subdomain. The ‘autodiscover’ subdomain is commonly used to assist in the setup of email clients so that the user simply needs to enter an email address and password. This is very commonly associated with Microsoft Exchange environments. For this particular customer, when we navigated a web browser to the autodiscover subdomain we were redirected a Microsoft Office 365 login portal. At this point we contacted the customer to determine if the Microsoft Office 365 portal was in scope for testing. They confirmed that it was. (Note: when pentesting third-party services of any kind it is very important that the organization communicate that an assessment is going to occur with the third-party. Most third-party orgs have a pentest authorization form the organization can fill out to authorize the pentest. See below for a list of these.)

During our reconnaissance phase we always try to find both valid email addresses as well as usernames. For this particular company we had discovered a relatively low number of valid email addresses, and no usernames. Nevertheless we proceeded in attempting password-spraying attacks. Even with the low number of email addresses we had discovered we were still able to password spray a valid user credential using the always-reliable, season-year combination (Spring2016).

Here’s where the magic comes into play when it comes to attacking cloud infrastructures. We started with a very small number of valid email addresses, and then password sprayed one. This organization did not utilize two-factor authentication so at this point we had access to this particular user’s Office 365 account, which had access to Outlook mail, Sharepoint, OneDrive, etc. Before we proceeded in pillaging the Office365 services we wanted to see if we could find any more valid email addresses. So, naturally we started poking around Outlook. The thing we quickly learned was that the “Address Book” gave us pretty much everything we needed. It included the email addresses, usernames, phone numbers, and full names of every employee in the company. At this point we now had a complete list of everyone’s email address in thecompany.

Outlook Address Book

We continued on with more password spraying, this time with a full email list. Many more credentials were obtained and we now had access to the cloud infrastructure as a number of different types of users with different roles in the company. For each user the types of files and things we could access in the cloud were different. But just like a file share on an internal network, the permissions must be configured so that only the correct users are able to access protected resources.

Anytime there is a collaboration/documentation platform like Sharepoint used by an organization there is commonly a treasure-trove of data to be found there. We found a ton of very sensitive information being stored in this organization’s cloud. While we navigated through the Sharepoint site and located sensitive company information we more importantly found access to the organization’s actual internal infrastructure.

Sharepoint, like pretty much every other cloud service, has a very useful ‘search’ function. This is useful to employees to find the documents they are looking for fast but is also useful to an attacker if the organization is storing sensitive documents there. During our reconnaissance phase we didn’t discover any sort of remote access systems like a VPN server. This was very much intriguing to us as we assumed that this rather large organization had users accessing their network remotely. We performed a search in their Sharepoint site for “VPN”. Low and behold we found a document detailing exactly what VPN client to install, where to direct it to connect to, and the “PIN” that must be used along with valid user credentials to authenticate to the organization’s network.

Of course two-factor wasn’t enabled on the VPN as well. We VPN’d into the network as one of the users we password sprayed. From there we escalated privileges to domain admin through our typical means.


While this story ended up with us accessing an organization’s internal network infrastructure during a blackbox external network assessment, we did it by hacking our way through the organization’s cloud infrastructure. This particular assessment was focused on attacking the Microsoft Office 365 platform, but could easily be performed against similar cloud infrastures like Google, or Amazon’s AWS.

If you are an organization that utilizes cloud services to host your organization’s data, email, etc. please implement two-factor authentication. Had two-factor authentication been enabled during the case study above we would have been stopped way earlier.

Remember that if you are going to perform a pentest against a third-party service get authorization first. I’ve crafted a list of a few of the auth forms below.

Pentest Authorization Forms

Microsoft Azure –

Amazon AWS –

Google Cloud Platform –

       -Interestingly enough Google says you don’t have to contact them.

Poking Holes in the Firewall: Egress Testing With AllPorts.Exposed

posted May 3, 2016, 9:59 AM by Beau Bullock

If you have been even remotely in touch with technology in the past thirty years you have probably heard of this thing called a “firewall”. If not, a “firewall” decides what does and does not get to proceed through it. Most organizations have one of these protecting their network from the rest of the Internet. Some organizations place them in the most opportune spots to segment off specific areas of their internal network. The system you are using right now to read this blog post most likely has a firewall built-in.

The general consensus about what a firewall does is that it keeps “bad stuff” from entering a protected network or system. But firewalls can also keep things from leaving a network or system. This is called “egress filtering”.

Why Should We Care What Leaves?

The simple answer is the more ports allowed out, the easier it is for an attacker to establish command and control. If there are no outbound filters put in place an organization can quickly lose visibility into what is leaving the network. This can lead to malware infections, command and control sessions going unnoticed, or insider employees getting around corporate network policies.

If you are the one in charge of the firewall at your organization, how do you go about knowing what is allowed out of your network quickly without diving into your firewall rule sets?

If you are a pentester, how can you quickly find out what ports are allowed out of a network that can be used as a command and control channel?


AllPorts.Exposed is an Internet-resident system with (as the name suggests) all 65535 TCP ports open on it. If you were to portscan it from a system/network without firewall protection you should see that all ports are “open”. Now, if you were to portscan this system from within your network protected by a firewall, and you see open ports, these ports can be assumed as being allowed outbound through the firewall.

How To Test It?

Yes, you could use something like Nmap to do a simple portscan but I prefer PowerShell for this task as it is built into Windows operating systems. Often-times, when we are performing a pentest we are working from a Windows-based system and are typically not an administrator user. So, installing external tools can be difficult.

Here is a short PowerShell portscanning script you can use to test ports 1-1024 against

  1. Open up a command terminal.
  2. Type ‘powershell.exe -exec bypass’ and hit enter.
  3. Copy the below script into the terminal window and run it.
1..1024 | % {$test= new-object system.Net.Sockets.TcpClient; $wait = $test.beginConnect("",$_,$null,$null); ($wait.asyncwaithandle.waitone(250,$false)); if($test.Connected) {echo "$_ open"}else{echo "$_ closed"}} | select-string " "

In the following screenshot you can see where the script prints ‘open’ to the terminal window for ports that were discovered as being open.

Alternatively, if you would like to just check for certain ports you can comma-separate each port you would like to scan at the beginning of the script in place of “1..1024”. For example, the following script will only scan ports 21, 22, 23, 25, 80, 443, and 1337.

21,22,23,25,80,443,1337 | % {$test= new-object system.Net.Sockets.TcpClient; $wait = $test.beginConnect("",$_,$null,
$null); ($wait.asyncwaithandle.waitone(250,$false)); if ($test.Connected){echo "$_ open"}else{echo "$_ closed"}} | select-string " "

Here is the same script, but this time we are testing the top 128 ports in use on the Internet as defined by the Nmap project.

80,23,443,21,22,25,3389,110,445,139,143,53,135,3306,8080,1723,111,995,993,5900,1025,587,8888,199,1720,465,548,113,81,6001,10000,514,5060,179,1026,2000,8443,8000,32768,554,26,1433,49152,2001,515,8008,49154,1027,5666,646,5000,5631,631,49153,8081,2049,88,79,5800,106,2121,1110,49155,6000,513,990,5357,427,49156,543,544,5101,144,7,389,8009,3128,444,9999,5009,7070,5190,3000,5432,3986,13,1029,9,6646,49157,1028,873,1755,2717,4899,9100,119,37,1000,3001,5001,82,10010,1030,9090,2107,1024,2103,6004,1801,19,8031,1041,255,3703,17,808,3689,1031,1071,5901,9102,9000,2105,636,1038,2601,7000 | % {$test= new-object system.Net.Sockets.TcpClient; $wait = $test.beginConnect("",$_,$null,$null); ($wait.asyncwaithandle.waitone(250,$false)); if($test.Connected){echo "$_ open"}else{echo "$_ closed"}} | select-string " "

In conclusion, knowing what ports are allowed out of a network is very important for both pentesters and network admins. Each port allowed outbound from a network creates an additional exit point for attackers to utilize. BHIS recommends locking down egress traffic to only the ports required for the business to function. If possible, implement a web proxy and only allow outbound web traffic from it. Block all outbound traffic from client systems, and force their web browsers to use the web proxy to perform web browsing.

REVIEW: Kali Linux Web Penetration Testing Cookbook

posted Mar 29, 2016, 9:07 PM by Beau Bullock   [ updated Mar 29, 2016, 9:13 PM ]

I perform pentests against web applications on a regular basis amongst other types of pentesting including internal network assessments, external network assessments, phishing, wireless, C2, pivot tests and more. In the past two years I've pentested around 40 different web applications for various organizations. I read the Kali Linux Web Penetration Testing Cookbook, and wanted to share my thoughts on the book.

This is a great book for introducing webapp attack vectors to new pentesters. There might be a section or two that seasoned pentesters find useful. I felt the author did a great job describing the tools and techniques in the book. The book lacks details into the underlying web protocols so don't expect to become an "expert" of all the intricacies involved in web applications after reading this book. I also feel there were a few items included that were a bit off topic and probably should not have been included in this book. That said, I give this book a 4 out of 5. 

Ok... the longer version is next. I've provided a brief outline of what is included in each chapter below, as well as what I felt was either awesome about the chapter or what I felt was missing in the "Comments" section.

-The author describes the book as being designed for many types of readers including those who want to go beyond general computer science study, application developers, and even seasoned security pros.
-States the book will include some possible intermediate or advanced exploitation by chaining attacks together.

Chapter 1 - Setting Up Kali
-Downlading Kali, and updating it
-Using OWASP Mantra - firefox plugin
-Setup Iceweasal with addons (tamperdata etc.)
-Using Owasp-bwa vm and BWapp Bee-box as target vuln machines
-Download Windows 7 IE8 VM as client for MitM attacks

There were no instructions on installing Kali. The book jumps straight from downloading it to updating it. Some readers might have trouble installing it. Also, the book is focused on installing Kali as the host OS. I would bet that the majority of readers who are jumping into web application pentesting will probably want to install Kali as VM. I was very happy to see that the author is putting the VM's to good use. 

Chapter 2 - Reconnaissance
-Nmap - shows basic network scan
-WAF detection with Nmap script http-waf-detect, http-waf-fingerprint, and wafw00f
-Looking at the source code of a page to identify vulnerabilities. Locating hidden fields that might be alterable
-Cookies manager+ to edit cookie values
-Looking in robots.txt for hidden dirs.
-Dirbuster to find hidden dirs - demos a basic wordlist but doesn't mention Dirbuster's wordlists (mentioned later when demoing Zap proxy forced browse)
-Cewl for creating wordlists from site content.
-Using John and the wordlist generated by Cewl to mangle a more complex wordlist with John's rules.
-Zap forced browse

This chapter does a decent job of covering recon for a webapp but I might add that during recon for a webapp Google can be your best friend. I discuss that in more detail in the next comments section. Also, is a good resource for finding what technologies a webapp is utilizing. 

Chapter 3 - Crawlers and Spiders
-Use wget and HTTrack to download website for offline analysis
-Using Zap and Burp to spider a site
-Burp's repeater to repeat requests
-Using webscarab to spider

Three different tools were demonstrated to perform the same task of spidering a site. Two tools were demonstrated to make a local copy of the site. The author did not mention what the purpose of creating a copy of the site was for or why this is useful. This section could be improved by spending less time on separate tools and more on focusing the spider engine. There are times where sites are so big that you may want to limit the spider's scope to only a certain directory and to only recurse a certain depth.

I would also add that Google has already done a good job of this. Using "Google hacking" techniques a pentester can find sensitive directories, and files without spidering at all. This can be a most valuable technique when the goal is to be stealthy.

Chapter 4 - Finding Vulnerabilities
-Hackbar Firefox addon - second address bar that is not affected by redirections, and allows  POST modification
-TamperData to modify requests
-Using Zap and Burp to intercept and modify requests
-Identifying XSS
-Uses DVWA XSS reflection exercise with basic alert script
-Error based SQLi with DVWA
-Blind SQLi
-Session cookie vulns - Mentions secure and httponly flag
-Using sslscan to get SSL info from a site
-Testing for LFI and RFI
-Detecting Poodle with Nmap script

While some more demonstrative examples are included later on in the book there was no information about why XSS is bad in this section. It could have provided a test case to demonstrate risk. There are a number of vulnerabilities that could be discovered through manual testing that were left out from this section. None of the following vulnerabilities were covered: CSRF (covered in advanced exploit chapter later on, but how to discover it), username harvesting, account lockout controls, session fixation, weak session token entropy, privilege escalation across access roles, insecure direct object reference (again, included later on in the book), etc.

I really like how the author is demonstrating some manual techniques prior to jumping into automated scanning. 

Chapter 5 - Automated Scanners
-Nikto scanner
-Wapiti scanner
-Zap automated scanner
-Using w3af scanner
-w3af has command line interface in addition to GUI
-vega vulnerability scanner - has ability to do auth to webapp but lacks reporting
-Using wmap as a scanner

Automated scanners can help speed up the process of a pentest. Being familiar with different types of scanners can help in various situations so I appreciate the inclusion of multiple tools. Although many tools were listed, I didn't feel that any real insight into what to do with the output of the scans was given. 

Chapter 6 - Exploitation - Low Hanging Fruits
-Uploading a PHP webshell to execute commands on the server
-Command injection - appending system commands to get Netcat shell is demonstrated
-XML External Entity Injection - very nice description and example of XXE. Also, the author demonstrates how it can be used to run commands when combined with a webshell upload vuln.
-Brute forcing passwords with THC-HYDRA
-Brute forcing passwords with Burp Intruder and wordlists
-Exploiting stored XSS to get a victims browser to visit an attacker hosted webserver with a PHP script to store cookies
-Nice manual SQLi walkthrough
-SQLMap for automated sqli
-Bruteforcing Tomcat logins with Metasploit module
-Tomcat war file upload with Laudanum web shell

I thought this section was probably the most valuable of the entire book with the next chapter being second. Good examples of some common exploit vectors were provided. Later on in the book the author dives into man-in-the-middle attacks and social engineering. I feel that these sections could have been left out and the author could have expanded chapters 6 and 7 as these two are truly the core of webapp testing. Having real world scenarios and potential exploit techniques really can help demonstrate to a reader what the risk is with certain vulnerabilities. I think the author did a fantastic job here. 

Chapter 7 - Advanced Exploitation
-Using Searchsploit to locate exploits in ExploitDB
-Exploiting Heartbleed
-Hooking a browser with Beef
-Manual blind SQL injection
-Using Sqlmap to gather data like current DB user and password hashes
-Decent CSRF walkthrough
-Decent Shellshock walkthrough 
-Cracking passwords with John and oclHashcat

More good examples were provided as in chapter 6. I think more information could have been provided regarding discovering particular vulnerabilities such as ShellShock, and CSRF. 

Chapter 8 - MitM attacks
-Using Ettercap to arp poison the network to MitM two systems
-Capturing packets with Wireshark
-Ettercap filters to replace data in web requests
-Use sslsplit to decrypt traffic after mitm (victim gets cert error)
-Spoofing dns to redirect requests

I'm not sure that I feel this chapter was necessary in this book. When approaching a web application pentest it is rare that the tester would need to demonstrate the risk of a MitM attack. The fact a user system can be attacked to create a MitM situation does not mean a vulnerability in the web application being tested exists. These are really "Network Pentest" techniques. 

Chapter 9 - Client Side Attacks and Social Engineering
-Harvesting login credentials with a scraped site using SET
-Creating a login harvester that actually logs the user into the real site.
-Creating a reverse shell Meterpreter exe 
-Browser autopwn Metasploit module
-Social engineering a user to run a malicious beef hook

Again, I'm not sure this chapter belongs here. There is a section in this chapter that explains how to create a Meterpreter payload, host the payload on an attacker's webserver, and then get a target to download it via social engineering. What does this have to do with webapp testing? I think between this chapter and the last the author could have expanded quite a bit on both webapp attack vectors, and the underlying protocols at use.

Chapter 10 - Fixing OWASP Top 10
-This chapter walks through the OWASP top 10 vulnerabilities and how to fix them. 

Comments: This chapter redeemed chapters 8 and 9 for me. It is rare that a "pentesting" book includes a very detailed chapter on actually fixing the vulnerabilities discovered through the techniques presented in the book. This chapter does this. As penetration testers we need to not only find the vulnerabilities, but also provide the best recommendations we can to fix them to the clients we are working with. 

Conclusion - 

The Good:
-The author portrays each concept taught in the book very well. His teaching style is very easy to understand and I think anyone can pick this book up and start learning.
-Many tools related to webapp pentesting that are built into Kali Linux are demonstrated.
-The majority of common vulnerabilities found in web applications are demonstrated.
-New web application testers will learn a ton!
-Seasoned web application testers might find a new trick or two.
-Great demonstrations of manual exploit techniques.
-For each of the tools demonstrated the author provides a number of additional options that may be useful.
-Chapter on fixing OWASP top 10 vulnerabilities is awesome. More pentesting books should include recommendations for fixing the vulnerabilities we find.

The Bad:
-No steps to install Kali
-No mention of Google Hacking
-Some common vulnerabilities were left out of the vulnerability discovery section including username harvesting, account lockout controls, session fixation, etc.
-No WPScan (Wordpress attack tool)
-MitM and Social Engineering chapters could have been replaced by more web application testing content

Password Spraying Outlook Web Access - How to Gain Access to Domain Credentials Without Being on a Target's Network: Part 2

posted Mar 9, 2016, 5:17 PM by Beau Bullock   [ updated Mar 9, 2016, 5:21 PM ]

This is a cross-post from the Black Hills Information Security blog. You can read it here:!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.

New Profile Pic!

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:


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 “” domain: “ 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:

  • Be extremely mindful of lockout thresholds! If you submit too many bad passwords in a given amount of time you are going to lock accounts out. Without being on the target network it is impossible to know exactly what the domain account policy enforces.
  • That being said, by default Windows default domain account policy does not enforce a lockout of any kind. This means that technically you could brute force any user’s password without locking them out. I have yet to run into an environment that does not have some sort of lockout policy. Very commonly I find that environments set their lockout policy to five (5) failed logins within a 30 minute observation window.
  • Just use one password for spraying every two hours. This is a reasonable window that will likely not get you into a situation where you are locking out accounts.
  • Be in close contact with your point of contact at the company to verify you are not locking anyone out.

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:


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

  1. Locate publicly available files with FOCA on websites of the target organization.
  2. Analyze the metadata from those files to discover usernames and figure out their username convention.
  3. Craft a list of their entire possible username space.
  4. Password spray against an external system that performs domain authentication (like Outlook Web Access) using the username list you generated.
  5. Profit?


  • Analyze all of the documents your organization is hosting publicly for information leakage via metadata.
  • Implement policies and procedures to scrub the metadata from anything that is going to be posted publicly.
  • Watch your OWA and any other external authentication portals for multiple failed login attempts and password spraying activity.
  • Create stronger password policies beyond the default 8 characters (we typically recommend 15 or more).
  • Force users to use two-factor authentication. In the event someone does password spray a user if two-factor authentication is enabled they won’t gain access to much.

1-10 of 72