On Feb 12th 2013, FireEye announced the discovery of an Adobe Reader 0-day exploit which is used to drop a previously unknown, advanced piece of malware. We called this new malware "ItaDuke" because it reminded us of Duqu and because of the ancient Italian comments in the shellcode copied from Dante Alighieri's "Divine Comedy".
Since the original announcement, we have observed several new attacks using the same exploit (CVE-2013-0640) which drop other malware. Between these, we've observed a couple of incidents which are so unusual in many ways that we-ve decided to analyse them in depth.
Together with our partner CrySyS Lab, we've performed a detailed analysis of these unusual incidents which suggest a new, previously unknown threat actor. For the CrySyS Lab analysis, please read [here]. For our analysis, please read below.
Key findings include:
• The MiniDuke attackers are still active at this time and have created malware as recently as February 20, 2013. To compromise the victims, the attackers used extremely effective social engineering techniques which involved sending malicious PDF documents to their targets. The PDFs were highly relevant and well-crafted content that fabricated human rights seminar information (ASEM) and Ukraine-s foreign policy and NATO membership plans.
These malicious PDF files were rigged with exploits attacking Adobe Reader versions 9, 10 and 11, bypassing its sandbox.
• Once the system is exploited, a very small downloader is dropped onto the victim-s disc that-s only 20KB in size. This downloader is unique per system and contains a customized backdoor written in Assembler. When loaded at system boot, the downloader uses a set of mathematical calculations to determine the computer-s unique fingerprint, and in turn uses this data to uniquely encrypt its communications later.
• If the target system meets the pre-defined requirements, the malware will use Twitter (unbeknownst to the user) and start looking for specific tweets from pre-made accounts. These accounts were created by MiniDuke-s Command and Control (C2) operators and the tweets maintain specific tags labeling encrypted URLs for the backdoors.
These URLs provide access to the C2s, which then provide potential commands and encrypted transfers of additional backdoors onto the system via GIF files.
• Based on the analysis, it appears that the MiniDuke-s creators provide a dynamic backup system that also can fly under the radar - if Twitter isn-t working or the accounts are down, the malware can use Google Search to find the encrypted strings to the next C2. This model is flexible and enables the operators to constantly change how their backdoors retrieve further commands or malcode as needed.
• Once the infected system locates the C2, it receives encrypted backdoors that are obfuscated within GIF files and disguised as pictures that appear on a victim-s machine.
Once they are downloaded to the machine, they can fetch a larger backdoor which carries out the cyberespionage activities, through functions such as copy file, move file, remove file, make directory, kill process and of course, download and execute new malware and lateral movement tools.
• The final stage backdoor connects to two servers, one in Panama and one in Turkey to receive the instructions from the attackers.
• The attackers left a small clue in the code, in the form of the number 666 (0x29A hex) before one of the decryption subroutines:
• By analysing the logs from the command servers, we have observed 59 unique victims in 23 countries:
Belgium, Brazil, Bulgaria, Czech Republic, Georgia, Germany, Hungary, Ireland, Israel, Japan, Latvia, Lebanon, Lithuania, Montenegro, Portugal, Romania, Russian Federation, Slovenia, Spain, Turkey, Ukraine, United Kingdom and United States.
For the detailed analysis and information on how to protect against the attack, please read:
2013 Mar 04, 22:22
You talk about such a nasty PDF exploit, and then include a link to a PDF document to download? LOL
2013 Mar 05, 05:52
Just trying to understand
On page 14 of the article it is shown that the startup LNK is being executed and failing, but it's inside a VM - wouldn't the "fourth block" attempt to try and protect the entire backdoor from running any further in that sort of environment?