The "CSI:Internet" series was originally published in c't magazine starting with issue 13/2010. For links to other articles in this series please refer to our CSI:Internet HQ page.
CSI:Internet
Episode 2: The image of death
by Frank Boldewin
One morning when checking my emails, one subject line really drew my attention: "Air France Flight 447 (crash pictures)". The email claimed that images on the camera memory stick of a passenger on the crashed plane had been successfully reconstructed and could now be viewed in the attached PowerPoint presentation.
The day before, there had indeed been headlines about an Air France plane crashing off the coast of Brazil. The plane had still not been found, and exclusive images of the catastrophe would have been a good way of getting people to click on an attachment. Too good, if you ask me! When someone is trying that hard, my alarms go off.
So I saved the email attachment in a shared folder, to which my virtual malware analysis environment has access. I was not about to experiment with my desktop system. In this protected, virtual environment, I first uploaded the PowerPoint file via Virustotal to see whether an antivirus vendor had already taken the time to analyze it. Nope. Only one vendor was already categorizing it as somehow "suspicious", an outcome that is unfortunately not rare for contaminants that are just coming into circulation.
So let’s get to work – the job could prove to be interesting. First, I checked whether simple methods revealed anything. It's really amazing how often you can use the Unix command strings
to detect such suspicious strings as a typical PE header or such import names as Createfile
and WinExec
. These are clear signs of executable code, which has no place in an Office file. But this time, strings
did not reveal anything aside from a few strings typical of PowerPoint, such as "Arial".
Next, I took a look at the mysterious PowerPoint file with the much more refined Officecat tool from the Snort team. Recently, it had proven quite useful in analysing what purported to be an invoice; the tool not only found the file to be infected, but also pointed me to the "Common Vulnerability Enumerator" CVE-2006-6456. This is a reference to the MITRE database of vulnerabilities which in turn provided me with links to a number of descriptions of the exploited hole in Microsoft Word, including Microsoft Security Bulletin MS07-014, which closed the hole.
But the only thing that Officecat had to say about these purported crash images was, "SAFE File". I could not imagine that the file was truly safe. It was more likely that the simple, signature-based approach of Officecat had once again failed. After all, these tests produce no results without a signature for a known, analysed exploit.
It was time for me to play the honeypot and open the PowerPoint file within my safe environment using an old, unpatched Office 2003. Obviously, I would then discover a number of suspicious activities, such as the creation of new files or the downloading of malicious code from the Internet.
Here, the ProcMon
tool from the SysInternals Suite is a charm; it logs all of the activities pertaining to the file system, the registry, and the launch of new processes. And indeed, a new process called fssm32.exe
popped up directly after the PowerPoint file was opened. In the background, PowerPoint then also opened Temp\Celebrities_Without_Makeup.pps.
, which had popped up out of nowhere – a clever tactic I have often witnessed when studying malicious files in formats like DOC, XLS, PPT, and PDF. First, they create an executable file, and then they execute it. Directly afterwards, they distract the victim by opening a harmless file, like the presentation of celebrities without makeup in this case.
At the same time, Wireshark found some strange HTTP traffic pertaining to a POST request at port 8080 under the IP address 202.52.X.Y. A look at the whois service on The H revealed that the server is located in Kathmandu, Nepal. There is no way that this is part of a regularly installed program. I generally have a network sniffer run on the host system in such cases. Because it sniffs on the network outside of the test system, not even an active root kit that has made itself at home in the kernel can hide its activities completely. In the worst case, I would still at least see an encrypted data stream.
On further investigation, neither the process, nor the data transmission to Nepal can be traced back to a natural source. Now I have proof that malware is at work. The question is how it managed to execute code. Not even intensive research online gets me any further. Apparently, there are simply no useful tools that extract macros from Office files or look for shellcode in them. I guess I'll have to write one myself.
It would have been much easier if the file had been in the new XML format that Microsoft launched in Office 2007. Then, I would have been able to use an unzip tool to produce more or less readable files I could look at in an editor. But my PowerPoint file is in the old binary format. So I spend the next few days studying a number of Microsoft articles.