I recently created the EWSToolkit off the back of an assessment for Exchange Client Access Services. I realise I committed it with basically no explanation, so this blog post will serve as a quick introduction and a look at perhaps one of its more interesting features.
The aforementioned assessment was of a public-facing CAS, which was part of a hybrid Exchange Online model. In this hybrid model, the Exchange Online service talks back to on-prem mailbox servers.
The only protocol required for this to work is Exchange Web Services (EWS) - and so a properly configured CAS has everything else disabled (notibly OWA and MAPI).
MailSniper already has the ability to password spray against EWS and you’ll generally get lucky with the usual candidates of Month+Year
, Season+Year
etc.
MailSniper has a couple more functions built around EWS, including downloading the GAL and searching emails. But we were looking for some more “aggressive” actions, akin to the old Ruler days. So we started looking into EWS and what type of capabilities it provides.
We discovered the EWS API, which has a metric boatload of operations available. Whilst scrolling through the list, InstallApp caught my eye. The InstallApp operation installs a mail app for Outlook in a mailbox. At first I was hoping this would include the older style C# VSTO Add-in, but it appears this is for the newer Web Add-in only.
Mike Felch and Beau Bullock presented a talk at the 2018 Wild West Hackin’ Fest called Covert Attack Mystery Box, where they talked about pushing a malicious Outlook Add-In via OWA to Beef hook a victim’s browser. James Williams also published a blog referencing Mike and Beau’s work, where he creates an Outlook Add-In to steal users’ emails (also via OWA), disguised as a “Windows Defender for Office 365” app.
So we combined the two ideas and made a “McAfee Total Protection” add-in that Beef hooks the desktop Outlook client.
You can create Office add-ins in Visual Studio by installing the “Office/SharePoint development” packages. The source code for our demo app can be found here. To leverage the add-in, you will need two hosts - one to host the Office add-in, the other, Beef.
Change all instance of https://attacker.domain
in McAfeeForOutlook.xml
for the domain where you’ll host the add-in; and https://beef/hook.js
in index.html
for wherever you’re hosting Beef. You can then right-click McAfeeForOutlookWeb
in VS and Publish
to a FolderProfile
(e.g. your desktop). You need then to simply upload the content to your host.
EWS (and OWA) will only let you install web add-ins that are hosted via HTTPS, and the Beef hook also needs to be HTTPS due to mixed content restrictions (EDIT: It think this later point is only applicable to OWA, not Outlook). LetsEncrypt is your friend.
The victim’s Outlook client will then show a new add-in in the ribbon.
The user must click the icon, there doesn’t seem to be a way to force-pin the add-in through EWS.
The static page shows the user everything is fine, but in the background, they are Beef hooked. I think there could be some other options here though - e.g. “Threat detected, click here and run this exe to fix”.
Obviously the best thing we can do now is Rickroll them.
Failed authentication from the password spraying creates 4776 Audit Failure
, where error code C000006A
is user name is correct but the password is wrong
. If email addresses were obtained via OSINT, it’s possible some of the email addresses belong to staff who no longer work there. In which case, C0000064 : user name does not exist
might be interesting to look for.
Because EWS uses NTLMSSP, the hostname of the “attacking” computer is recorded in the log. This can be changed to something more arbitrary, or to make it look like it’s coming from an internal machine.
Successful authentication creates a 4776 Audit Success
with with an error code of 0x0
.
Web add-ins don’t seem to appear under the normal Outlook Event 45
log. If anybody knows where/how you can audit when these are installed, please let me know.