olevba - should display an error instead of no vba detection - MHTML with malformed Base64

[decalage2]

Originally reported by: sbidy (Bitbucket: sbidy, GitHub: sbidy)

---

The olevba don't detects the attached file as a vba containing MS-Document.
But a short investigation shows some suspicious Hex-String.

I think the malfunction comes from the leading returns and and random chars.

I used the python packages oletools-0.42.1

---

• Bitbucket: https://bitbucket.org/decalage/oletools/issue/35

[decalage2]

Original comment by Philippe Lagadec (Bitbucket: decalage, GitHub: decalage2):

---

Hi @sbidy, could you please confirm if this malware sample actually runs macros in MS Word?

I studied the content in details, and it turns out that the Base64-encoded blob which contains macros is malformed: At the beginning there is "N0" twice (e.g."QWN0N0aXZl..."). If you remove one of the N0 strings (replacing "N0aXZ" by "axZ"), the Base64 blob becomes well formed and can be decoded by Python.

And then the file can be properly analyzed by olevba, and indeed there is a malicious macro in there.

So there are two possibilities:

1. Either the malware author made a mistake when he/she edited the file to make it difficult to analyze, duplicating the "N0" string. This would be the most likely scenario if the file does not run macros when opened in MS Word.
2. Or MS Word does not treat incorrect Base64 encoded files the same way as Python does, and we would need to find out how to fix the Base64 decoder.

Thank you.

[decalage2]

Original comment by sbidy (Bitbucket: sbidy, GitHub: sbidy):

---

Hey @decalage ,

ah you right with 1.. I tested it with a lab environment and WindWord 2013 to open the file.
Word can open the file but can't parse the macro in the document.

I think there is no risk form this types of documents but can the WinWord fix such malformed strings? Like a repair function?
In this special case Word don't recognize the macro code - but what is if the first chars are skip by the word parser in magic way?
Is there a defined behavior?

Thanks for the investigation and your very cool parser!

[decalage2]

Original comment by Philippe Lagadec (Bitbucket: decalage, GitHub: decalage2):

---

Thanks for the test. I also ran the original file and my fixed version in the reverse.it sandbox, and it shows that the original file does nothing special, whereas the fixed one tries at least to connect to an Internet address. Interestingly, the original version triggers more alerts than the fixed one:

• original: https://www.hybrid-analysis.com/sample/3501e4c1d3141b5b69a5670217f98b4c6fea0080d95c018ac2098be8158f6259?environmentId=4
• fixed: https://www.hybrid-analysis.com/sample/c332faf8334b28cb86d89d16671d406e45179b8690f08dacc95870ee4e55170e?environmentId=4

As for your question, I think there is little risk: this file is obviously malformed, and Word should not manage to decode the faulty base64. And I don't see how Word would find which duplicate characters to ignore (I had to guess it after many trials and errors).

I will keep the issue open, because olevba should display a parsing error instead of reporting "no macro".