Decoding ZeuS Malware Disguised As A .DOC

[Ronnie] recently posted about his adventures in decoding malware. One of his users reported a phishy email, which did indeed turn out to contain a nasty attachment. The process that [Ronnie] followed in order to figure out what this malware was trying to do is quite fascinating and worth the full read.

[Ronnie] started out by downloading the .doc attachment in a virtual machine. This would isolate any potential damage to a junk system that could be restored easily. When he tried to open the .doc file, he was presented with an error stating that he did not have either enough memory or disk space to proceed. With 45GB of free space and 2GB of RAM, this should not have been an issue. Something was definitely wrong.

The next step was to open the .doc file in Notepad++ for analysis. [Ronnie] quickly noticed that the file was actually a .rtf disguised as a .doc. [Ronnie] scanned through large chunks of data in an attempt to guess what the malware was trying to do. He noticed that one data chunk ended with the bytes “FF” and D9″, which are also found as the ending two bytes of .gif files.

[Ronnie] copied this data into a new document and removed all new line and return characters. He then converted the hex to ASCII, revealing some more signs that this was actually image data. He saved this file as a .gif and opened it up for viewing. It was a 79KB image of a 3D rendered house. He also found another chunk of data that was the same picture, but 3MB in size. Strange to say the least.

After finding a few other weird bits of data, [Ronnie] finally started to see more interesting sections. First he noticed some strings with mixed up capital and lowercase letters, a tactic sometimes used to avoid antivirus signatures. A bit lower he found a section of data that was about the size of typical shellcode. He decoded this data and found what he was looking for. The shellcode contained a readable URL. The URL pointed to a malicious .exe file that happened to still be available online.

Of course [Ronnie] downloaded the .exe and monitored it to see how it acted. He found that it set a run key in the registry to ensure that it would persist later on. The malware installed itself to the user’s appdata folder and also reached out repeatedly to an IP address known to be affiliated with ZeuS malware. It was a lot of obfuscation, but it was still no match for an experienced malware detective.

30 thoughts on “Decoding ZeuS Malware Disguised As A .DOC

      1. Thank you everyone for the positive feedback on the article and a HUGE thanks to Rick for featuring the article, as well as everyone at Hack-a-Day! Been a long time follower myself, and hopefully I can answer a few of the questions that are popping up in the comments!
        –Ronnie
        @iHeartMalware

    1. Ren,
      I did not contact the vendors directly, however I submitted the samples up to VirusTotal. All of the AV vendors have hooks into VT, and this is the easiest way to get it over to them. If this was something more targeted like Stuxnet, tehy would probably spend more time analyzing it, however this specific sample probably gets fed into their automated process. For the malware on VT, here’s the analysis for the exe:
      https://www.virustotal.com/en/file/da7ab88828ad5e4ff9ccd6957927db41fe1899986a2a2738a4a79ac5fe2fb7f5/analysis/
      And the RTF / DOC file:
      https://www.virustotal.com/en/file/e73436ad6a426ceb0daad145ec74cbb7aec71d8138c876d46aab704503bea087/analysis/
      Regards,
      –Ronnie
      @iHeartMalware

    1. BrotherGecko,
      Super malware sleuth, I like it. :)
      For the folks at MalwareBytes, I can’t speak for them directly, however this is one of the ways folks reverse malware. Once you find that interesting piece (such as the shellcode) you can create signatures for it.
      If you check the VirusTotal hits for the document ( https://www.virustotal.com/en/file/e73436ad6a426ceb0daad145ec74cbb7aec71d8138c876d46aab704503bea087/analysis/ ) Many of the vendors flag is at some form of obfuscated text related to RTF files and CVE-2012-0158. Many exploits have to be executed in a unique way in order to get them to be effective, and this is where many researchers “capture” the signature, at places that it can’t really be changed. Hope that helps!
      Regards,
      –Ronnie
      @iHeartMalware

  1. Does opening the .doc file in word really execute the shell script, download an executable and run it? Does microsoft word really have the power to do that without the user knowing?

    If not, what was the goal of this file?

    1. Ryan,
      For opening the word doc, it’s a little different than executing a shell script (just a batch / sh file), but the attackers goal is to get shellcode (think assembly code) to run. Let me explain a little further.
      For exploits such as this (CVE-2012-0158) the attackers have to find a vulnerability in a piece of software, and in our case, that software is Word. Once they find the vulnerability, they make the determination if they have code execution, if it’s a crash, just a bug, or what the nature of the vulnerability is. In this example, attackers are able to get code execution, meaning they can inject their own code into Word, and have Word execute it on it’s behalf.
      When the file is opened, Word attempts to read it, but it hits the vulnerability, and starts to crash. However, the attackers have coded it in a way that they control the crash, so instead of crashing, they jump into their shellcode, which is normally assembly instructions that they control. Once there, the shellcode decodes different things into memory (such as functions to import, like download a file) the shellcode attempts to reach out and download the file, and execute. If successful, they have successfully infected the system, installing the next stage malware that can do more things, such as stealing credentials and banking information. (Usually their end goal, but not always)
      Regards,
      –Ronnie
      @iHeartMalware

  2. Love these kinds of posts, hope to see more like it. Just for future reference, it’s possible to detect and break out of virtual machines. I wouldn’t make a habit of dissecting malware on an important machine, even if it’s in a VM. But then again, I’m more paranoid than most.

      1. If the VM can see the world (i.e. it has a working NIC) then the malware on it can potentially damage things around it. If the VM is isolated, then it would take some pretty nifty footwork to infect anything else… not saying it can’t be done…just that it would be a stretch, even for the most toxic of malware.

        1. oh come on, virtual machine technology is NOT “virtual machines” you are not “virtualized” at all really, you are STILL running native machine code on the metal. all it takes is one side effect from one instruction and the “virtualization” falls away like melted butter.

      2. Escaping the VM has been exposed more than a few times. There was even a Blackhat talk on it in 2012 where they escaped Xen. It was a known bug so in theory not a ‘real’ threat but how many hobbyists update their VMs religiously? Probably just those in the habit of opening malware on purpose. Given how everyone is using VMs for so much these days it would make sense for a malware writer to spend the time to find 0-days to exploit in the VM. They can already tell if they’re in a VM, breaking out is the next logical step.

        See page 9 for escaping the VM http://www.symantec.com/content/en/us/enterprise/media/security_response/whitepapers/threats_to_virtual_environments.pdf

    1. Hey Chaemelion,
      I agree, and as with any software, this is 100% possible. CVE-2008-0923 was demoed a few years at BlackHat. Here’s some specific information on the exploit, which is a directory traversal allowing for writing of arbitrary files to the OS:
      http://www.rapid7.com/db/vulnerabilities/vmsa-2008-0005-cve-2008-0923-player
      However on the flip side, the good thing for researchers is that we’re all using slightly different OS’s, VM’s, and environments. So for an exploit to work, they would have to find a vulnerability in the VM that has permissions back to the host OS, exploit said vulnerability, create code that would run on the host OS, and have it stick. From an exploit development perspective, there are many moving parts to successfully jump out of a VM, so the bar of entry for an exploit like this is very impractical to most attackers, unless we’re talking more of your sophisticated APT threat actors.
      I do recall one specific occasion when I was reversing a worm (analysis system was offline) and I had a shared folder set up for moving files back and forth, and it was mounted inside of the VM. The malware went and infected the share, and if I was running the same host OS as the guest, there could have been problems, but it would still have involved me needing to click it.
      And as a side note, for those who are reversing Windows malware…use Linux or something not Windows as your host OS. Accidental double-clicks happen, and it’s best not to have your host the same to keep you from having to re-build your system. :)
      Regards,
      –Ronnie
      @iHeartMalware

  3. i am surprised the image was not pornographic in nature because much spam has porn images.

    and the reason for the for the lack of memory and disk space is probably a corrupt header (at least corrupt to the reader).

    i dont know how that text editor works but some text formats may install extra header data to tell it the file size and such so since the data showed as wrong it tried to over allocate or something.

    as of the virtual machine stuff you may want to not use a virtual machine rather if you have another hard drive you can clone the internal drive or even install another instance of windows for testing purposes.

    hard drives can be gotten very cheap if you have an electronics recycling program and they dont have any rules on taking of the electronics you can pick up an old pc to wipe and make into a guinea pig

    if you are doing just what you did you are safe using a vm but if you want to see the malware working you need a real pc as malware can detect if it is on a vm.

    1. Hey ejonesss,
      > i am surprised the image was not pornographic in nature because much spam has porn images
      You would actually be surprised at how little malware authors include pornography in their malware and exploits. The reasoning they don’t? I’m assuming it’s a better story to an executive about a purchase order.

      > the reason for the for the lack of memory and disk space is probably a corrupt header
      This is probably true. A lot of the times the payload “breaks” and just doesn’t work as it should. Attackers are human and make mistakes, too.

      > as malware can detect if it is on a vm.
      One of the awesome things with RE is that you can control the flow of the malware, so you can usually see if it’s detecting if it’s being ran inside of a VM (and bypass it) . This also applies to cases where the malware jumps out, but there are more things that have to happen for a malware hop-out to be successful.
      Regards,
      –Ronnie
      @iHeartMalware

  4. this is even more fun than backtracking the people who try to ssh into your router

    one of them ended up being some sort of “computer genius” whose system was infiltrated

    1. I live to troll and waste the time of these folks, and I’ll be the first to post passwords owned by the attackers that are used in their malware.
      A few months back, we had a few Microsoft calls come into our office, and one of our employees passed the phone number and such over to me. I had them in a VM the entire time, and played things such as nyan nyan cat and trollolol very loudly. They were so persistent to get money out of me that they STILL tried going through the scam, and even called me back days later to see how I was liking the service. Here’s that post:http://phishme.com/fighting-back-fake-tech-support-call/
      Happy reading!
      –Ronnie
      @iHeartMalware

  5. I played around with a VM to intentionally get infections from downloaded software. I was surprised at how many times my antivirus software went off on my host machine when the VM was writing to the “virtual” disk. So if my antivirus was seeing it, then it was available to the rest of the system!

    1. No, all that means is that the bytes written to the virtual disk were accessible by anything reading the virtual disk file inside the containing OS. There’s no way for code inside the VM to cause that data to be executed.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.