Recently whole cybersecurity community was shocked by a newly disclosed Microsoft Exchange pre-auth vulnerability aka Proxylogon. This security flaw when chained with another SSRF vulnerability allow unauthenticated RCE on almost any outdated Exchange server. This resulted in many companies compromised and malware using this exploit as an entry point to be observed in the wild.

The client side

However, not only server side of Microsoft’s email exchange software is known to have interesting functionalities that can be exploited. In corporate environments it is not uncommon to have Outlook client application installed on employees computers - with user permanently authenticated. In this scenario we can utilize Outlook’s very powerful API that can be used to interact with email client almost if You would be using a desktop application.

In the first place we need to invoke the API by defining namespace using GetNameSpace() method. With this we will be able to interact with messages in the mailbox as if they were typical objects.

$outlook = New-Object -ComObject outlook.application
$olFolders ="Microsoft.Office.Interop.Outlook.OlDefaultFolders" -as [type]
$namespace = $Outlook.GetNameSpace("MAPI")

Next we can create an $inbox variable where we will be able to access the default Outlook folder (which usually is just “Inbox”).

$inbox = $namespace.GetDefaultFolder($olFolders::olFolderInbox)

With $inbox.items we can access all the objects (emails) in the default folder. If we are curious with how much data we are messing with we can call the count method.

$count = $inbox.items.count

A not so trivial matter

The question is how this can pose a threat to a user? Normally mailbox is a juicy target for a cybercriminal as it can contain passwords and confidential data. In a scenario where a malicious user gets a remote powershell session with our machine (i.e. as a result of evil payload in document macro), he is able to access our emails via this API.

Usually this task is much easier and boils down to retrieving the OST (Offline Outlook Data File) database of our mailbox, which by default is unencrypted (!). However, if the user has Outlook client configured properly and has offline mode disabled or the file is locked by Outlook process it is impossible to read the contents of the file. But someone in Microsoft already thought of this danger and when You try to interact with the API the users on the remote machine will be suprised by the following alert message.

However the pop-up never mentions the possibility of someone stealing our data. It only instructs us to “Deny” and update our antivirus. Very often if an employee is surprised by such an alert he will click “Allow” thus leaving his mailbox wide open for us.

Get-OutlookDump

As a proof-of-concept for using Outlook API in the pillaging stage I created a Get-OutlookDump cmdlet that can be used to search mailbox content for passwords and other keywords. It can be also used to dump the whole inbox by piping its output to a file. Below You can find an example post-exploitation process with this tool.

The script can be found on my Github.

References:

1. https://docs.microsoft.com/en-us/archive/msdn-magazine/2013/march/powershell-managing-an-outlook-mailbox-with-powershell
2. https://github.com/MicrosoftDocs/windows-itpro-docs/issues/6172
3. https://support.microsoft.com/en-us/office/introduction-to-outlook-data-files-pst-and-ost-222eaf92-a995-45d9-bde2-f331f60e2790
4. https://github.com/redfr0g/Get-OutlookDump/