06 Feb Encrypted Java Archive Trojan bankers from Brazil Dmitry Bestuzhev
10 Nov Steganography or encryption in bankers? Dmitry Bestuzhev
12 Jun iFrames = Apple too? Michael
30 Apr More thoughts on drawing the line VitalyK
Join our blog
You can contribute to our blog if you have +100 points. Comment on articles and blogposts, and other users will rate your comments. You receive points for positive ratings.
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:
Looking up definitions for 'iframe' does indeed give results about "... a constraint of the H.264 codec specified by Apple to ensure ease of consumer video editing.". Such iframes do contain all necessary rendering information and serve as reference to construct other frames. But here we discuss the other kind of iframes - HTML tags. Iframes can have several attributes and we often encounter them when analysing malicious sites. They are often used in a hidden way to construct drive-by downloads of malware. To hide even more, simple encryption (also called 'obfuscation') is often used, web browsers decrypt that on the fly. Knowing that, we can search for interesting websites. For example doing a web search for "#64#6f#63#75#6d#65#6e#74#2e#77#72#69#74#65" (which decodes to 'document.write'), we instantly get 10,000+ results.
The first entry in our search results is a link to a torrent site where users discuss a malicious package. Ironically in between these search results we also noticed what seems to be an 'infected podcast' hosted at itunes.apple.com - which brings us back to the initial talk about iframes. The injected code contains an iframe redirecting to moshonken(dot)com, a host known for having spread exploits in the past. Currently that host appears to be not operational but malicious code trying to access it is still injected in many legitimate sites, as our search results showed. We detect this code as 'HEUR:Trojan.Script.Iframer' and have reported the problem via Apple's feedback form.
Fabio, our researcher in Brazil, has noticed malware authors using an old trick to mask URLs. The trick involves specifying an IP address such as say, 220.127.116.11 (the IP address of google.com, borrowed from my colleague, Costin) in a numerical base other than base 10. The supported bases are octal (8) and hexadecimal (16), and even a single 32bit number work, thus the following are all valid, and each will take you to google.com:
Now, by itself, this isn’t terribly interesting from a technical perspective; this ‘feature’ of IP specification has been around for quite a while.
However…what is interesting though is that due to the relative obscurity of using such methods to denote an IP or URL, it is quite feasible that existing security products do not correctly identify the URLs as valid or flag them as malicious when they point to existing known bad websites.
In my testing, Firefox on Windows supports all of the above addresses, under Linux however, Marco from our German office says some are unsupported. Based on poor browser support for such features, it’s possible to imagine URL filtering tools having the same lack of support.
In addition to potential weak tool support for such URLs, it is likely that unsuspecting users may be more easily convinced that a particular URL is legitimate, which I think is the obvious goal of using such URL obfuscation techniques.
Following on from Eugene's post, I'd like to chip in with my thoughts on what's happening at Defcon this year. I spoke at Defcon last year, and I'd say that the event is something unique – an opportunity for smart people with unconventional minds to meet and share their knowledge. Defcon not only gives you access to new ideas, but you also get to encounter the spirit of modern cyberculture.
It seems to me that the emergence of contests like Race to Zero was always simply a matter of time. And now that such a contest has appeared we'll see similar ones in the future, whether we like it or not. Of course breaking the law is wrong - I think the exact form of the contest will be modified before Defcon starts in order to meet legal restrictions.
However, I think the Race to Zero contest organizers could change the rules of the game in other ways, to make it beneficial to all participants. Let me explain...
Let's take a look at what the participants are going to manipulate: they will have the code of existing applications and probably some prepared sets of nop code. Nop code ("no operation" code) is special software code that neither affects the state of the machine nor alters the system. There are many approaches to obfuscation techniques but almost all of them have the same basic principle: the affected code is restructured and mixed with nop code. Depending on the algorithm used to mix the two sets of code, either it will be more difficult to read/re-engineer the code or the code will be able to evade detection by signature-based AV software engines.
The so-called 'malware obfuscation contest' proposed by the folks at Race to Zero is already generating contradictory discussions.
IMHO - either something is ethical or not...and I firmly hold that creating new malware to bypass security products 'for fun' is not!
We anti-virus researchers have always opposed the creation of new malware under any circumstances. The only excuse for creating malware in test environments that ever sounded vaguely reasonable was the old "we need to create new samples in order to study attack methods in detail".
Let's get real folks - we are seeing new samples by the thousands today - we have more than enough 'live' malware to study in order to improve our technologies. So even if this excuse was "sort-of-maybe one-time-only almost-acceptable" once upon a time, it is NOT acceptable in 2008.