Home

Pivoting through your Exchange Server

Ruler is a tool that allows you to interact with Exchange servers remotely, through either the MAPI/HTTP or RPC/HTTP protocol. The main aim is abuse the client-side Outlook features and gain a shell remotely.

The full low-down on how Ruler was implemented and some background regarding MAPI can be found in our blog posts:

• Ruler release
• Pass the Hash with Ruler
• Outlook forms and shells
• Outlook Homepage attack

Using Ruler

• Getting Started
• Brute-Force
• Rules
• Forms
• Homepage
• GAL

Presentations and Videos

Ruler was presented at Troopers17, there is recording of the talk. And the slides.

At the same time, Liniaal was released. This provides a stealthy communication channel through Exchange and was built using the Ruler library.

The forms and homepage attacks were presented at EkoParty13.

Tips and Tricks

A few common issues that you may run into.

Office365

Ruler was developed against an Office365 hosted domain and has full support for Office365. If you know a domain is hosted in Office365, you can skip most of the autodiscover schenanigans but using the --o365 global option. This will take you straight to the Office365 domain and perform the relevant actions to get you authenticated.

It is important to note that fully Office365 hosted domains (not ADFS), authenticate with email addresses, rather than usernames. So supply the full email address and leave out the --username option to gain access.

PtH - Passing the hash

Ruler has support for PtH attacks, allowing you to reuse valid NTLM hashes (think responder, mimikatz, mana-eap) instead of a password. Simply provide the hash instead of a password and you are good to go. To provide the hash, use the global flag --hash.

./ruler  --username validuser --hash 71bc15c57d836a663ed0b02631d300be --email user@domain.com display

For more information on how the PtH attack works in Ruler, see our blog post: Pass the hash with Ruler

--domain is not always needed

Another interesting thing to note, is that Ruler doesn't require the --domain for authentication or autodiscover in most cases. The autodiscover service works off the email addresses domain. If you find that authentication is failing, it might mean that you require the internal domain name as part of the authentication string. For this, you will need to add --domain DOMAIN to your requests. This will ensure that NTLM auth does DOMAIN\USERNAME in the authentication sequence, instead of .\USERNAME.

Basic rule, use --domain with bruteforce (it uses this to figure out the autodiscover URL), otherwise leave it off.