The method does take more complicated shellcode and can be tricky, we've previously only seen this technique used with one byte XOR keys, in this case we have a 8 byte XOR key used to encrypt an executable and clean dropped .doc file.
Sample: MAP forecast template_2012.xls / f2e17c8954569ca2b20428f4c3112a30
Looking at the original XLS file, we can see that the embedded malware's zero space is not encrypted, the actual XOR key does not appear anywhere in the file:
In the image above, we can see that fragments of the inverse XOR key are left when a block of FF characters is encrypted with the 8 byte key. We can see the pattern b181826c015bd079 appears to repeat, since FF in binary is 11111111, XORing FF will leak the bitwise NOT of the key (compared to the full key when XORing 00000000). Using the inverse key and calculating the NOT gets us the actual key 4E7E7D93FEA42F86. Which shows the FF space as suspected:
And the malware in encrypted form:
And decrypted we can see the MZ Header:
We've added the above as a feature to our Cryptam document malware anaylysis system, this is the report for this XLS trojan:
And we've added a new "zero space not replaced" field to the cryptanalysis section. We'll add proper decoding for this in our public tools soon.
Other new features in the latest release of Cryptam :
- Enhanced Max OSX malware embedded in documents' detection.
- Retina resolution images in all reports.
- More accurate CVE-2010-3333 RTF exploit signature
- Open XML document format scanning - docx, pptx, xlsx.