Protecting over 200 million PCs, Macs, & Mobiles – more than any other antivirus

June 28th, 2011

Flash malware that could fit a Twitter message

When analysing malware you are most likely to encounter samples which use all kinds of obfuscation in order to hide from antivirus software that protects your computer. This is also true for malware written in flash (more specifically, ActionScript). Flash is very popular among malware writers these days because many people use it on daily basis. Sometimes, they don’t even know it’s flash that runs all the fancy stuff which takes place on their screen! Recently I came across a sample that uses a very nice trick to hide its purpose from everyone who tries to look under its hood. What is more interesting, this sample is actually smaller than 140 bytes, which means it could fit in a Twitter message!  That is rather unusual for flash files, which tend to be considerably larger. But don’t worry, this is not a case of malware spreading through Twitter in its binary form. Maybe via malicious links, but that is another story.

So apart from the small file size, what is so interesting about this sample? Since it is very small, lets see the hexdump of it:

 

Hexdump of the original sample

Hexdump of the original sample

 

Nothing unusual to see here, because we are looking at a compressed flash file (see the “CWS” header at the beginning). Okay, so lets unpack it and look again:

 

Hexdump of the unpacked sample

Hexdump of the unpacked sample

 

Now this is much better. We can see the uncompressed header (“SWF“) and there are some plaintext strings right at the end of the file, notably “/:$version” and “_root”. At first glance, this does not look very suspicious, but there is more. I’ve run this sample through some of our fancy tools to get a better idea of what is in the file. You might not be familiar with the structure of flash files, so let me explain it a bit. Every flash file consists of a mandatory header (that thing beginning with “SWF” or “CWS”). This header stores some information about the flash movie, like version, size and so on. Then comes a sequence of so called “tags”. A tag is a block of data which begins with a header that contains an ID (an unique number telling flash player what kind of tag this is, because there are many different tags) and length of the tag. One of the defined tags is the “End” tag, which tells the flash player that after this tag, there are no more tags (so the file ends, or at least should end ;)). With this brief tutorial, we can have a look at the tags in this particular sample:

 

List of tags

List of tags

 

As you can see, the first tag is reported as “Unknown”. Because of backwards compatibility, flash simply skips any tags that it does not recognize, so we can skip this one too. Out of the remaining tags, the only interesting for us is the DoAction tag and ShowFrame tag. The ShowFrame is important because it actually makes Flash Player execute all actions defined before it (simplified a bit). The DoAction tag is where all the magic happens. This tag contains ActionScript code, which can do various stuff ranging from a simple puzzle game to a video player. Because there is nowhere else to look for malicious code, lets try our luck and dig deeper into this particular tag. A quick disassembly reveals some interesting stuff:

 

Code in the DoAction tag

Code in the DoAction tag

 

Ooops, what is that? We can immediatelly tell there is something fishy about this code. First of all, there are numerous instructions that are not known. Better yet, there we see the ActionPush instruction which is used to push data on the ActionScript Virtual Machine stack. In this case, it pushes the data from a so called “constant pool”, which is just a fancy name for an array of strings. But where is this array defined? An ActionConstantPool instruction is used to define this array, but it is not in the code above! Does it mean this code will not work? Of course not. In order to reveal the secrets of it, we must look a bit back. In the list of tags we see that the DoAction tag should be 103 bytes long, but the largest offset in our instruction list is only 47! The sequence of bytes at that spot in the file is FC FF 88, which “translates” into an action of code FC (not defined) and length 0x88FF. Since the file is only 131 bytes long, this is clearly bullshit. But dont worry, lets patch the file a bit to remove this obstacle and see what happens:

 

Code in the DoAction tag - second attempt

Code in the DoAction tag - second attempt

 

Now that is interesting! An ActionConstantPool sitting right after the “obstacle” we just removed! There was actually another hint that some useful data will be at the end of the tag – the first instruction of all is an ActionJump which jumps in the code by the given offset. The offset in this case is 0x2C, so the new address will be 0×31 (since the jump action is 5 bytes long and we need to add those too). All these tricks are here to defeat disassemblers or any kind of static analysis. So what does the sample do? When the code runs, first thing it does is it jumps forward to the constant pool definition and then jumps a bit backwards, right at offset 0x0A where the ActionPush is. Remmember that before we said this action is invalid since there is no constant pool? Thats no longer true, so all is well and the code goes on. Its pretty simple now to get the resulting code, it will be something like this:

 

Final code

Final code

 

The sample simply checks the version of your flash player and opens an appropriate flash movie, which can contain exploits that work in that particular version of flash player. So its actually a downloader, something that opens doors into your computer and lets the bad things in. All this in just slightly over 130 bytes of flash.

  1. June 28th, 2011 at 13:51 | #1

    Where is an analysis of Stuxnet ???? Any way .. flash is gonna die soon with HTML 5 coming

  2. Naytee
    June 28th, 2011 at 14:15 | #2

    @HackToHell
    The thing is, Flash will never die. At least, not with HTML5 coming. We would need a LOT more interactivity coming from HTML and Javascript to destroy Flash. Elements of Flash (video, audio, etc.) can be replaced with HTML 5 tags, but Flash itself offers technologies that HTML generally can’t. HTML, after all, is a only a markup language. Actionscript is based on ECMAScript, both scripting languages and are far more capable than HTML is at the moment, or even with HTML 5. And HTML 5 itself won’t be fully developed and finalized until something like 2014, right? Flash is far more powerful and does far more than just providing simple animations and making games. And with technologies such as Adobe Air being used now to write native Flash applications, Flash is more available than HTML 5 and won’t be killed off, simply because it is still ahead of HTML 5 and tries to remain ahead of it.

  3. June 28th, 2011 at 14:48 | #3

    نشوف وش الجديد ياحووبي لي افاست

  4. June 28th, 2011 at 14:50 | #4

    ياحووووبي لو

  5. June 28th, 2011 at 15:27 | #5

    I want antivirus to protect my profile on Facebook and e-mail

  6. Chris
    June 28th, 2011 at 18:20 | #6

    Don’t click dumb shit and you won’t need another antivirus@zaki laggoune

  7. .:Mac:.
    June 29th, 2011 at 13:53 | #7

    Interesting analysis. Just shows how powerful Flash can be and how valuable Click-to-Flash is.

  8. June 30th, 2011 at 16:17 | #8

    It’s hard to know anymore what is safe to click, and what is not safe. Virtualizing one’s browser in the Sandbox stpos all the 5h!+ from happenning. Virtualization will be the savior of the PC! J.R.

  9. pedro brogueira
    July 7th, 2011 at 06:11 | #9

    muito grato pelo trabalho

  10. vgfeit
    July 17th, 2011 at 01:25 | #10

    i think that a nice thing to do is get linux, get mozilla, get flashblock + noscript + requestpolicy plug-ins and enjoy safe surfing.

Comments are closed.