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:

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:

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:

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:

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:

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 0x31 (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:

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.