Category Archives: Exploits

[ Sharing ] Analysing simple tricks used in malicious documents

Today i’ll go through with everyone on how to analyse some of the simple tricks used in malicious documents.

The first example that we will go through is a ppsx file using CVE-2017-0199 with “PPSX Script Moniker” bug
SHA256 : d4b345ed6b83fe477f3b30a4f4d124284fb73c38ec918d71284f6abf48982c23
ITW filename : 0Baptist U China1.ppsx
First Submission : 2017-08-10 16:44:45
Last Submission : 2017-08-10 16:44:45


The sample is trying to execute the following scriptlet, script:hxxp://
So you might ask “But how do we normal users know that?”
So loading it up with Profiler, we select “ppt/slides/_rels/slide1.xml.rels” and we can see the following image.

So now let’s inspect the contents of jf93jf8yu98yretghw43k4i2i3i4.sct

Contents of jf93jf8yu98yretghw43k4i2i3i4.sct:

Ok now let’s decode the base64 encoded string and see what jf93jf8yu98yretghw43k4i2i3i4.sct is trying to execute in the PowerShell script.

Base64 Decoded String:

After decoding and decompressing, the string looks like the following:

Base64 decoded and decompressed String:

As we can see from the code snippet,it will send back data about the victims’ machine and send it back to hxxp://
After that it will fetch instructions from hxxp://

If we were to execute the following curl command:

We can see, it’s trying to run a “dir” command on the victims’ machine and send back the data.

Ok let’s move on to another sample.
The next example that we will go through is a chm file. I decided to go through CHM after i read a DeviceGuard UMCI bypass using CHM today,
I won’t go through how the bypass works as the blog post is quite detailed enough. I’ll focus on an old example that was distributing PlugX.
There is a much comprehensive article on chm analysis
SHA256 : 7f4062a38dc5d40eec0ddfd8be6e60c01567f70dfa6ec065cb8ddf996251f369
ITW filename : My Document22s.chm
First Submission : 2017-08-10 07:59:50
Last Submission : 2017-08-10 07:59:50


Ok, let’s load it with Profiler and do some basics DFIR.

As we can see that the DWORD at offset 0x0014 is 0x000804
With reference to, this ID
is the user language ID (from GetUserDefaultLCID) of the
Operating System at the time of compilation.
This means that the default language is Chinese Simplified (Windows Language ID).

If we look at the DWORD at offset 0x0010, it’s 0x4020AE9E
We now know the human readable timse stamp is GMT: Wednesday, February 4, 2004 8:34:38 AM
A timestamp. With reference to, this is
derived from GetFileTime() function and is the value of the
dwLowDateTime member of the last write time parameter.

Ok now let’s unzip the chm file as chm is sort of like a zip container.
So let’s load unzipped folder with Profiler again and we can see the following image.

We can see that there are 3 html files. But the first one that is shown to victims is main.html and we can find this interesting code snippet.

As this is fairly trivial to deobfuscate, i won’t go through it but you can use to deobfuscate it easily.
We should get back the following code snippet.

Hmmm…the Javascript still look messy. Ok now we can either decode it again or use
We should get back the following:

A quick glance and we can see that it’s trying to execute the codes in 1.htm.
So let’s move over and take a look at 1.htm

As we can see from the code snippet below, that it’s trying to decode base64decode the base64 encoded string and execute it.
We can also see that it’s trying to base64 decode “bin.base64” but we can’t find it here. Let’s get back to this later. We can also see the dropped payload is named as “MsMpEng.exe” ^^

After base64 decoding, we get back the following. It seems like it is trying to execute xml.htm. Ok, let’s look at that now.

Checking out xml.htm, we can spot “bin.base64” which we found in 1.htm. So what is the base64 encoded blog.

Once we base64 decode it, we get back the payload as shown here.

The dropped payload is actually PlugX and there are many articles on it so i won’t go into the details of it as well.
You can read up on PlugX here:

The details of the dropped payload is as follows.
SHA256 : 6a60e950f06a3d9b0eaac81d69a3a6da9e04eff5db9f094ad0a06f7bc983092d
ITW filename : MsMpEng.exe
First Submission : 2014-06-13 07:14:21
Last Submission : 2015-03-12 10:00:17

Ok let’s move on to another sample.
The next example that we will go through is a docx file using CVE-2017-0199
SHA256 : db20e146714121fa02d24a7de2ee0132052e0202856396c95e191453badf7239
ITW filename : Payment_Advice.docx
First Submission : 2014-06-13 06:18:04
Last Submission : 2017-07-04 09:44:54


So let’s load this file with Profiler again and we can see the following image.

As we can see here:

There is an externally linked OLE Object located at, hxxps://a[.]pomf[.]cat/xhiuyr[.]doc

So let’s download this file.
SHA256 : 659CD31DAB50248F741C822C2641B65B5314DB043BFADDE32CD9051AF3FC5FE4
ITW filename : xhiuyr[.]doc

Ok, so this file is not uploaded to VirusTotal yet.
Never mind, let’s load it with Profiler again. We can see that it’s trying to download and execute the binary from hxxps://a[.]pomf[.]cat/kzwhhg[.]exe

Let’s go through another docx file using CVE-2017-0199
SHA256 : f0f6a33e779ebc2ee9553cf413fc93d4236aefb970fd4a4435b45957f0799d9a
ITW filename : BL_INV#086395_PL.docx
First Submission : 2017-08-09 10:50:30
Last Submission : 2017-08-09 10:50:30


So let’s load this file with Profiler again and we can see the following image.

As we can see here:

There is an externally linked OLE Object located at, hxxp://uploads[.]shanatan[.]moe/yytvit[.]doc

So let’s download that as well.
SHA256 : 98ccf03a2fea4984ffe71acd2326e1f7533db78e4f487149daf08ea0935c1534
ITW filename : yytvit.doc
First Submission : 2017-08-03 12:46:47
Last Submission : 2017-08-09 03:11:53

Again, we can load it with Profiler and we can see that this is another CVE-2017-0199 file.

This time round, it’s downloading from hxxps://i[.]memenet[.]org/wfedgl[.]hta
Using curl command, we can see that the wfedgl[.]hta contains a JavaScript.

Now let’s do url decoding of the string and we should get back this.
So it’s trying to execute PowerShell and download the malicious binary from hxxp://uploads[.]shanatan[.]moe/wzglvz[.]exe

The next example that we will go through is a rtf CVE-2017-0199 exploit.
SHA256 : 5e226dbb90541a61203eeb4baef01326aa67a7e9461d1efec0d786c39781aeb7
ITW filename : CN-17069 REQUIRED.doc
First Submission : 2017-08-14 02:47:32
Last Submission : 2017-08-14 05:36:46


Loading up on Profiler, we can see that the sample contained an OLE object as shown here:

However, we can’t find any urls like any other “CVE-2017-0199” samples. Now let’s open it with Notepad++ and check out the RTF file.

Immediately one interesting thing that caught my eye is this string here: {\*\b 0{\*\pxe b}
If we read the specifications on,

\b turns on bold, whereas \b0 turns off bold.

So let’s just remove {\*\b 0{\*\pxe b} and load it with Profiler again and see whether it helps.
This time round we can see a url, “HtTP:\\193[.]29[.]187[.]49\qb.doc” as shown below.

So now let’s download the other “doc” file.

Inspecting qb.doc with notepad++ and we found this interesting code snippet

It’s not difficult to understand that piece of code snippet:

We can see that it’s downloading from tartakpiotrkow[.]com/.cache/en/emma.exe. So let’s download that.

The downloaded emma.exe is actually LokiBot. There is a detailed paper on LokiBot which you can read it up here:

The hashes of the 2 files are as follows:
Filename : qb.doc
SHA256 : 31a5b4331429bd6e406c5fb00e814ddafd69b73c71f63c64559e1ee5a1260b94
Filename : emma.exe
SHA256 : ba5271c01380cc148b608a1d0cbed39ef2882bcbf304029ea96d672ff223f73e

The next example that we will go through is a pptx file using mouseover feature of PowerPoint.
SHA256 : b26da51a70618b68a479e21bce499c20d4b280d7c79aa6b054da82c747ccfba1
ITW filename : sample.pptx
First Submission : 2017-08-07 11:05:38
Last Submission : 2017-08-07 11:05:38


Loading up on Profiler, we can see that the sample is trying to abuse the mouseover feature of PowerPoint to launch commands.
This is basically done by using the ppaction:// protocol to launch a commands.

We can see the following codes in “ppt/slides/_rels/slide1.xml.rels”

As we can see here, it’s trying to download from hxxp://youthservicesballarat[.]com[.]au/images/kubrickhead[.]jpg and using msiexec to execute it.

SHA256 : fabcee5f4bab02700375db8a6b1e6a04372f19a4af98d2652ddcc15915374e02
ITW filename : kubrickhead.jpg
First Submission : 2017-08-07 04:30:43
Last Submission : 2017-08-07 04:30:43

If we were to inspect it with Profiler again, we can see that this is really not a jpg file but an MSI installer.

However, we can see that within the msi file, there is a .NET malware.
I shall leave the reversing of the malware as an exercise for the readers.

Thanks & Regards
Jacob Soo

[ Technical Teardown: Exploit & Malware in .HWP files ]

This article will focus on teaching analysts on analysing malicious JavaScript code within the HWP files and a walkthrough of how we can analyse .HWP files that was used to deliver malware.

[ 1st Sample used in the analysis ]
MD5: 8EB5A3F38EB3DE734037AA463ADE7665
SHA256: D0361ADB36E81B038C752EA1A7BDC5517B1E44F82909BC2BD27B77B2652667EE
As of writing, the detection rate for this sample according to VT is 12/54

[ Part 1 : Understanding OLE compound file ]
We need to first understand how OLE compound files work.
Inside these OLE compound files, there are folder (storage) and file (stream). We will use SSViewer( to take a look into the interior of the malicious .hwp file.

Most of the Streams in .hwp files are “zlib compressed“. We can see from the image below that the structure in .HWP files differs from .doc files.

However, today we are going to focus on “DefaultJScript“. You may ask why that? Well, think of “DefaultJScript” as VBA in Office documents.



[ Part 2 : Getting Started ]
For those who want to follow along. Do note, this is a MALICIOUS file, so please do the analysis in a “safe” environment.

Now, let’s start getting our hands dirty…and open the suspicious .hwp file with Cerbero Profiler.

As we can see from the image below, the data within “DefaultJScript” looks gibberish. So how do we make sense out of it?


As i’ve mentioned earlier, most of the streams within .hwp are “zlib compressed
So let’s “Select All” within the “DefaultJScript” stream and press “Ctrl+T

Now let’s add “Unpack Zlib” and remember to check the “Raw” checkbox and add it as shown in the image below.


Then let’s press “Preview” and have a look.


After decompressing the raw bytes, we can start to see some readable words. But it seems to be in Unicode.

Now let’s add in another filter to remove the “00” bytes.
Select “Replace“, change the mode to “Bytes” and add in “00” for the “In” value as shown below.


We should get back something like the one shown below.


If we were to analysed the decoded JavaScript, we can see more interesting stuff as shown in the image below.


So it seems that the JavaScript is doing Base64 decoding of the very long string and dropping it as “msvcr.exe”
I wrote the following Ruby script to decode the Base64 String.

After Base64 decoding the string, the output file looks like this,

The hash of this malware is 765834b1b780dacda8baa671c76328445cb8278099bad375ee22130f48920a7a
We won’t be going through this malware this time round.

[ 2nd Sample used in the analysis ]
MD5: a986a3fdf2afba98de21f0596a022b9b
SHA256: bd8fa7793f2192d4ff3979526955d5d6c965218eb0c0fe579f8ef0602357d5a9
As of writing, the detection rate according to VT is still pretty low. 3/53

[ Part 3 : Getting Started on analysing Exploits in .HWP files ]
This is a .hwp file containing an exploit (Most probably CVE-2013-4979 or CVE-2013-0808).
I drew a diagram like the one shown below to illustrate the general idea of how this exploit works.


For this particular exploit, the first thing we should be looking at is BinData/BIN0001.EPS as shown below.

There is an unknown error upon opening the document using hwp2010.

Nevertheless analysis can still be done by extracting the EPS files from the doc
Let’s do a quick network check by opening the eps file using hwp2010 and we can see that the exploit was indeed executed and connect to www.ethanpublishing[.]com/ethanpublishing/phpcms/templates/default/member/account_manage/teacup.jpg if we use FakeNet or similar tools.

We suppose that teacup.jpg” is most likely the payload. However, the jpg file is no longer found using the url so we cannot conduct further analysis on it.


Let’s go on to focus our analysis on the vulnerablity that was exploited by the eps file.

Opening the file eps file in the text editor we can identify a few components of the exploit.
The green block represents a NOP sled using 0xB5.
The blue block represents a NOP sled using 0x90.
The red block represents the shellcode.


Following the shellcode is this line of post script command

This command would execute a “Heap spray”. 500 blocks of the NOP sleds and shellcodes would be ‘sprayed’ in the memory. The NOP sleds and shellcodes is allocated as a string with a length of 65535 characters.

Next we want to determine which vulnerable process is the exploit targetting.
We do so by trying to search for traces of the NOP sleds and shellcodes in the memory of the vulnerable process.
At first it looks like the vulnerable process is likely hwp.exe or HimTrayIcon.exe


However, we could not locate any trace of NOP sleds and shellcodes in both processes.

At this point, I wonder if other child processes could be created by Hwp.exe. These child processes could have termininated after the execution of the shellcode.

One ‘trick’ we used was to modify the start of the shellcode with the opcode “0xEBFE” which is actually an infinite loop. This would allow the process that executed the shellcode to run continously without terminating.


Now we can attach our debugger into the gbb.exe process and we located the NOP sleds and shellcodes


Now after locating the vulnerable process, we have to debug into it to locate where the vulnerable code is exploited.
We now located the code in where hwp.exe created the gbb.exe process.


We shall modify the “CreationFlags” to CREATE_SUSPENDED. This would allow us to attach debugger at the start of the execution of the gbb.exe process.


After tracing the code we located the instructions in gsdll32.dll that executed the NOP sled “0xB5B5” which is MOV CH,B5


From the vulnerable instructions, we can more or less conclude that the vulnerablity is indeed based on CVE-2013-0808
For more information on CVE-2013-0808, you can read it up this article by CoreSecurity.

In the meantime, we hope you enjoyed reading this and we would be happy to receive your feedback!

Best Regards
Jacob Soo & peta909

[ Sharing ] More ITW Exploitation of Internet Explorer ‘Unicorn bug’ found

These few days i have seen friends asking me whether i have seen any sites during work using CVE-2014-6332.
Sad to say, i can’t talk about work. So today i will talk about what i’ve seen during my free personal time.

[ How it starts ]
So what is this vulnerability known as CVE-2014-6332?
This is an interesting bug as it exploits Internet Explorer versions 3 through 11. This means that most if not all of Internet Explorer users are vulnerable unless they are using patched systems. It was first disclosed publicly by @yuange75 here back in 01st August 2014 :
However he found it long long ago.

I guess it’s only a matter of time that “malware writers” start using this knowledge and use it as part of their cybercrime. I’m not from any AV companies nor ThreatIntel team selling “APT” news, but i do want more people to know that there are now several compromised website(s) that are using this CVE-2014-6332 vulnerability to install malware on the computers of its unsuspecting visitors.

[ Compromised Website details ]
The very first one that i found is from www[.]uyghurweb[.]net
The page source contains 2 interesting thing that caught my “eyes”.

The 1st one is “http://122[.]10[.]91[.]20/2013/frame.js” but it’s down when i tried to grab it.
The other being the other JavaScript(s) in the page.

The one that is more interesting is “js/udg.js” as it’s actually redirecting visitors to another website serving “CVE-2014-6332

As you can see, the exploit is hosted on the domain “http://www[.]owner[.]com[.]tw
If you have seen the source of “new.htm” as shown below.
It looks almost identical to the one shared by @yuange75. I suppose this malware writer is quite lazy to change anything to it.

I actually found a total of 7 but some are sensitive to be shared. One of it was disclosed by ESET here:
The other 3 non-sensitive sites that i’ve found are from:

But interestingly for these 3, all are showing “Hacked by LulzSec” and the following is found in the page source.

My guess is the first one is probably not related to the other 3. But one thing is for sure, there are more of these websites serving “CVE-2014-6332” as we speak.
I’ll probably blog about the payload later.

[ Conclusion ]
Although i do not have the mass amount of data as AV companies or ThreatIntel companies to offer IOC (Indicators of Compromise), but i guess if i can find a few website(s) within a week. I suppose it’s is just a matter of time before ExploitKit(s) integrate this vulnerability to their existing toolkit. Since most of the Internet Explorer versions were affected, I guess user(s) of Internet Explorer should just update IE NOW!!!!!.

Happy Reversing
Jacob Soo

[Technical Tear Down] Fiesta Exploit Kit – Java Exploit (CVE-2012-0507)

Today, we’re going to look at another exploit that is delivered by the Fiesta Exploit Kit. As usual, the purpose of this post is to provide a technical understanding on how the exploit work. This time it is a JAVA exploit.

This is the link to the fiesta_ek_java_2012_0507 (The .JAR file contained 4 .class files and a .txt file containing the parameters that was passed to the JAVA applet by the launching Javascript). Do note that these are MALICIOUS files, so please run them in a “safe” environment.

[Part 1: Overview]

This exploit uses the CVE-2012-0507 vulnerability. It is a type confusion vulnerability affecting the AtomicReferenceArray class. More information about this vulnerability can be found at these 2 articles ( and ). This exploit will result in a JAVA sandbox escape and allow the attacker to perform privileged actions.

Exploiting type confusion vulnerabilities are very interesting and very different from exploiting overflow/code execution vulnerabilities. In a sense, it is much easier to perform. To fully understand how it works, we must first discuss about the JAVA sandbox.

[Part 2: Java Applets and Sandboxing]

For the full explanation, refer to

In summary, there are 2 types of JAVA applets, Sandbox applets and Privileged applets. As the name suggests, sandbox applets run in a sandbox and have limited access to certain operations. Privileged applets do not have such restrictions but they have to be signed by a recognized CA (Certificate Authority) and the user must give permission to the applet to perform higher privileged operations. Most applets we see are sandbox applets.

The picture below shows some of the restricted operations of sandbox applets.


Take special notes of point #1 (cannot access local filesystem and execute files), #2(cannot connect to third party servers), #4(cannot change security level) and #5 (cannot create classloaders).

[Part 3: The Malicious Applet]

Below is the de-obfuscated Javascript code that is responsible for loading the applet.


The Javascript first checks that the Java version is Java 6u30 or lower. If it is lower than that, it will fetch the applet from the malicious url and start running the code in the “tampi” class. 2 paramters “peso” and “lapp” are also passed along to the applet.

In the following source codes, I have de-obfuscated some of the strings and variable names so as to make your reading easier. Let’s look at the “init” method of the “tampi” class. The “init” method is first called when a Java applet is loaded.


The 2 params that was passed in will be stored into the javaparam_lapp and javaparam_peso variables. Take note of the javaparam_peso which contains a URL link to the malicious server.  I will come back to it later.

Although a sandbox applet cannot create a ClassLoader, it is still able to get a handle to the Applet’s ClassLoader seen on line 17. The “lapp” parameter is the serialized form of an Object[] array. It is decoded by the “foro” method then deserialized by the ObjectInputStream and cast back to its Object[] form on line 19 and 20. The diagram below shows the reconstructed Object[].


The Object[] array contains 2 Objects.

  • preyx[] array containing 1 element (null at this point)
  • AtomicReferenceArray (I shall refer to it as ARA) containing 1 element
    • This is actually the same preyx[] array above, only casted as a ARA object

Line 22 to 24 is a Java Reflection call to set the first element of the ARA object to the classloader that was referenced earlier (Line 25 comment line is the non-reflection way to call the same method).  This means a reference to the Applet’s ClassLoader has been assigned into the preyx[] array. This violates JAVA’s type safety and hence a Type Confusion vulnerability.

Line 27 then calls the “juri” method on the first element of the preyx[] array which contains the ClassLoader now. Let’s look at the “preyx” class and its parent class, “odesh



The preyx class is actually a subclass of the ClassLoader class (See Update #1 for more details).

The “juri” method reads in the “teemb.class” class file and creates a Class object from it with the “defineClass” method on line 16. Take special notice of the last parameter of the method call. This is the “privilege” level to be assigned to this class. An instance of this class is then created on line 17. Let’s look at the “tampi.rous()” method.


The commented block is the non-reflection way to call the same methods. This is a typical JAVA privilege escalation method. It creates a ProtectionDomain which has access to “AllPermissions”. By AllPermissions, I mean ALL permissions. This means the “teemb” class would have access to all operations including file I/O onto the local filesystem, network connections to third party servers and so on. The applet can now perform whatever a normal executable jar file can perform when it is run from the local filesystem.

Let’s look at the “teemb” class now.


The 3 methods “lewd”, “orly” and “callWriteMethod” are helper methods.

  • lewd – some form of decoding function based on xor
  • orly – reads everything from the inputstream into the input byte array and returns the total number of bytes read
  • callWriteMethod – calls the write method of the specified class

The constructor of the “teemb” class calls the “doPrivileged” method which then calls the “run” method below.


Line 53 assigns the malicious URLs in “javaparam_peso” into the arrayOfString variable. For each url in there, the for loop on line 59 is executed. In summary, the for loop perform these operations.

  • Creates the temp file path to store the malicious file
  • Opens a URL stream to the malicious url
  • Read the first 256 bytes from the stream (this is the xor key)
  • If key is read successfully, read in the rest of the stream
  • Decode the rest of the stream with the xor key and store it into the temp file path
  • Use the Runtime class to execute the downloaded file in the temp file path

In gist, this is a Download and Execute code. At this point, the attacker would be able to download any malicious file from the Internet and execute it on the victim’s machine. This defeats all the restriction that was placed on sandbox applets, effectively bypassing the sandbox.

[Update #1]

The purpose of this update is to better explain the role of the vulnerability in this exploit. The original article did not really explain this part clearly.

Earlier in the article, I mentioned that preyx is a subclass of ClassLoader. This means under normal circumstances, the applet would not be able to create a preyx instance (e.g. thru a “new preyx()” call) because sandbox applets are not allowed to create ClassLoaders. CVE-2012-0507 allowed the applet to “smuggle” a reference to a preyx object into the applet’s execution environment without actually creating one.

However, the next question is why is the preyx object important? The answer is privilege escalation. In order to execute malicious operations, a higher privilege level is needed other than the sandbox privilege level. The defineClass method allows the attacker to create a class with a specified “privilege” level (thru the last param of the function call). However, the defineClass is a protected method which means only subclasses of ClassLoader would be able to call it and that is where the preyx class comes in.

To understand this easier, put yourself in the shoes of the exploit writer. The thinking would go something like this.

  • Goal is to run malicious code
  • Need a way to load a class with elevated privilege levels (defineClass method)
  • To call the defineClass method, need a subclass of ClassLoader (preyx class)
  • Normal applet would not allow the creation of a preyx instance, need a way to get a preyx object into the applet environment (CVE-2012-0507 vulnerability)

[End Update #1]

I hope you have gained a better understanding of this exploit. Until next time!!

Glenn (@_graypanda)

[Technical Tear Down] Fiesta Exploit Kit – Silverlight Exploit (CVE-2013-3896 & CVE-2013-0074)

While analysing the Fiesta Exploit Kit, a number of “java applets” and a Silverlight application was downloaded by the exploit kit. This post will describe the Silverlight exploit. The purpose of this post is to give a better technical understanding of how exploits makes use of vulnerabilities and play with memory to acheive shellcode execution.

[ Sample used in the analysis ]
MD5: a920d4ead958746e4886859fc28dbcdb
SHA1: 12a3f08144d3d9f317a62cfefb4c54fe823e9724

[ Part 1: Getting Started ]

For those who want to follow along, this is a link to the Fiesta-EK-silverlight-exploit. Do note, this is a MALICIOUS file, so please run it in a “safe” environment. The password to the attachment is “infected29A”

Silverlight applications come in a .xap file. As .XAP file is a .zip compressed file that contains the client DLL for the Silverlight application as extra DLLs of assemblies that the Silverlight application could be using. This can be the author’s own assemblies of user controls or assemblies that are not part of the Silverlight runtime by default that gets installed on the client.

External resources like images or other types of files can also be added to the .XAP file if you do embed them into your client DLL. By renaming the .xap file to .zip you can view its contents. Inside the .xap file and we will see a manifest file and a DLL file:

The manifest file describes the entry point of the application so let’s take a look at that first.

In this case, the manifest file is quite straightforward. The “EntryPointAssembly” tells us that the application starts in the tuyngled30.dll and the “EntryPointType” tells us that it starts in the App class of that package.

The next step would be to decompile the dll file. For this purpose, I used .Net Reflector. Throw the DLL into it and you will get back the C# source of the internal classes. Let’s take a look at the entry point, the App class.


The constructor calls the InitializeComponent which actually loads in components based on a xaml file. Normally, you would want to look at the xaml file to see if it loads in any additional suspicious components but for this case, the xaml file does not load in anything extra. The Application_Startup method is also called when the Silverlight application is started. In this case, it creates a new “jake” object and passes it the InitParams (We will get back to these params later)

[ Part 2: Overview ]

This exploit uses 2 vulnerabilities to achieve code execution.

CVE-2013-3896 (Memory Disclosure vulnerability) bypasses ASLR by disclosing adjacent memory such that ROP gadgets can be reliably located within

After which, CVE-2013-0074 (Double-Dereference vulnerability) achieves code execution. DEP is also bypassed by overwriting the shellcode into legitimate executable memory addresses.

Also, this exploit seems to target only x86 (32-bit) architecture.

[ Part 3: Bypassing ASLR with Memory Disclosure CVE-2013-3896 ]

Let’s look at the “jake” class.


The constructor of the “jake” class assigns the init parameter of “dies” into the byte array named “curd” and then calls the “wake” method (we will get back to this “dies” param later).


The first interesting point of the wake method is on line 103. The “brab” method basically exploits the memory disclosure vulnerability and returns the address of the ROP gadget. For this part, we will examine the “brab” method. Part 4 will describe the rest of the code.


First, take a look at line 23 and 24. A “polk” object is created. Reading the source of the “polk” class will reveal that it is a subclass of the MemoryStream object. It will be used together with the BitmapImage and WriteableBitmap class to trigger this vulnerability.

The vulnerability lies in the BitmapImage.SetSource(MemoryStream ms) method. This method creates a BitmapImage based on a memory stream. The amount of memory that is read in is based on the “length” attribute within the stream. This value is controlled by user and can be manipulated to a larger value to read in adjacent memory.

In this case, the memory stream is manipulated to look like a PNG file with a declared PLTE chunk of 0x300 bytes. Those unfamiliar with the PNG format can read about it at the following links. These 2 chapters show how a PNG is represented and the idea of chunks within a PNG file. ( and


The constructor first writes 0x29 bytes into the memory stream. These 0x29 bytes is the header of a PNG file up till the PLTE chunk header.


The “racy.tunc” method then calls the BitmapImage.SetSource method which will call polk.Read method which has been overridden such that it will declare additional arrays in a specific order (specifically the scum and raps array). When these arrays are declared, they are stored right after the already written PNG header.


The last few array elements will store the PNG Footer.

When viewed as a contiguous memory chunk, it looks like a legit PNG file. The resultant memory layout of the “polk” object is shown below.


The main objective of this arrangement is to have the additional arrays be stored in the PLTE chunk of the PNG. If we look at the PNG specifications at under the PLTE Palette section, it says that

“The first entry in PLTE is referenced by pixel value 0, the second by pixel value 1, etc.”

On line 29 of the “brab” method, “racy.papa” method creates a WriteableBitmap object with the affected BitmapImage object. The disclosed memory in the PLTE Chunk can then be accessed with the WriteableBitmap.Pixels array. The method transforms this pixels array (which stores 4 bytes/pixel in a ARGB format) into a contiguous byte array and returns it. So why is the disclosed memory important? Let’s take a look at what is disclosed.


If you are not familiar with how C# stores objects/primitives in memory or about Runtime Type Information (RTTI), read this first ( . Don’t worry if your RTTI addresses are different from mine, this is because these addresses are ASLR-ed. Basically, all objects in C# has this RTTI pointer. The RTTI stores type information that can be used for dynamic type-casting.

The objective here is to get the RTTI address. The RTTI address points to somewhere in the which is ASLR enabled. However, this RTTI is always loaded at the same offset from the base address of the Therefore, with the RTTI address, the base address of the DLL can be calculated. With that, the exact location of the ROP gadget can be reliably determined thus bypassing ASLR.

[ Part 4: Achieving code execution with CVE-2013-0074 (Double De-reference vulnerability) ]


Looking back at the “brab” method again, these are what the other functions do.

  • vamp(p1, p2) – Reads 4 bytes from p1 array starting from offset p2 (Read Pointer)
  • oils(p1,p2,p3) – Writes 4 bytes (p3) into p1 array starting from offset p2 (Write Pointer)
  • racy.lisp() – Returns the offset to find the ROP Gadget on different Silverlight versions.
    • Based on this method, it seems to target the following Silverlight versions


The rest of the “brab” method does the following

  • Save the RTTI pointer (num)
  • Save the raps[] pointer (num2)
  • Save the scum[] pointer (mews)
  • Save the offset to ROP gadget (num3)
  • Calculate and save the memory location of ROP gadget (num6)
  • Get the memory address of 41 bytes before the end of the PNG (c) (Take note of this!)
  • Writes a total of 8 bytes starting from memory address c in the following format
  • c05_8bytes
  • Returns the value of c “pointer to itself” (Take note of this!)

Let’s return back to the “wake” method.


The next important step is on line 109. The “diam” class exploits the CVE-2013-0074 vulnerability. The vulnerability lies in the ScriptObject.Initialize method. Fortunately, this is a protected method, meaning only child classes can call it. Unfortunately, ScriptObject has a public child class called HTMLObject. By sub-classing the HTMLObject class, it is now possible to call the protected Initialize method.


The “diam” class inherits from HTMLObject and wraps the Initialize method in the “gain” method. Calling the “gain” method with “(IntPtr) a” will lead to a “call [a+4]” instruction, meaning the next pointer after “a” will be called.


Recall that in the “brab” method, the above 8 bytes was written in the IDAT chunk, 41 bytes before the end of the PNG? Line 109 calls the “gain” method with “pointer to itself” as the parameter. This would lead to a “call [ptr to ROP gadget]”, thus executing the ROP gadget.

So, what ROP gadgets are being used? Interestingly, this ROP chain only consists of 1 gadget. The gadget consists of the following byte sequence “83-49-34-40-B8-01-00-00-00-C2-04-00”. Passing this sequence into Capstone yields the following result.


The gadget simply performs an OR operation with the value in [ecx+0x34] with 0x40.

Analysing the memory with WinDBG reveals that ecx at this moment contains the value of the “pointer to itself”. Therefore, [ecx+0x34] actually points to somewhere after the PNG “file”. In this case, it points to the most significant byte of the length of the next adjacent array, jake.chap[].

By performing this OR operation, it changes the length of the jake.chap[] array from 0x00000003 to 0x40000003, effectively allowing jake.chap[] array to access the entire 32-bit process memory space.

[ Part 5: Executing the Shellcode ]


With access to the entire memory space, the next step would be to get the exploit to run the shellcode payload. From line 114 of the “wake” method, a “jake.loci” object is created. This object is responsible for putting the shellcode into memory and executing it.


Take note of the “bust” method. It is the first method declared after the constructor and it contains a lot of code that does nothing. It performs a whole lot of mathematical operations and the result is neither returned nor used.


On line 115, the “loci.pore” method is called next with the parameter “curd”. The “curd” here refers to “jake.curd”. Recall the initParams that was passed into this Silverlight application in the beginning? “jake.curd” contains the value passed in through the “dies” parameter. The “loci.pore” method basically transfers “jake.curd” into “loci.curd” variable.

This is actually the shellcode itself, it is Base64 encoded and passed in through the initParams of the Silverlight Application. In this way, the shellcode could be changed or modified without needing to recompile the whole Silverlight application.


On line 116, the “gnaw” method is called. The comments basically explain what this method is trying to do. Here is a summary. (Note: [“pointer”] means dereference the pointer)

  • Create “bust” method to make sure a vTable entry is created.
  • Create a new array “scum” which contains a marker value and the pointer to this “loci” object
  • Iterate through the jake.chap[] (with 0x40000003 length) to find the marker value
  • “loci” pointer = next pointer from the marker value
  • vTable pointer = [“loci pointer”] + 0x2c
  • “bust” function pointer = [“vTable pointer”] + 0x8 (I believe the value 0x8 is used because “bust” is the second function in the “loci” class)
  • Exchange the bytes from “loci.curd” (Shellcode) and the bytes at [“bust pointer”]
  • Call the “bust” method (Shellcode Execution Here!!!)
  • Exchange the bytes back from “loci.curd” and the bytes at [“bust pointer”]
  • Restore the length of jake.chap[] to its original value (Element 0x3fffffff causes an integer overflow, essentially becoming jake.chap[-1])

Shellcode execution is achieved by making use of the jake.chap[] array to override the “bust” function instruction bytes with the shellcode bytes and then calling the “bust” function. In this way, there is no need to bypass DEP as the shellcode is residing in a legitimate executable memory.

Although I am unable to confirm this, I believe that the length of the initial “bust” function instruction bytes must be the same as the length of the shellcode that will replace them. This would explain why there are a whole lot of useless instructions initially declared in the “bust” function.

[ Conclusion ]

I have discussed how this exploit made use of 2 vulnerabilities to achieve shellcode execution. I hoped that you gained a better understanding of how the exploit was able to work. Also, an additional point to note is that the exploit code is similar to the POC code initially released by Packet Storm for these 2 vulnerabilities.

This is also my first time writing such a technical article and there are some parts of the article that I found it difficult to explain the technical details in words. If you have any advice/suggestions on how to improve this, please let me know through the comments.

If not, I hoped you enjoyed the article!

Glenn (@_graypanda)