.docx can be used to move files onto a system when .exe, .zip, etc, are blocked.
Every now and again you might find yourself on a host with extremely tight whitelisting for file types at the Gateway. This is commonly on Citrix hosts, but can also apply to other virtualized hosts, kiosks, etc. Getting the payload onto the host can provide a challenge due to SSL decryption and strict file whitelisting.
This particular engagement was performed by another consultant, but I made up this method of getting a payload onto the system, which I was told worked when other methods failed. The consultant on the engagement had tried various methods initially, such as using a rubber ducky to type out a base64 encoded payload to Word. At that point you would use native certutil.exe on Windows to base64 decode and rename the file as an executable. For one reason or another, character encoding was messing up this method.
TLDR; the consultant couldn't transfer common payload formats, and compressed files such as .zip and .rar also were blocked. Simple attempts to rename a .exe to a whitelisted file format with a header change (e.g. MZ => PK), were also blocked. This indicated that the gateway security appliance was performing file inspection.
However, the Citrix host allowed for Office documents to be transferred onto the system. Initially it was decided that doing a .doc with a macro would be the way to go. The endpoint did have AV and EDR which could make creating an undetected mal doc quite challenging, even using some of the newer vba stomping techniques. Hrmph.
The modern .docx and .xlsx Office formats are .zip files, so why not just smuggle a .exe payload inside one of the resource folders inside .docx?
Here you can see that the .docx format can be unzipped without modifying the extension. The PK header also shows that it is a zip.
In an environment that blocks typical archive formats, this is a valid method to smuggle data in, or out for that matter. After adding a sample exe (plink.exe) to the _rel folder, and compressing to create a new file (test_withexe.docx) I verified that no errors were thrown and I could still open up the docx in an editor.
Although this is not a dropper payload, and it is unlikely to be useful for a SE scenario (although you could potentially do something with a .bat file that decompresses and runs..) this is a very useful way to move payloads laterally once you are inside the network. It could also potentially confuse a SOC analyst when they follow the file creation thread after investigating a host.
From what I can surmise, the main utilitarian reason to use this technique is to get that initial beacon going on a hardened host. For added OPSEC, put the file on a document sharing portal used by the target ( Google Drive, O365, Box, SharePoint, etc). Then use the browser on the target host to download the file. I always avoid doing PowerShell, wget, etc, unless absolutely necessary due to the cmdline visibility.
Detection and Conclusion
I tried putting a several year old mimikatz inside the _rel folder and I found that the level of detection was roughly the same as the binary itself. However, just renaming the mimikatz extension to .xml dropped detection down to approximately 50%.
Regardless, you are going to have to worry about endpoint detection at the point that you have extracted the exe and have to run it. My main question is, do any of the products detect putting an exe inside a .docx as bad in general? There is NO legit reason to ever have an exe inside a word doc after all.
Curiously enough, the answer is none of the products on VirusTotal detect this abnormal nesting of an exe inside a docx... While you cannot rely on the .docx format obfuscating known malicious code, you can currently use it as a proven method to move an EXE or other files onto a system that blocks payload formats or zip/rar/gzip/etc at the gateway.