Another reason to hate Excel: its Macros can help pivot attacks

From Excel.Application to remote code execution. Lovely

A white-hat has taken a good look at whether you can pivot an attack from one machine to others using Microsoft Excel, and you probably won't like what he found.

The researcher, Matt Nelson of SpecterOps (@enigma0x3) writes that he's found loose default launch and access permissions, meaning a macro-based attack doesn't need to interact with the victim.

The nutshell version is this: Excel.Application is exposed via DCOM; it has no explicit launch or access permissions set; since the attacker would have to find some other means for the initial compromise, Microsoft Office Macro security won't stop the pivot; and Excel.Application can be launched (and interacted with) remotely.

That means the remote attacker can push up an Excel spreadsheet containing a malicious macro, and: “Since VBA allows Win32 API access, the possibilities are endless for various shellcode runners”.

Since it's a proof-of-concept, Nelson doesn't do anything especially evil: he merely launches calc.exe, but it's far too easy to do.

“Just create a new macro, name it whatever you want, add in your code and then save it. In this instance, my macro name is 'MyMacro' and I am saving the file in the .xls format.”

The calculator in the demo is spawned as a child process of Excel, but Nelson notes that “since VBA offers a lot in terms of interaction with the OS, it is possible to not spawn a child process and just inject into another process instead.

“The final steps would be to remotely cleanup the Excel object and delete the payload off the target host,” he adds.

While it's restricted to users with Local Administrator group privilege, the vector remains serious enough. This is, after all, a pivot attack in which Nelson's assuming a machine in the group is already pwned.

There are mitigations, but he warns they might be troublesome. A sysadmin can manually set remote Launch and Access permissions to Excel.Application, but that might impact other Office applications.

Other mitigations include using dcomccnfg.exe to edit the launch and access discretionary access control lists (DACLs), as well as turning on Windows Firewall and limiting the number of local administrators. ®


Biting the hand that feeds IT © 1998–2017