Looking back at the story I posted 2 weeks back, on getting target users to leak credentials using malicious UNC links in office (or other) documents ( https://isc.sans.edu/forums/diary/24062/ ) - how would you actually identify a malicious document of this type?  After a bit of digging, it turns out that there are a few ways to do this.

It's pretty easy actually, office documents are essentially zipped-up xml files.  In native powershell you'd execute:

$targetfile = "C:\full\path\to\doc.docx"
$word = New-Object -ComObject Word.Application
$doc = $word.documents.open($targetfile)
$xmlout = New-Object System.XML.XMLDocument
$xmlout = [xml]$doc.WordOpenXML
$targetrel = $xmlout.package.part.xmlData.Relationships.Relationship
$targetrel | ft

L:\cust\sans\isc\honeydoc> $targetrel | fl | sls "\\"
Target     : file:///\\192.168.122.212\test\cmd.png

Note that the full path seems to be needed in $targetfile - ("./" doesn't cut it as a path.)

There's a pretty big problem with this approach though - using the com object word.application actually opens the file using the application, so this actually opens word and then triggers the attack, sending the password hash of the account in use, which is probably more privileged then the user that was originally targetted (oops).  So if you use this method, be VERY SURE that your script is running in a fully firewalled sandbox or a fully firewalled machine.  Also, since you are invoking the application each and every time, there's a pretty hefty delay in that process, this isn't a method that you coiuld effectively scale to handle large volumes of files.

A better approach might be to use DocumentFormat.OpenXML.  Before you go there, you'll need to install the OpenXML SDK first, find it at https://www.microsoft.com/en-us/download/details.aspx?id=30425

A script using this method might look like:

[System.Reflection.Assembly]::LoadFrom("C:\Program Files (x86)\Microsoft Office\Office15\DCF\DocumentFormat.OpenXml.dll")
$file="L:\cust\sans\isc\honeydoc\smb trap 4.docx"
$doc = [DocumentFormat.OpenXml.Packaging.WordprocessingDocument]::Open($file,$true)
$targets = $doc.MainDocumentPart.ExternalRelationships
$doc.Close()
$targets | fl | grep "file://"
Uri              : file://192.168.122.212/test/cmd.png

At this point you can dissect things even further:

PS L:\cust\sans\isc\honeydoc> $targets.Uri

AbsolutePath   : /test/cmd.png
AbsoluteUri    : file://192.168.122.212/test/cmd.png
LocalPath      : \\192.168.122.212\test\cmd.png
Authority      : 192.168.122.212
HostNameType   : IPv4
IsDefaultPort  : True
IsFile         : True
IsLoopback     : False
PathAndQuery   : /test/cmd.png
Segments       : {/, test/, cmd.png}
IsUnc          : True
Host           : 192.168.122.212
Port           : -1
Query          :
Fragment       :
Scheme         : file
OriginalString : file:///\\192.168.122.212\test\cmd.png
DnsSafeHost    : 192.168.122.212
IdnHost        : 192.168.122.212
IsAbsoluteUri  : True
UserEscaped    : False
UserInfo       :

In many (most? all?) cases what you really want in this list is the "Host" parameter - you might want to put that host into your firewall's block list, or maybe add it into your Threat Intel feed. 

Adding these 2 lines to the script fills the "just give me the malicious host" requirement:

foreach ($t in $targets) {
if ($t.uri.isunc) {echo $t.uri.Host}
}

192.168.122.212

If there are multiple hosts in one file you'll get them all this way

How long is such a thing of interest?  It really depends - for most "in the wild" samples, a few days is usually plenty, most attackers don't leave these hosts up for too long.  Or for the duration of your pentest if that's the situation you are in :-)

Using this DocumentFormat.OpenXML method does NOT follow the link, so it doesn't trigger the exploit.  It also doesn't fire up a winword.exe (or excel, or powerpoiunt, or whatever) process, so it executes ***w-a-a-a-y*** faster!  Using this approach means that if your mail filtering app allows external script execution against attachments, this is something you can work into your mail security toolkit.

... However, this only works if you can "catch" a file as it comes into the company.  It won't help for instance if I get this into your organization via a USB key drop - in that case, unless your endpoint security / EDR / AV solution catches and "disarms" embedded UNCs (hint - I haven't been caught yet by AV), capturing  user credentials that way still works great!

All that said, any defensive approach that works with potentially malicious files should be working in a sandbox, you don't want malware of other types triggering while you are scanning incoming files!

User our comment form - what malicious content have you found in Office docs using OpenXML?  Or other methods for that matter - if there's a better/faster way to do this, please share!!

===============
Rob VandenBrink
Compugen