Occasionally, we come across interesting scenarios that require thinking outside the box. For example: What if you've obtained a target user's credentials (via responder.py, brute-forcing, sniffing, keylogging, etc.), but don't have access to their workstation? This raises the question of whether a domain username and password could be useful without a workstation to authenticate against. Most organizations use Exchange for email, and make it externally accessible (via OWA or RPC over HTTPS). The AutoDiscover DNS record simplifies most of this process requiring a user to simply input his or her domain credentials into Outlook to setup the remote connection. Hopefully you can see where we're going with this. If not, read on!

Anyone familiar enough with Outlook will know it has a "Rules and Alerts" section that allows the user to automate certain actions based on message criteria. This feature is particularly interesting because the rules sync between all Outlook installs via Exchange. Most of the available rules actions pertain to modifying the mailbox, moving messages, categorizing items, etc. However, a few more devious actions immediately stand out, namely "Start Application".

This seems too easy! Sure enough, playing with the rule in the Outlook client highlights some pretty serious drawbacks. First, the target file needs to be locally accessible before it will save the rule. Second, it doesn't appear to support arguments when starting the application. Poking around a bit more, we find the ability to import or export rules under the "Options" menu. Here is where we can have some fun! Let's export a simple rule file and throw it into a hex editor.

Through the hex editor, we can find the data we're interested in. We have the name of our rule, the text that our subject trigger is using, and the path of the file to execute. Experienced reverse engineers may notice that each text sequence is preceded by the length of the string, and the string itself is encoded with UTF-16LE. After spending some time reversing the file format, we built a python script to automate the process of modifying the rules file to execute an arbitrary malicious file instead of the one initially specified! By default, the script uses an email subject trigger rule to execute the file path specified. Like any good hacker script, it's a little rough around the edges (e.g. no exception handling), but it's much better than manually editing the .rwz files in a hex editor. It can be found here: https://gist.github.com/monoxgas/7fec9ec0f3ab405773fc

Note: The API Outlook uses is ShellExecute with the "open" verb when running the file, so technically any file extension with an action defined for "open" is valid. These can be found in the registry under HKEY_CLASSES_ROOT. This is also why arguments don't work…for now.

That's cool, but we're always looking for ways to weaponize techniques in real-world attack scenarios. That being said, the next challenge became finding a way to remotely leverage the capability to obtain initial access, or pivot around tough network segmentation. This is where UNC paths, SMB, and WebDAV come in handy.

Assuming you already had internal network access, you could host your malicious files on an open Samba share with Kali, or simply drop them on an existing public file share on the network.

If attempting initial access, the target network would need to allow port 445 outbound (more common than you might think), in which case you just host the file on a public server.

Similar to #2, but WebDAV (port 80) is used to deliver the payload.

Again, focusing on real-world attack scenarios, we opted for method #3, using an external WebDAV server running on port 80 (because everyone lets port 80 out) to deliver the payload.

Note: Performing this attack via the internet might generate a user prompt warning of execution from an untrusted location.

So let's put all of this theory into practice and show an example attack.

The machines we'll work with:

Target Workstation On the internal network Target user has Outlook running

Public Web Server Internet facing server Running WebDAV with Apache Will deliver Powershell Empire as the payload

Windows VM Used to connect to target user's email account externally


Overview of the process:

Install Apache and WebDAV modules. Setup a public share with anonymous access (public server) Run Empire and create listener/stager (public server) Build EXE wrapper to run PowerShell one-liner silently Build Outlook RWZ file Connect to target users email in Outlook and sync the malicious rule file (Windows VM) Send an email to trigger the Outlook rule Shellz! (target workstation) PROFIT???

Step 1 – Install Apache and Web