Threat Level: green Handler on Duty: Didier Stevens

SANS ISC: Dissecting Malicious MS Office Docs SANS Site Network Current Site Internet Storm Center Other SANS Sites Help Graduate Degree Programs Security Training Security Certification Security Awareness Training Penetration Testing Industrial Control Systems Cyber Defense Foundations DFIR Software Security Government OnSite Training SANS ISC InfoSec Forums

 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 Rob VandenBrink 521 PostsISC Handler Subscribe Sep 17th 20181 year ago