Closed rsaccani closed 7 years ago
First commit and first PR in 6 years! Thanks a lot, this is a great idea. :-)
One question, though: can the DDEAUTO/DDE strings be split differently, to bypass the regex you are using?
Yes and I am also watching malicious samples that don't call cmd or powershell. One, for example, calls regedit in order to install the malware on the next reboot.
I think I will make it more general by disarming any DDE usage. Nowadays it's virtually impossible to find legit uses of it. If I change it in this way, it becomes much more robust. Let me know what you think.
Also, this PR works with openxml office files, it doesn't work with dde called from ole documents.
Thanks for the quick feedback.
I agree, it would be more effective to remove any DDE usage.
The last commit generalizes by disarming all usages of DDE/DDEAUTO.
Thanks! I did a few tests with xlsx and docx files, and it worked fine except on this one: https://www.hybrid-analysis.com/sample/e6804662e1e820a251379af04258a9b22e41838cbad9589a3450697ed9248d38?environmentId=100
Thanks for the sample! The regexp needs to be updated for this. Makes sense. I'll try to do it tomorrow or the day after tomorrow at most.
Disarming of DDE attacks in office documents.
Works both with Word and Excel attacks that attempt to execute stuff through DDE/DDEAUTO launching cmd/powershell.
Originally the exefilter XML filter does nothing, I've modified it to disarm the tags used to abuse DDE maliciously. The approach is the same of the PDF filter: replacing tags to disarm them.
It has been tested with real samples of malicious documents.
Here is the relevant part of word/document.xml contained in a simulated malicious word file:
And here is the disarmed version:
Here is the relevant part of xl/externalLinks/externalLink1.xml of a simulated malicious excel file:
And here is the disarmed version: