Pen-tester gets past Microsoft VB macro barriers

Outlook Forms aren't macros, after all - but is it a bug or a feature?

A bunch of white-hat researchers have turned up a nasty new vector for attacking Microsoft Outlook: a forms creation feature that bypasses macro rules so attackers can get to the victim's shell.

Sensepost says its interest in looking for an attack angle arose because Microsoft blocked older weak spots in a patch for Outlook 2016, which prevented the company's “Ruler” attack tool from getting in, and because “more and more organisations are (finally) moving towards a 'block all macros' policy”.

Sensepost's Etienne Stalmans found is that Outlook has a “forms” capability that with a lot of work can embed VB code – and the forms script engine is separate from the VM macro script engine, so the attack works even if macros are blocked.

Stalmans points to this explanation of how forms macros work. The Register notes that the Outlook Forms documentation dates from 2008 – so apparently the capability has been lying around, apparently unexploited, for nearly a decade.

The upshot of Stalmans' long post is that via Outlook Forms, “we have a full VBScript engine available to us”, something he demonstrates with the conventional test payload opening Calc.exe:

Function Item_Open()
     CreateObject("Wscript.Shell").Run "calc.exe", 0, False
End Function

More work identified where forms are stored (necessary to know how a form is accessed via MAPI), along with one of the banes of security pros – undocumented features.

For example: “For example, setting the PidTagSendOutlookRecallReport to true would hide the form from the user interface. This means the new form won’t show up under custom forms in the new item menu. To discover the new form, a user would need to go into the advanced options tab in Outlook, navigate to forms, select the inbox and view the list of forms (unlikely).”

Stalmans ended up with a form template that looks pretty straightforward:

Function P()
>>MAGIC<<
End Function

Function Item_Open()
Call P()
End Function

Function Item_Reply(ByVal Response)
Call P()
End Function

Function Item_Forward(ByVal ForwardItem)
Call P()
End Function

Function Item_Read(ByVal Response)
Call P()
End Function

This makes multiple triggers available to the attacker, he says: so long as a reader has at least previewed a message, reading, opening, replying or forwarding trigger the payload. “You need a slight amount of social engineering, where the attacker needs to either get the user to open the message or to reply to it. A nice side affect [sic] is that the user will inadvertently trigger the payload if they try “forward” it to the incident response team”, he writes.

Accessing the shell from the form is demonstrated in the YouTube video below.

Youtube Video

Microsoft, however, isn't convinced that this should be treated as a vulnerability. The company told The Register in a statement:

"The technique described in the blog is not a software vulnerability and can only be leveraged using an account that has already been compromised by another method. We encourage customers to set strong passwords, not share those passwords across multiple services and enable security features such as multi-factor authentication to help keep them protected." ®