Thursday, October 25, 2012

Tricky Tilon: disappearing instruction, anti-debugging, deceptions and much more!


This post is about a sort of anti-debugging trick that I discovered while analyzing a malware named Tilon. Well, to be precise, it's more a deception trick than an anti-debugging one but, as we will see later, it's really easy to tweak it to tamper with debugging.

Tilon is a banker that has been spotted by Trusteer in July 2012 and, aside from some pretty standard stuffs, like a Man In The Browser implementation,  it's better known for the peculiarity of making use of several evasion techniques. I found one of them, in the attempt of digging deeper in its various encryption/packer layers, that hasn't been reported yet.

All the layers are very easy to bypass: they roughly consist of basic crypto operations and UPX compression. After solving them you will see the following listing:


008D0079   CALL 008D0233
008D007E   CALL 008D04DC
008D0083   POPAD
008D0084   ADD ESP,4
008D0087   MOV EAX,DWORD PTR SS:[EBP+4020BF]
008D008D   JMP EAX

Tilon's trick(s)

So, we have two CALL and one JMP.

If we step into the first call, we will notice that the malware is going to set an "hook" (it's not properly API hooking as it's only inside the process itself) on the KiUserExceptionDispatcher API (a function of NTDLL.dll that is being called when some types of exception occur) to call (what we will discover to be) a decryption routine.

Pay attention to the code while stepping... As I reminded you before, Tilon is famous for the number of the deception tricks implemented!
For example, the next call makes use of a well known PEB related anti-debugging trick:

008D04EB   JNZ SHORT 008D04EE
008D04ED   RETN
008D04EE   INT3

Finally, there is a jump that brings us to an encrypted code:

Access violation, indeed!
Since there is no Exception Handler installed, one may think that the code has crashed for some reason that he missed and he will restart the debugger to conduct a more precise analysis. On the other hand, if we use Shift+F8 the malware will decrypt the code because of the previous "hook"! Finally, it will also delete the "hook" from the KiUserExeceptionDispatcher API and jump to the decrypted bytes.

So, this is really not an anti-debugging trick, even if it will work fine in some cases, like against emulators, but, let's stay focused: our goal is to fool the debugger... How can we do it? Well, there are surely several ways to do that, the one I have in mind consists of mixing this trick, the PEB one and... one more finding!

Let me explain it briefly: when Tilon generates the exception, by pressing Shift+F8 the debugger will execute the first instruction of the "hook", but will break only on the second one.
Thus we have: 

7C91EAEC   68 FA028D00      PUSH 8D02FA ; the first instruction is executed...
7C91EAF1   C3               RETN ; but the debugger will break only here!

That gives us the possibility of hiding an instruction!

Putting the pieces together:

Tilon: you are doing it wrong...!

Now I will show you one way to improve the trick in the Tilon's code:

STEP 1. We need to change the decryption key with a wrong one and to set a global variable (for instance, 00BD0AB0) containing the address of the decryption routine (in my case 008D02FA).

STEP 2. We modify the hook by writing: JMP [008D0AB0](this instruction will be hidden).

STEP 3. We modify the PEB trick (inside the last call before the jump to the encrypted bytes; see the listing at the beginning of this blog-entry) in the following way:

008D0A00   MOV EAX,DWORD PTR FS:[18]
008D0A0D   JNZ SHORT 008D0A19
008D0A0F   MOV DWORD PTR DS:[8D0AB0], 8D0A1A  ; no debugger!
008D0A19   RETN
008D0A1A   MOV BYTE PTR DS:[8D036D],7A ; small snippet in case of no debugger
008D0A21   JMP 008D02FA

When the code will jump to the encrypted bytes, the exception will call the "hooked" KiUserExceptionDispatcher API, that:
  • will jump directly to 008D2FA (the decryption routine), using the wrong key, if the debugger is detected;
  • will jump to the small snippet in the listing above, that will restore the correct decryption key and then jump to 008D2FA, otherwise.

In this way, if an analyst doesn't notice the PEB control (stepping over its call, for instance), the bytes won't be decrypted in the right way and this will cause a crash.

In my opinion, this version of the trick is way better than Tilon's original implementation, but we can improve it much more if we chose not to consider how it was originally structured (that is strongly related to the exception caused by the execution of the encrypted bytes...).

Another way to implement the trick (my fav one ;))

Another variant of Tilon's original implementation of the trick is the following.

We have to set a global variable (let's say 00BD0AB0that contains an address memory, depending on the result of the PEB anti-debugging trick. Then, we need to generate an appropriate exception (for example, by reaching a null pointer) and to "hook" the KiUserDispatcher API by injecting a JMP 00BD0AB0 (the hidden instruction!).
Thus, we have something like:

mov eax, 0
mov [eax], 0
* junk code *

The idea is to use the PEB check to set the global variable 00BD0AB0 to the address of * junk code * if the debugger is revealed, and to set it to the right address (where the real code is) otherwise. In this way, the analyst may not notice the "hook" at all, but will use shift+F8 to continue its debugging from the instruction right after the exception.

The following diagram will clarify the procedure:

Of course you can choose a different (more subtle and less visible) way to generate the exception, but the thing is that you can really confuse the analysis using the * junk code * and this can be really time consuming from the analyst perspective. For instance, you can insert some junk code and then terminate the process, or anything else.

Moreover, it's less detectable than setting the jump directly in the PEB check, because of the hidden instruction and the fact that the debugging will continue its execution after the exception itself like you would normally expect.

Note also that the PEB check is only one of the possible tricks to detect the debugger and you can obviously chose a different one!


You can use this technique on its own, or mixing it with other tricks. In case you chose to combine different tricks together, the risk of being detected will increase... but so will the number of possible uses you can make!

Thursday, October 11, 2012

Some notes about the pdf exploits in Blackhole 2.0

Recently we have been hearing a lot about Blackhole 2.0, the last edition of the popular exploit kit, and so I started looking around to gather some more information. In particular, I searched for some websites hosting it and found out a pdf file that caught my attention (you can find it in <blackhole_host>/data/t.pdf). 

The curious thing about it is that it doesn't contain any malicious code and if we look closer we understand that it's only a sort of skeleton for the real malicious pdf.

In fact, just analyzing the raw bytes we see the following streams:

3 0 obj<<%data%/CreationDate(%title%)>>

42 0 obj<</Length 504/Filter[/FlateDecode]/Type/EmbeddedFile>>stream

43 0 obj<</Length 1313/Filter/FlateDecode/Type/EmbeddedFile>>stream

This suggests us that maybe the malicious pdf is built at runtime: it seems that the fields %data%, %title%, %config% and %js% are filled each time with data related to a different exploit, depending on the vulnerability found on the victim's system. Moreover, it is a novelty for the Blackhole exploit kit, as the other versions didn't make use of a similar approach.

So, I conducted further investigations, searched for some live exploit urls to perform a real infection and take a log with WireShark. I then extracted the pdf file from it and started analyzing it.

To do that I used an utility named PDFStreamDumper, that successfully decompresses the streams (note that some other alternatives, such as pdftk, failed in this attempt as maybe the file was intentionally corrupted in order to make the inspection more difficult).

The important streams are the same as the ones listed above, but in this case they are filled with some data (they are reported in a slightly different notation because I had to decompress them). Here they are, together with a brief explanation: 


/Keywords(3a3p3p1h3a3l3e3r40233e423e3n401h403a3r3g3e401h3c3r3e3a403i3o3n2a3a403e1h3r3e3p3l3a3c3e1b1i1f1i3g1f1a1a1c21423a3r133p3a3d3d3i3n3g21423a3r133b3b3b1f13… **ENCRYPTED EXPLOIT BYTES** …383j1l1b383l3l1l1c21433i403h1b473k20383l3l1m491c382f1j1b3k1c212f3m3a3g3e2c3i3e3l3d1k1h3r3a432s3a3l413e23383l3l1k49383j1m1b1c21)/CreationDate(6683e4fcfc85e47534e95f33c0648b40308b400c8b701c568b760833db668b5e3c0374332c81ee1510ffffb88b4030c346390675fb87342485e47551e9eb4c51568b753c8b74357803f5… **SHELLCODE BYTES** ...6363636d7477723d3033303333333034333430383335333830393035266c71786d746e66623d30332668657a6e647865663d746c796d6626717666707870656f3d75777462730000)

This stream contains both the encrypted javascript exploit and the shellcode.


<config xmlns="" xmlns:xfa=""><trace><area level="1" name="font"></area></trace><agent name="designer"><!--  [0..n]  --><destination>pdf</destination><pdf><!--  [0..n]  --><fontInfo></fontInfo></pdf></agent><present><!--  [0..n]  --><pdf><!--  [0..n]  --><fontInfo><embed>1</embed></fontInfo><version>1.6</version><creator>Adobe Designer 7.0</creator><producer>Adobe Designer 7.0</producer><scriptModel>XFA</scriptModel><interactive>1</interactive><tagged>1</tagged><compression><level>6</level><compressLogicalStructure>1</compressLogicalStructure></compression></pdf><xdp><packets>*</packets></xdp><destination>pdf</destination></present><acrobat><acrobat7><dynamicRender>forbidden</dynamicRender></acrobat7><common><locale></locale><data><incrementalLoad></incrementalLoad><adjustData></adjustData><xsl><uri></uri></xsl><outputXSL><uri></uri></outputXSL></data><template><base>C:\</base><relevant></relevant><uri></uri></template></common></acrobat></config>

This stream contains some xml data.


<!--&lt;template>--><template><subform layout="tb" locale="ru_RU" name="form1"><pageSet><pageArea id="Page1" name="Page1"><contentArea h="10.5in" w="8in" x="0.25in" y="0.25in"></contentArea><medium long="11in" short="8.5in" stock="letter"></medium></pageArea></pageSet><subform h="10.5in" w="8in"><field h="98.425mm" name="ImageField1" w="28.575mm" x="95.25mm" y="19.05mm"><ui><imageEdit></imageEdit></ui><caption placement="bottom" reserve="5mm"><font typeface="Myriad Pro"></font><para vAlign="middle"></para><value><text>Image Field</text></value></caption><border xmlns=""><edge presence="hidden"></edge><edge stroke="dotted"></edge><edge stroke="dotted"></edge><edge stroke="dashed"></edge><corner stroke="dotted"></corner><corner stroke="dotted"></corner><corner stroke="dashed"></corner><fill><pattern type="crossDiagonal"></pattern></fill></border><event xmlns:xfa="" activity="initialize">
<xfa:script contentType='application/x-javascript'>
</xfa:script></event></field></subform><proto></proto></subform><?templateDesigner DefaultLanguage FormCalc?><?templateDesigner DefaultRunAt client?><?templateDesigner Grid show:1, snap:1, units:0, color:ff8080, origin:(0,0), interval:(125000,125000)?><?templateDesigner Rulers horizontal:1, vertical:1, guidelines:1, crosshairs:0?><?templateDesigner Zoom 76?></template>

This stream contains the script that decrypts the exploit itself.

To decrypt the exploit, you can use the following html page ("z" contains the encrypted bytes):


<title>Decrypted Exploit</title>

<script language="javascript">

var z;
var s;
z = "3a3p3p1h3a3l3e3r40233e423e3n401h403a3r3g3e401h3c3r3e3a403i3o3n2a3a403e1h3r3e3p3l3a3c3e1b1i1f1i3g1f1a1a1c21423a3r133p3a3d3d3i3n3g21423a3r133b3b3b1f13… **ENCRYPTED EXPLOIT BYTES** …383j1l1b383l3l1l1c21433i403h1b473k20383l3l1m491c382f1j1b3k1c212f3m3a3g3e2c3i3e3l3d1k1h3r3a432s3a3l413e23383l3l1k49383j1m1b1c21";
s = "";
for(i=0; i < z.length; i+=2)
  document.write(String.fromCharCode(parseInt(z[i]+z[1+i], 0x1d)));
  if(String.fromCharCode(parseInt(z[i]+z[1+i], 0x1d)) == ';' )



Which leads to the following well known vulnerability (CVE-2010-0188):

  _j8='SUkqADggAABB'; // * base64 representation of a TIFF header! *

I also gathered some other malicious pdf files and found out that they are structured always in the same way: the decryption script may change a little (for example, I found "0x1C" instead of "0x1D", that is the numerical base employed to interpret the bytes), but the method itself will be very similar.