A new version of the Rig EK

It looks like the developers of the Rig EK have been busy.

In my last post Pulling apart Rig Exploit Kit we see the way the decompiled flash file looked. It used several action script files and used 2 different configuration/replacement arrays to do its work. They used a combination of RC4 and AES to decode the embedded binary’s to get the arrays.

The first sample of this new version I have found is 2016-09-08 – EITEST RIG EK FROM from Brad @malware_traffic and found here http://malware-traffic-analysis.net/2016/09/08/index2.html . If you read that article you see the the EITest campaign was back after a short pause.

If we take a look at the flash file from 2016-08-31 – EITEST RIG EK FROM Here http://www.malware-traffic-analysis.net/2016/08/31/index2.html and do a quick check with SWF Investigator we see this.


Here we have multiple Action scripts and 5 defined binary data items.

If we look at the new version we see this.


This one only has 2 action script files and 1 defined binary item.

The first few that I looked at had the same “Names” but after that I have seen a change.

So what in the world did they do here.

Lets open this up in “JPEXS Free Flash Decompiler” from Here and see what we find.


We can see here that is has changed and starts out with a with the check for.


Next we scroll down to the the decoding function for our embedded byte array.


and here


Do you notice anything strange about this ?

There are several “this.init” assigned the same name. So what gives.

If you didn’t notice in the above screenshot this flash is obfuscated by the DoSwf tool.

If we go to their site then we see this.


And on another page we see this.


So that explains it.

After an Issue was submitted on the “JPEXS Free Flash Decompiler” site in their issue tracker, within a few days there was a new version available that can help with this problem.

So thank you Jindra Petřík (aka JPEXS) for fixing this so quickly. I’m sure most issues don’t get fixed as quick though.

So what does it look like afterwards.

Before setting the checkbox to auto rename  classes  we can see the name are not readable.




And a closer look at the code.


If you notice now there is an index number on the end of the names to make them distinguishable. Now that we have an idea of what goes where lets take a look at the embedded binary.


Ok so how do we read this ?

If we take a quick look at the SWF File Format specification then we see this about bytes and unsigned integers.


So we read the bytes like so.


Now we can look at our code again.


The first thing this does is pull our data bytes out. “_loc2_” will be our new byte array formed from the last “init#24”(0x5640) length bytes from the embedded byte array.

While less than this length it will do a nested while on lengths of “init#27” (0x14)  Xor’ing the byte at the index position by “init#26”(0x60) , each loop it will add 7 to the index.

Once it completes this loop it will then do a Un-compress. One thing to note is that this is using the ZLIB version not the same version that Neutrino was using.

So what do we get when we get done ?


As is, this will not load in a decompiler do to what ever it was that the DoSWF has done to it.

If we scroll down our code more we have an idea to help us to figure it out.


Looking at this it tells us it is taking the first byte and reading it in as a Boolean value. If True it will just go to the function  “this.garbageBytes#23” and create a garage Swf byte array.

If false then it will continue on and check the next byte which in this case appears to result in “True” .

Next it will take the next 4 bytes to get the length in LittleEndian byte order for a new Flash byte array.

That is about as far as I have gotten on this right now.

As you can see there is more research to do here and time to dig back into the SWF File Format specification to see if I can find a way to get this to load into a decompiler.

That it for this one I hope it helps someone.

Posted in Malware, Networking, security | Tagged , , | 1 Comment

Pulling apart Rig Exploit Kit

In the last post, A look at a cross bred Neutrino EK–Rig EK Flash file we see where the two exploit kits were merged into one.

This one is pure Rig and looks the same on the surface as other samples I’ve looked at.

The sample used here is from Brad @malware_traffic 


The main differences between Rig EK  and Neutrino EK are the the Neutrino EK uses a layered approach with multiple flash files and embed binary files that get decoded as needed. The Rig EK uses more of a scattergun approach. they use 1 flash file and multiple embed binary resource files.

They also split the functions into many classes, functions and parameters to make it more difficult to follow along. Some parameters/vars just get passed to a new ones and not used right away.

Note: My hats off to the person(s) that made the obfuscation tool the exploded this thing into 20 different files. That said I hope whomever it was is turned into a babbling idiot after writing it. I almost was trying to follow along with this crazy maze. I feel better now.

As mentioned above they are splitting everything into 20 action script files and are using 5 different embedded resource files.

They are using 2 different Xor functions to calculate the index value for the extracted replacement values.

They are also using the RC4 encryption for one set of replacements and AES 128 ECB for the other set of replacements for a total of 25 different values decoded for use as replacements throughout various parts of the code.

If we look at what the files look like in the folder normally after decompiling we see this.


But if we let it do a rename for us we see this.


That’s much Better and if we look at the Second file that it calls.


And after renaming it looks like.


If this looks familiar then that is because it is the same function from the last post. The difference is, instead of leading to the RC4 decrypter it is leading to a very well exploded self contained version of the AES decryption routine. It will work the same way passing the values to get decrypted.

I believe that they may have done it this way so there would not be a call to the built in crypto provider to raise a flag on what was used, or what they wanted was not available.

This version is only extracting 6 byte arrays to decrypt and 1 key. The last byte array is 2528 (0x09E0) bytes long and is listed as the shell code.

They do several things to this “Shell Code” byte array before it gets used anywhere. It gets sent to string, has another string tacked onto the end of it, get turned back into a byte array, gets reversed (littleEndian) , and that’s all I can remember off hand.

In this view of class_12 (file)  we can see there is allot going on.


If you look close at the two “Calculate replacement index value”, you will notice that they are calling two separate classes. Although they are two separate classes the number that those values gets XOR’ed with is the same number. The class_14 gives you the value for the index number to calculate in the RC4 decode, the class_2 is the extracted and reversed binary value and converted to Integer to get the value to XOR with,  that is for the AES decode.

Here we see the the start of the RC4 decode routine with the value (var_78) that is used to do the XOR to get the index value.


and here is the XOR routine.


I the screenshot above I was comparing the the values from the the RC4 and the AES to verify they were the same.

Using a tool I created for working with Angler EK to calculate the XOR  32 bit values we can verify what the results are. Using Calc.exe on a 64 bit system gives a different result.


So here is the list of RC4 replacements.


Here is the AES replacements.


Well that it for this one.

There is allot more that could be said about this one but tracing the code can be difficult at times. I traced the AES function across 4 class files and multiples functions and variables.

Thank you for reading.

Posted in Malware, Networking, Programming, security | Tagged , | 1 Comment

A look at a cross bred Neutrino EK–Rig EK Flash file

A recent post by Jérôme Segura of Malwarebytes https://blog.malwarebytes.com/threat-analysis/exploits-threat-analysis/2016/08/neutrino-ek-more-flash-trickery/

Although this post showed the flash file being sent from the compromised site rather than a “Gate” is interesting. What is more interesting is what is inside of this flash file.

After decompiling the the second level of this flash file the fist thing I noticed was the file structure.


To me this folder structure and naming convention looked more like the Rig EK than Neutrino EK.

If we take a look inside this to find where the configuration file gets decoded we see this.


Interestingly enough if we look at the Rig EK sample from Broad Analysis here http://www.broadanalysis.com/2016/08/15/rig-exploit-kit-from-185-158-152-195-delivers-zbot-banking-malware/

As we can see here.


Besides the naming of the variables these two functions are the same, what they do after that is somewhat different though.

After beating my head against the wall for a couple of days trying to figure out these weird loops I finally broke down and  took a crash course how how to crash a flash debugger.

Ryan Chapman @rj_chap in his BSides presentation here was using FlashDevelop from Here http://www.flashdevelop.org/.  , so I decided to try and install it. After several try’s and Google I finally figured out how to get the the decompiled file to recompile with that program. After a few more hours of trying to figure out how to solve a problem of it throwing an error on readint() I finally gave up and abandoned that program. The break points didn’t break and a few other things about it makes me never want to try it again.

So I went back to the Free flash decompiler and figured out how to set it up to run as a debugger. That finally helped get me the last clues even though I was not able to step thru it like a normal debugger and see what all of the values were.

One thing this version did was, instead of using a normal RC4 Function like this.


They separated the functions inside to three different ones.


Our decode function from above will send the key in this part, build the SBox then it will be used in this section (below) for the final Xor.


It will then be returned to the original function and pushed as a string, basically to a list.

It will cycle like this several times, in this case 45 times.

A list of What? Well of replacements.


And where are these used ?


And if we compare that to the last one I pulled apart.


We can see here it is pretty much the same, but what are all of these values ?


As it turns out this gets Xor’ed with a value from the embed binary data that gets the bytes reversed and converted to integer.


So if we Xor these numbers then we end up with something like.(The comment Values)


Which as it turns out does match up to the index values shown above in the decoder.

So how does this decode function work ? Lets look and the binary files and let them tell us.


We skip the first 2 bytes, take the next 2 bytes and convert them to an Integer and that is how many times we will loop.

Next we skip 2 more bytes, take the next 2 bytes  and that is how many “Data Bytes’” we will take and add to the array of “Array Of Bytes” for later decryption.

Then skip 2 bytes again and repeat until you have looped thru the given amount of times.

In the Rig sample it was only 6 times.

I’m pretty sure I’ve seen this method used somewhere before.

Lets look at the Key file.


And the number of bytes to get is called from this function.


Well that pretty much covers the bulk of this one.

So the question remains Which EK will this get identified with? This sample has both.

Is this just a trial run or a new way they will be built.

As it turned out my shiny new decoder did not work on the Rig EK sample even though they used the same method to pull the bytes.

The difference is however the Neutrino EK was running those bytes thru a RC4 decoder and the Rig EK sample was running them thru a AES decrypter.

So I guess I’ll have to build a new decoder for that one. Bummer.

This one is kind of short compared to the others but before I go 1 more thing.

While trying to update a new test system.


Enough said.

Posted in Malware, security | Tagged | 2 Comments

Pulling apart Neutrino EK

I’ve spent the last few days going from top to bottom of 3 different Neutrino EK infections.

The one I will show here is from Broad Analysis @BroadAnalysis  from their site http://www.broadanalysis.com/2016/08/08/new-c2-neutrino-exploit-kit-via-pseudodarkleech-hopto-org-gate-delivers-crypmic-ransomware/

You can download the pcap of the traffic from there.

Any one that has read any of my post before know that I prefer to do static analysis when ever possible. When facing a new piece of malware for the the first time it is like finding a piece of cipher text that needs decrypting.

Neutrino EK is similar to the complications of the Angler EK except they use so many flash files to hide what they are doing versus just scripting and encoding/encryption.

There are many great articles out there that have already covered most of what I could write so I will concentrate mostly on understanding the code and how to follow it. I will post a few of the links to some good articles that have help me put the pieces of the puzzle together at the end of this post.

By doing static analysis and creating most of my own tools I can change them and adapt them myself for what ever changes the malware authors may make.

The Neutrino EK is comprised of what I call 4 levels, 5 if you count the original flash file.

We will first need the JPEXS free flash decompiler which for me worked flawlessly in a VMware virtual machine using a never before used copy of 32bit Windows XP Pro that I have been saving for a rainy day since the sp2 version was still new. Trying it in Windows 7 64 bit kept crashing.

Once we extract/decompile the flash file we have a folder structure like this.


If we export everything then remove what is empty then that is what is left.

The first thing we will want to look at here is the scripts folder. The “binaryData” folder is the binary files we will have to work with later.


Here we see we have two action scripts outside of the other 2 folders.


I’m no action script Guru but this appears to be the entry point into this rabbit hole. It is creating a child or running the object referred to here which is the other file out side of the other 2 folders. So what is in that ?


Here we see that this is importing several items to use in the script we have 3 that start with “flash” so those are the native flash functions that are getting imported, but what are the ones starting with the “r’ ? to answer that question we go back to the the symbols file and look at it.


If we look at this and then look in the binary resource folder the names after the “r” match those files, so we figure the “r” is for resource , the last one on the list is our first file we looked at.


In the screenshot above we see in the red there is a variable but if we trace it down it is not used anywhere. They add a lot of code that does not do anything in order to help hide the small parts that do. In the blue we see more variables that are declared and set but never get used.

In the green though, it is setting “e” to the value of  the function “m” which is the RC4 decoding routine, and passing 2 of the embedded binary resource files. After decryption, it is next sent to the  “to string” method  then splits it in to a “String Array” with the character “%” to be use later for replacements.

As you can see at the bottom  this.e[3] would equal, starting  with index 0, “stage”.

(I missed separating the two at that one point in the screens shot above)


Here in the red box is yet another variable that is declared but not used.

In the blue box we see where it is assembling the byte arrays from the embedded resources. It is next run thru the RC4 decryption with the key and it returns another flash file as a byte array.

It then passes on to the “s” function  where it pulls another byte array from the binary resources and passes it to the function “et” in the launched second level flash file.

What does this last part do ? it is the most important part of the whole operation. This is, once it get decrypted is the configuration file.

Fast forward to extracting the second level and locating the function “et”.


This passes the last byte array from the first level as param1 here and sets “s=s” to “param 1”  and then it will call the function “s9s” if it has a event listener or it will add the result of that function call.


The main part we are concerned with in this one is it sets the value “s0s” to a string, does some check and will bail if they don’t pass and not decrypt the config. file.


We can see that the name of this function gets called from the last one if it is not found.

And what does the config file look like for this one after getting decrypted?


Or using a JSON Viewer it looks like this.


Here we can see that they can call out to several locations depending on what the result of the fingerprinting of the system is. It can give you nothing or the malware payload.


This is what my binary resource folder looks like after doing the decryption and decompressing.

The 3 new flash files only gets RC4 Decrypted and again depending on what the fingerprint is they get served up. The 3 html files and and the java script file each gets RC4 decrypted and and then have to get decompressed. This is a case where I made my own tools to work with these files in order to get the plain text.

The main fingerprint file to the best of my knowledge is the JS file. The only problem is it looks like this.


In order to decode it we have to take this function and the the var”v” and decode this into an array of string, which is what was show by @BroadAnalysis on a twitter post earlier today.

The very first time I worked with this I did all 70+ var replacements by hand , I’ve created a new tool to help with that now.


Here is what it looks like after the replacements. This code may not run but at least you get an idea of what is going on.

At this point we have a pretty good idea of how to decode this for each new level that is presented but what if we wanted to search around to see what connects to what.

I was having a problem where a tool I created some time back to look for stings in file was not finding the values as displayed by Notepad ++


As you can see here they are using some strange characters for names of the functions and classes. If you try and copy paste one of these in anything else  and do a search for that string it does not find it.

I finally open one of these up in a hex editor and paid closer attention to the variable names  and I seen this.


As you can see that looks different so what is up with that? As it turns out the answer came in  the way I have been extracting the html pages. I had discovered on the first file I ever worked with that you can not just open the decoded/decompressed byte array with a hex editor and copy the string part to a text file because it can leave extra escape chars in it, that gets real confusing and a pain to clean.

This file above is actually one of the Action Script files that the flash decompiler extracted.

So based on the idea from the html files  I use another tool I built a while back that will convert the hex bytes to a string using any supported encoding on the system, in this case it was normally UTF8 and after discovering this problem I found that UTF 7 would display what was in the hex file correctly. So I opened the Action script file in a hex editor and copied the bytes to this program to be converted using UTF7.



Now I can copy paste those names into my search tool and can find them anywhere in the sub folders to see what connects to what.

Before we move on to the level 3 code lets take a quick look at the script to decode a binary resource file.


As you can see there is a lot going on here to just load this iframe.

This is already getting long so lets move on to the last thing I want to show you that I have not seen mentioned before.

References to ‘MAC”


By this there appears to be checking if it is a “MAC”, there is one more flash file for a level 4 that can be decrypted. In 1 other sample I had worked with I found references to “MAC” in the extracted files, so I’m not sure if this will work on a “MAC” also or not. I’ve Never used one and have no way to test it.

As we have see here it can get quite confusing and difficult to travel thru these extracted files to see what does what.

After you learn the tricks and have the tools you can completely decode one of these in a matter of a few hours or less.

The analysis of all of the extracted code could take considerably longer though.

Well that’s it for this one , if you made it this far thanks for reading.



This helped with the last piece of the puzzle, the config file.


And this one.




Talks about an exploit added after someone published a POC


I’m sure there are plenty more good ones out there .

Let me know and I’ll try and add them.

Posted in Malware, Programming | Tagged , , | 2 Comments

My first deep look at KRYPTOS K4

My fist exposure to KRYPTOS was most likely when I seen it used in the TV Series Alias.

I most likely looked it up, got an idea of what it was about then forgot about it it for the next several years.

A few years ago I started working on the ciphers for Ghost in the wires where I have still only completed the ciphers for chapters 1 to 35 leaving the remaining 3 to finish, I’m still missing something about chapter 36. (any clues ?)

During that process I created several tools, one of them being a Quagmire 3 cipher tool and while searching for possible solutions for the Ghost in the wires ciphers I kept running across references to the Kryptos ciphers. Dropping the first two cipher into the Quagmire 3 cipher showed that they could be solved using that tool and the known keys.

If we look at Quagmire 3 it uses two keys and an indicator letter. If we test it with “A” we get this.


If we keep scrolling down the indicator letters and when we get to “K” we see this.


Or we can cheat and test all of them at the same time.


The question is, if we have some cipher text, plain text and the main key (KRYPTOS) can we figure out the Indicator key?  And of course the answer is yes. 


From the repeating pattern here we can guess what the keyword is.

In the process of creating this tool I discovered that the indicator letter was irrelevant to finding the indicator key. Given the way that Quagmire 3 works we can make a list of all 26 alphabets and compare if the index positions of the plain and the cipher text agree. Then the first letter of that alphabet found is the current letter for the Indicator key.

This tool also works with K2.

Given this information lets try it out on K4.


A few things to notice about this is, we only have 1 repeating letter , and since our search is from the middle of the cipher text the letters may need to be rotated forwards or backwards to be used as a key do to the way the cipher works on key lengths.

Together this implies that this is “Not” a Quagmire 3 cipher like the first 2 were.

So lets go back to the Statistics and see what we can learn from this.

If we do a letter count using http://rumkin.com/tools/cipher/frequency.php we can see that every letter is used thus eliminating any cipher that does not use all 26 letters. We also see that it gives an index of coincidence score of 0.0361. Anything above .0500 could be getting into some form of mono-alphabetic substitution cipher like a Atbash cipher or plain text.

After spending the last 3 + weeks I was looking at everything from Atbash to Quantum Cryptography, Morse code, Fractionated Morse and Binary manipulation. I was even trying to find a way to use a calculation for “SINE Wave” but couldn’t get the math to work out.

I’ve come to the conclusion that this may be some form of a home grown Poly alphabetic substitution cipher along the lines of a Quagmire using many alphabets to encode with. But what ?

While starring at this I finally started seeing some patterns show up.


What is the fist thing you notice here ?

We have 3 sets of letters that encode to or from different letters suggesting that there is at least 3 different Alphabets used to encode this with.


What is the next thing we notice ?



Looking at this it suggest that for each of the Plain text letters the Cipher letter gets bumped up 1 for every space in between each letter. It works for these two but will it continue forwards and backwards for the rest of the cipher text ?

The problem is, if you were creating this cipher it would be fairly easy to count what the cipher text letters would be if you know the spacing on the plain text and what alphabet was used. You would also need to know what the starting point was, or which letter you start encoding with. Here it appears to be a normal A-Z alphabet for these two samples.

In reality having mostly only Cipher text it is a real pain to calculate backwards or to decrypt it. I kept messing up my count, or was not sure if I messed it up or not so I wrote a program to do the counting for me.


Based on the theory’s from above I created this program to calculate forwards and backwards from our know Plain text letter and our Cipher text letters in the position in the cipher text.

We start with the known alphabet index location of the cipher letter and start counting backwards with the given alphabet and the initial position in the cipher text. If the current letter of the Alphabet = Current letter in the cipher text we replace the lower case “x” in our “Test String” with the our upper case letter we are testing for  , In this case “B” . We will do the same forwards.

After some trial and error and some bug hunting I also came up with some rules to narrow down on what was a potential match.

The First test is to see if our used alphabet will change the wrong letters in our know text.

The second test, once we get a output using one of the current 4 alphabets we change the location to the first letter replaced and reset the the letters and index position to match where we start this test from.


As we can se here using a normal A-Z alphabet messed up the third letter so that would tell me that a different alphabet was used.


Here using the first “L” we can see that it properly replaces the second “L” also.

It works the same for the 2 “C’s” in “Clock” also.

After going thru all of the letters in this manner we end up with this wild looking matrix.


This represents the best results by following the rules. I stopped bringing down the letters after I noticed a problem with this.


The “B” and “C” both land at the same position. This suggest to me that there may either be other Alphabets used or it will reset to the original position either at a certain count in the cipher text or for a limit to the number of plain text letters, which could change my second rule some.


Here we see the output of the “C’s” compared to the selected “B”. The “B” is the result of using a Reverse KRYPTOS alphabet which was the only one not to break the original rules.

After doing some more calculations on potential letters to fill in around our known letters I ended up with this.


You may be able to see in this that I was able to extrapolate the word “Crafty”.

So if this is correct then we would now have “Crafty Berlin Clock”

Although I have not cracked this yet, it will require further investigation to see if this method will hold true for smaller groups to work with.

Like reset the alphabets every 24 or 26 letters .

I also will need to try every letter in each position that seems correct.

Perhaps this was the way he encoded it or perhaps I’m just jumping down the rabbit hole.

This could also be like a Hill Cipher that was encoded with a matrix that has no “Inverse” matrix, thus not being able to be decoded.

That’s it for this one, and time to turn back to other task for now like reversing malware.

I will have to try more when I can come up with a way to automate this process.

Thanks for reading if you made it this far.

Posted in Cipher | Tagged , | Leave a comment

De-obfuscating Cerber Malspam file

On July 1’st 2016 I seen a tweet by Herbie Zimmerman   @HerbieZimmerman where he had gotten a zip file from some malaspam  containing an obfuscated Java Script file.

The infection chain is documented on his site here https://www.herbiez.com/?p=550

He had posed that he had trouble reversing the script, so that is what I will cover here.

As we scroll down the script we first see this.


We see it starts by setting a variable , assigning a value then tacking more on to the end of it. We next see another variable name and a value assigned to it.

If we look close at the second variable name  it is the same variable name and value assigned many times.

So we scroll down until we see this.


Tacking more onto our initial value. Scroll down some more.


Hmm a regular expression and new array.


Looks like this is only supposed to work this year.


Hmm if the date doesn’t match it return an empty string else ……


Lets take a closer look at this.


This looks like it takes our first variable as a hex array and Xor’s it with the Decimal 68.

A close look at the second variable name  and it is never used so lets clean this up and see what is left.


Now that we have this cleaned up what do we have ?

At the top we see out initial variable as a string of hex Char’s.

Next our variable is being reassigned as a hex array by using the Reg X to spit the string into lengths of 2 hex char’s , or a hex array.

Then we start the while loop.

Next is a check for the year, Interesting thing about this is the function used is depreciated for html  and returns 116 instead of 2016. If you try and drop this script into a html page  it will always be false.

If it succeeds in matching the date then it will run thru the array of bytes and Xor them by “Decimal” 68 (that tripped me up for a few minuets) then finally output the string or the decoded script.

The final 2 lines take our decoded script, drop it into a new function then call it to run the decoded script.

And here is what it looks like.


The script itself calls out to “http[:]//220.181.87[.]80/ok.jpg” to download the file and uses a random name generator to create a 1 Char name using the alphabet of “1234567890abcdef”  and save the file to the temp folder then launches the resulting .exe file.

That’s pretty much it for this one.

Ok, so I rushed over the part about getting the variable values into a hex array.

We first copy all of the variable parts over to a new text window.


Next in this case using Notepad ++ , select everything from the left single quote on the second variable to the right single quote on the first variable and then hit the find button.


next chose the replace tab.


be sure the “Replace with” is empty, then select replace all and we get.


Now take everything in between the 2 single quotes and run it thru your favorite Xor tool.


Take the result of the Xor and drop it back into a new Notepad ++ and use the Java Script format .


And there we go.


I hope it helps.

Posted in Malware, Networking, security | Tagged , | Leave a comment

Unknown Exploit Kit

When I first seen a screenshot of this one that’s what this was, Unknown.

Here is the twitter message that Jérôme Segura from Malwarebytes posted.


and the response by William Metcalf @node5 replied that it was Sundown/Xer and they steal from everyone for their Exploit Kit.

While researching other reports of Sundown, the code and the domains used in this version appears not the same as was reported in several other post on the Sundown EK. Is this a new version of Sundown? I don’t know, this is my first real look at it.

This version appears to be trying to look like Angler EK, it uses 5 sections that get decoded and each section has 1 or more levels to decode to get down to the final decoded code.

On June 15th 2016 Brad Duncan @malware_traffic posted his captured  run  here


that Jérôme Segura Mentioned in his Post.

If we look at what was posted for the first redirect from the infected site we see this.

(Screenshot borrowed from malware-traffic-analysis.net)


Here they are sending the person to 5 different URL’s but a closer look tells you they are actually hosted on the same IP.


Here is a closer look at what Jérôme Segura posted.


In the traffic from the Pcap from malware-traffic-analysis.net we can see there were 2 landing pages and at first they appeared to be exactly the same but doing a binary compare on them we know for a fact that they were different.

I next went thru and decoded every section as far as it would decode.

Viewing the decoded sections, “Most” of the sections contained code that would not run on its best day. In one of the decoded sections I even found a known Angler EK decryption key and some of the code from an Angler EK section. Reviewing the code in this section for what would have been the exploit section in Angler there were 2 separate decoding functions with the same name for what should decode some of the encoded strings.

Although there appears to be some advance functionality in this, um, Kit, it does not appear to be properly implemented at the moment. Just because it is ugly don’t totally dismiss this thing yet.

So if this thing is basically broken how is it calling out to download the flash and Silverlight ?

They are using embedded links in the code is several places.

In the first section we se this.


The top part of this is a hex encoded base 64 alphabet and then the base 64 decoding function , then finally the string to decode.

Once decoded we see this.


If you look close this is also a base 64 string but the string was reversed.


In the screenshot above we can see the eval that kicks of this part , taking the reversed base 64 string and using this reverse function  to reverse it then, finally base 64 decode and then we end up with this.


If you take a close look there are a few “p,a,c,k,e,d” sections it in. When you try and decode that it returns what you input.

Moving down on the same code from the first decoded section we see this.


If we drop the hex code for the “FlashVars value” into a hex editor we see this.


Here we can see there is no call for a “.exe” file but a link to

“http://trasergsgfsdx[.]xyz/z.php?id=8” which shows up in packet 602.

If we look at this section for the second landing page we se this.


It is has “z.exe” and a different site name and id number.

If we move on down on the first landing page we see this.


We have a call at the top using the same Url that was found in the hex above

If we clean up the top of this and zoom in we see this.


If we look at the bottom we se this.


The section in between is percent encoded hex so lets decode that and see what we get.


Above they are using a array of variables and an index number to build the code with.

Also notice the number on the special folder it is calling for.

It also has the appearance of having the option to save a file as a dll or an exe.

Another interesting thing if we scroll down to the bottom of the page we see.


Looking at this bottom function it looked familiar.


The left is from this exploit kit the right is from Angler EK. The differences are the variable names, the left is using “&” and the right is using “%” from some items.

Also the left is pushing to a char array then reassembling the string where the right just goes to string.

When trying to decompile the the .exe artifact the decompiler said it may be “packed” ,but looking at the file in a hex editor it appears to be corrupted or encrypted in certain sections rather than packed .

Here is a quick shot of the Silverlight after decompiling it.


Even after de-obfuscating this it is still large and a lot to navigate thru.

From a static analysis point it is difficult to tell what would and would not work in this.

It would need dynamic analysis.

Before I finish with this first pcap lets take a look at some ‘Who Is” for this site.


Notice the dates at the top, this url was not up long before it was found.



And the Scumware report.



Pcap 2

Now to the second Pcap, there were some changes from the first one.

On June 20th 2016 Brad Duncan posted another pcap in with a exploit kit dump.


Lets start this one by looking at the traffic and using filters for the streams to see what goes with what. The first filter is just “ http.request or http.response “ .


Here we have multiple gets and the first 2 were no doubt from the original infected page.

In this view we see at least 2 different landing pages, 1 flash not found, 1 flash that was found, and 2 Silverlight files downloaded.

If we set a filter of  “tcp.stream eq 0 and (http.request or http.response)” we see what packets goes with this stream.


A filter of “tcp.stream eq 1 and (http.request or http.response)”


A filter of “tcp.stream eq 3 and (http.request or http.response)” (stream two was empty)


And a filter of “tcp.stream eq 4 and (http.request or http.response)”


What does this do for us ? Since all of these point to the same IP it can help to see what is related a little easier.

If we look at the first one it tried to get a flash file but could not find the file.

The second one has a landing page and tried to get a Silverlight file but the traffic appears as though it did not get it.

The third one also contains a landing page and this time is did download a Silverlight application.

The fourth one instead of a “normal” landing page we get something else.

But let’s look at the third stream first.

If we base 64 decode the first section we se this.


We can see it is wanting “carolinamovie.swf” but the traffic supports that it was not returned but the Silverlight one was in this stream. So lets look at it.


Here we can (almost) see that it is looking for the Silverlight.  And the hex in the hex editor.


Doing a binary compare the 2 Silverlight files from the first Pcap and this one are the same.

Now on to stream number 4.

When we look at packet 174 in stream number 4 we don’t see a “normal” landing page but this.


And at the bottom we see this.


so what is this ? Perhaps this will give it away.


If we do a string search on the internet this code appears to be borrowed from this site.


With a description of “ A lightweight Javascript Libray for OpenSSL compatible AES CBC encryption.”

So they appear to be using open SSL to decrypt the bottom 2 sections.

At the time of this writing I didn’t have time to build a decoder.

Since it does appear to download a Flash file before we run out of traffic I can only assume that it does work.

One last surprise before I close.


Good luck with that borrowed name.


In conclusion, I still can’t decide if the person(s)  who write this don’t have a clue, are just testing out only certain parts of the exploit kit. If they are just trying to see what they can get out of researchers or possibly even some Collage project. There is just to much non working code in here to be a streamlined Exploit kit.

If you made it this far thanks for sticking with me.

That’s it for now.

Posted in Computer, Malware, Networking, security | Tagged , | Leave a comment