Digging deep into Recent Angler Exploit kit Fileless delivery

Recently ThreatGlass released a PCAP related to Angler Exploit kit from wira-ku.com. Looking into this, Angler EK has changed it’s obfuscation techniques to load it’s dropper from the exploit server. Let’s dig into this.

The initial dropper is downloaded before the flash exploit download from the exploit server. So it is clear that IE exploit downloaded the dropper from the exploit server.


Angler EK is known to exploit IE VML vulnerability(CVE-2013-2551) that is published by Vupen. This particular exploit code follows the same “pattern” we saw recently during the first Fileless Angler EK analysis. The initial HTML page is obfuscated a bit. Another reason to claim that the dropper is not downloaded by Flash is, Flash exploit uses different URL to downloads it’s dropper.


Looking into the IE Exploit code, once it exploited the vulnerability it used a decoder to decode the second stage shellcode. The decoder code looks like this,


Here is the C code to decode the shellcode using above logic:

unsigned int decryptme(char *buffer, long bSize)
    unsigned int decryptedindex=0, encryptedindex=0;

    unsigned short curValue=0;
    unsigned char ah, al;
    while(encryptedindex <= bSize){
        curValue= *(unsigned short*)(buffer+encryptedindex);
        if (curValue == 0)
            return decryptedindex;
        ah= (curValue & 0xFF00) >> 8;
        al= (curValue & 0xFF);
        al = al << 4;
        buffer[decryptedindex]= al | ah;
        encryptedindex += 2;
    return decryptedindex;

Here is the decoded second stage shellcode:


Once the second stage shellcode took the control, it resolves various API’s using API hashing.
List of API’s resolved are:
    GetProcAddress (0x1FC0EAEE)
    LoadLibraryA (0xC8AC8026)
    VirtualAlloc (0x697A6AFE)
    VirtualFree (0x3A35705F)
    CreateThread (0x6FB89AF0)
    WaitForSingleObject (0xC54374F3)
    ExitProcess (0x95902B19)
    CloseHandle (0x723EB0D5)
    RtlImageDirectoryEntryToData (0x503F7B28)
    LdrProcessRelocationBlock (0xCFF13015)
    RtlExitUserThread (0x524D6EDA)
    InternetOpenA (0x8593DD7)
    InternetOpenUrlA (0xB87DBD66)
    InternetReadFile (0x1A212962)
    InternetCloseHandle (0x7314FB0C)

Once it resolved the API’s it download the dropper from Internet and start the decoding and few other modifications. The interesting point about this process is, each time you load the dropped DLL in the victim machine, the DLL will have different hash. Though the dropped binary hash is same over the network , it will be different in each machine. Lets look deep into that.

The file is decoded using little complex logic. This is the recent change goes into the Angler Exploit kit. The initial dropper is decoded using the logic as shown here.

unsigned int keys[4]= {0x39525143, 0x75487832, 0x57645730, 0x79356332};

unsigned int __stdcall decryptthis(char* buffer)
  char * originalbufferpointer;
  unsigned int firstdword;
  unsigned int seconddword_and_result;
  int v5;
  signed int count;
  unsigned int curvalue;

  originalbufferpointer = buffer;
  firstdword = *(unsigned int *)buffer;
  seconddword_and_result = *(unsigned int *)(buffer + 4);
  curvalue = 0xC6EF3720;
  count = 32;
    seconddword_and_result -= curvalue + keys[((curvalue >> 11) & 3)] ^ (firstdword + (16 * firstdword ^ (firstdword >> 5)));
    curvalue += 0x61C88647;
    firstdword -= (curvalue + keys[curvalue & 3]) ^ (seconddword_and_result + (16 * seconddword_and_result ^ (seconddword_and_result >> 5)));
  } while ( count );

  *(unsigned int *)originalbufferpointer = firstdword;
  *(unsigned int *)(originalbufferpointer + 4) = seconddword_and_result;
  return seconddword_and_result;

void decryptmeNew(char* buffer, long bSize)
    long count = 0;
    while (count < bSize){
        count += 8;

Here is the encoded/decoded content:


The second stage shellcode uses a “similar” logic as we have seen previously. It uses first four bytes of decoded dropper to decide whether it is going to load the decoded dropped binary or continue executing the shellcode that is part of the decoded binary. If the first four bytes is equal to ‘ZZZZ’ then it means it is a shellcode. Here is the disassembly of that logic,


The most interesting point here is, once it finished decoding and if it finds it is a PE file (like in this case) then it will do few more modifications. The ESI register is pointer to the (VirtualAlloc’ed)buffer that stores the decoded binary. The EAX register points to the “NT Header” (start of PE). The PE is at offset 0xD0 and adding 0x60 to that leads to “SizeOfStackReserve”


Looking into that deep, it modifies three fields in the “Optional Header”.  The SizeOfStackReserve field is set to 0x12387645 and SizeOfStackCommit is set to an Address that we got from VirtualAlloc and SizeOfHeapReserve is set to the size of the file. Setting an address to SizeOfStackCommit  is going to modify its hash everytime we run it.


Once it finished modifying , it will load that DLL using reflective-DLL injection logic (fileless) as we seen before.

This entry was posted in Exploit, Exploit Kit, Malware, Malware Analyzer, Shellcode, Windows and tagged , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s