A major step in incident handling is to confirm whether a security incident is in fact taking place. Excessive handling of false positives can also cost an organization dearly in the long run. Recently, attacks using Office (or other office applications such as Ichitaro) as a vector have become more popular, making this identification stage a bit more difficult.
Some small tools can come in really useful if you want to avoid attaching a debugger to your Word session. Consider using your stock anti-virus. In many cases, it might be able to spot malicious files when they exploit a known vulnerability. Some names attributed to malicious Word files so far appear to generically trigger on malicious files:
Others vendors decided not to include patterns for exploitative Word documents, but provide them for their payload only, when it gets executed. While this generates less false positives, it also provides less protection for malicious code that is targeted, or has only recently been distributed. It also misses the exploit on the e-mail gateway. You may want to check in with your vendor to see what their approach to the issue is.
Another tool that is still useful is the regular hex-editor, or even strings. Seeing the MZ ‘magic’ and a stub executable, or even the UPX markers in a Word file is unusual:
dhahran:/tmp# hexdump -C malicious.doc | grep "UPX"
0103d0 55 50 58 30 00 00 00 00 00 20 12 00 00 10 00 00 |UPX0..... ......|
0103f0 00 00 00 00 80 00 00 e0 55 50 58 31 00 00 00 00 |........UPX1....|
010420 55 50 58 32 00 00 00 00 00 10 00 00 00 60 12 00 |UPX2.........`..|
0105e0 55 50 58 21 0c 09 05 06 5c 5d 41 a8 32 6d b5 68 |UPX!....\]A.2m.h|
Other useful tools have been released by Sourcefire and SecureWorks. SourceFire’s OfficeCat scans an Office file for the exploitation of a long list of known vulnerabilities.
Sourcefire OFFICE CAT v2
* Microsoft Office File Checker *
SecureWork’s Fess, short for File Exploit Scanning System, is an open-source tool that scans files for exploits using a Snort-like inspection language. Its basic release does not contain Office sigs, but one was released a few months later on the Fess-users mailing list. It’s a powerful tool, but you may need to write signatures yourself based on what specifically you are looking for. It’s a tool that would allow you to scan Office files for shellcode, for example.
Microsoft also has tools to bring clarity into the format. In essence, Microsoft Office files are of OLE Structured Storage nature, and consist of numerous ‘storage’ and ‘stream’ items. In order to identify each of the storage items, at the end of 2006, Microsoft released a tool called STG, which can display the different structure components and their contents. This can prove valuable when you’re trying to identify malicious components. Many of you may have worked with a similar tool, DocFile viewer, part of Visual Studio.
In May of this year, Microsoft also released two tools to control the Office targeting issue. The Microsoft Office Isolated Conversion Environment converts Office 2003 documents to the Office Open XML format. This should strip out any exploits that are present and present the file ‘safely’ to recent Office versions. There are some constraints, such as macros, smart tag data and embedded documents, which cannot be converted.
The other, File Block functionality for Office allows administrators to restrict supported file types for Office through the registry and GPO. By testing and combining both applications, an organization can proactively prepare an emergency plan that can be activated should a significant threat appear.
Do you have other tools or methodology you use to deal with this threat? Get in touch!
Maarten Van Horenbeeck