Angler Exploit Kit Steganography

When I first started working with exploit kits I started with Angler EK.

I was learning how the redirect from the compromised site worked and building tools to decode them. Once you get to the exploit kit landing page then the work really begins. There were several different encodings and encryptions used to conceal what was on the landing pages.
With that much data to go thru I did not work much with the flash files as most of my spare time was used trying to figure out a new encoding for the landing page or the PHP redirect and then build tools to quickly decode them.
Now that I have a little more experience and more tools in my toolbox I decided to go back and take a look at a later version of the flash file before they disappeared from the internet.

Our first sample from here

We see the layout of the flash file and how obfuscated it is.


Anything with “this.Var_1.” gets a replacement.


Now if we skip forward in time to this one and take a look at the PCAP file we see that there are 2 different flash files downloaded.


Lets take a look at the first one.

We first see a picture file and no binary data file.


We also notice that there are only 3 script files in this one.


Hmm, looks like it might be working with a picture file.


What are these numbers as a string ?


This Look like it might do something . Lets save this and take a closer look with Notepad++.




Even obfuscated you can see what this third section does. This is a RC4 decryption that uses the “&” instead of “%” 255. (I’ve seen both used in different decoders)

Now lets do the replacements and see what this looks like.


This first part is getting us set up , I’m mainly just showing it with the replacements.


Here you may be able to see my notes. Method_1 will kick things off and call the function to get and extract the data from the picture file then it passes that data to method_2 to do the decoding using the key from function “lII1I1()”. It will then load the bytes returned and go from there.


Here we see it gets the picture data using the built in function to work with bitmap data.

It will create 1 loop inside another to extract the the data using the height and width as the upper limits for the 2 different index values.

It will next get the first pixel a position 0,0 and convert the RGB values into an integer value and then “&” it with “16777215” to use as a output data length limit.

This will keep looping thru until it gets all of the data into a new byte array.

It then runs it thru the RC4 decryption to decode.


Now we have enough information to build a new tool.


This tool is simple. We select the Picture file, input the extracted key string and click a button and it returns the decoded hex output.


Next we just copy paste this into a hex editor to see what we have, and as you can see it is another flash file.

We now save this in the hex editor as a swf file.

After opening it up in JPEXS Free Flash Decompiler we see that this is a large file.



There is a lot going on in this one and will take some time to work my way thru it.

I went thru another one from later and it was much smaller so this may have still been in the development  mode. The later version  also used the same decoding function but a different decryption key.

That’s it for this one.

Thank you for reading.

Posted in Computer, Malware, security | Tagged ,

Ghost In The Wires Paperback Ciphers

I received the book in mid December 2013 as a early Christmas present and completed reading it on December 24th 2013 and then began working on the ciphers.

I was first trying to copy all of the ciphers  by hand to a notepad document and it was taking a long time and discovered I had several mistakes as I would go back thru and double check.

Next I got the bright idea of trying to scan the pages into a text document. That did not work very well either, the scanner program used did not recognize all of the characters in the font used in the book and was more of a problem to fix them than to try and copy by hand, so that was what I did, copied every 1 and 0 and everything else by hand to a text document. Needless to say it took a while to get it done and I still found mistakes as I was going thru the ciphers to solve them.

It has been some time since I have worked with any ciphers so I needed to go back and look up how to work with them. I spent the first bit of time trying to see just what type of ciphers are out there and how to work with them. There are allot of pages on the internet to help.

Next I looked up to see if anyone had already posted all of the answers.

I first ran across this page about the Hard Cover version of the ciphers.

That gave me an idea on how to start and what kind of ciphers were used in the hard cover version. They are different in the soft cover version.

Once I was about a quarter the way thru I ran across this page for the soft cover version.

This site had the answer to one of the ciphers I was working on and my tool that I created did not agree with the answer they had, so I emailed Fabien Sanglard to ask about it, but before he had a chance to answer I found the mistake in my program and I was able to verify the results posted on the site.

It was his suggestion that I write up my answers and post them for others to view.

I already had several of my own tools for other things and created more as needed and then converted some of the C++ versions from the hard cover version to VB.Net to help me. Next there are also allot of tools online to help with different ciphers but they do not all work the same or give the same results for the same Cipher.

When I was over half way thru I ran across this page by the co creator of the ciphers
Disa Johnson that was written April 29 2013 they explain about the way the ciphers were written and at that point only 1 person had submitted the correct answers.!/2013/04/ghost-in-wires-ciphers-paperback.html

That post got me looking closer at the patterns of the ones I have already solved and I was able to apply that to more and solve others. (Mainly the rail fence and Play Fair ciphers)

Most of the ciphers have at least two levels to decipher them. Some were just reverse the string then split them into the proper words after the first level was done.
Not all of the ciphers require you to have the answer to the one before to solve them so I was able to skip around a little as I got stuck on some.

Once you get the cipher deciphered to get the question, you still need to go to the book for that chapter and find the answer to the question. Then you are done with that chapter.

Next I will go thru and tell what they were. Some were just a matter of running them thru every tool I could find till I got the plain text, I was able to solve some of the column ciphers with pencil and paper. As you go thru them you do start to notice certain patters and are able to eliminate certain ciphers that would not have been used.

I will not post the answers to the questions that were revealed in the ciphers here, you will have to read the book and find them on your own. This post is just for the ciphers and the questions they revealed.

I mainly just copied from my notepad notes what my output was.

Chapter 1: Rough Start
Max vhlm hy max unl wkboxk ingva B nlxw mh ingva fr hpg mktglyxkl
The cost of the bus driver punch I used to punch my own transfers

This cipher is a standard rotation cipher they left all of the spacing and just rotated the alphabet. It is encoded with “Rot 19” and decodes with “Rot 7”. There are 26 letters in the alphabet so to figure this out we subtract 7 from 26 to get 19 that tells us what it was encoded with.

I started with a tool that I made that would rotate what ever number you wanted from 1 to 26. If you rotate 26 you get back to the same text you started with.



Chapter 2: Just Visiting
Estd mzzv esle elfrse xp szh ez ncplep yph topyetetpd hspy T hld l acp-eppy
This book that taught me how to create new identities when I was a pre-teen

This is another rotation cipher. Encode with Rot 11 decode with Rot 15.

Chapter 3: Original Sin
pbzfsobp dkfobtpkx lq pbkfi ppbkfpry aoxtolc iixz lq abpr bobt pbzfsba cl bmvq obail bpbeQ
secivres gnirewsna ot senil ssenisub drawrof llac ot desu erew secived fo epyt redlo esehT
These older type of devices were used to call forward business lines to answering services

This is another rotation cipher but this time they added a twist they reversed the string.
At this point is was getting time consuming to click the button for each number so I created a new tool that would do all of them at once.


In order to see if one of these are correct we need to read from both sides and see if it reveals the plain text. I have another tool that will reverse a text string but that was a pain to copy paste all of the time so I added that ability to the program. if you look close at the screenshot above you can see the reverse plain text as Rot 3 so lets reverse it with this tool and see what we get.


Now that is easier to read and quicker to see if it is a “Rot” cipher or not.

Chapter 4: Escape Artist

the name of the mainframes I hacked at usc in the arpanet days

This cipher is a Atbash cipher where the alphabet is just reversed  a=z b=y and so on.

I created a tool for this one too.

Chapter5 : All Your Phone Lines Belong to Me
jbi ujt veo eco ntk iwa lhc eeo anu uir trs hae oni rfn irt toh imi ets shs leu

I took a course in this subject when i ran from the juvenile authorties l (extra letter on the end for fill)

This is a column cipher. They are split into three letters, if you stack them from left to right top to bottom then read down the right column you can see what the plain text is.

The tip by looking at it is that they are split into groups of 3.

Chapter 6: Will Hack For Love

name the company where bonnie was employed when we started dating

The two equal signs on the end is a dead giveaway that this is Base 64 encoded.
There are several tools on line to decode this but I already had a tool from other projects that made this easy.

Chapter 7:Hitched In Haste

number of door codes i had for pacific bell central offices.

This is a Keyed substitution cipher. It uses the key of gte.

Several tools are available online to encode decode this one.

Chapter 8: Lex Luthor
‘siass nuhmil sowsra amnapi waagoc ifinti dscisf iiiesf ahgbao staetn itmlro

I said I wasn’ This famous magician While being a smart ass to prision officials

This cipher is a column cipher if we start stacking the groups of letters starting from the right and read down on the left side then the plain text is clear.

A clue on this one was that they were split into equal parts again.

Chapter 9: The The Kevin Mitnick Discount Plan
tvifafwawehes hsesoonvtlimaeloemtcagmen irnoerrldony

this version of novatel firmware allowed me to change my esn

This is a rail fence cipher the clue given for the number of rails is the amount of groups the text is split into. In this case it is 3.

Chapter 10: Mystery Hacker
gnkusr ooursnsisti ttnotoihiec rolwaintmlk ovtgp

got root on unlv work station using this simple trick

This is a rail fence cipher also. It uses 5 rails and the cypher text is split into 5 parts.

Chapter11: Foul Play
ow gw ty kc qb eb nm ht ud pc iy ty ik tu zo dp gl qt hd

This is a playfair cipher it uses a standard alphabet minus the letter j and no keyword.

When I read the title it made me think of playfair, but none of the titles really seemed to have anything to do with the cipher chosen.

Chapter 12: You Can Never Hide
idniidhsubrseognteiuignuhrzdalrd ietfetinmeablnigorcsnuatoieclei

i identified this number as belonging to eric using unauthorized caller id

This is another railfence cipher uses 2 rails.

Clue was text is split into 2 parts.

Chapter 13: The Wire Tapper

manager who i tipped off about wiretaps on teltec’s lines

This is another “Rot” with a reversed string. encode Rot 24, decode rot 2, reverse the string.

Chapter 14: You Tap Me, I Tap You
c2VuaWxzJ2RhZHltbm9zcGF0ZXJpd2VodHRjZW5ub2NLcm RuYXNlbGVnbmFzb2xvdHlsZm90ZGFob2h3dG5lZ2F5d GlydWNlc2xsZWJjYXBlaHQ=

the pac bell security agent who had to fly to los angeles and rK connect the wiretaps on my dad’s lines

This one was given away by the equals sign on the end as base 64 again. Decode and then reverse the output to get the plain text.

Chapter 15: How the “F” did you get that?
ud mn cf ub mw re lb is ba of gx ty qc qh il ea ym nx bz ub he cf th is


This is a playfair cipher using a normal a-z alphabet minus J and no keyword then reverse the result string.

Chapter 16: Crashing Eric’s private party.

i asked eric for the key to this phone company facility

This one I had some trouble with at first until I used the correct key.

This starts with a phone dial cipher to convert the numbers to letters.
once you get the letters then it deciphers with the Vigenere cipher using the keyword heinz.

The problem with this one was, the keyword was not in the section of text that the answer to the previous question came from like the previous ciphers. They only listed the persons first name and not the last. You had to get that from another location in the book. And thus the keyword was the persons last name.

Chapter 17: Pulling back the curtain
100 0000 10 1 01 001 00 1000 1 010 11 000 0 0000 11 000 000111 00011 10000 11111 11110 11000 00111 10000 11111 10000 11111


What number is this 310-477-6565

This is Morse code as 1’s and 0’s instead of dots and dashes. First you get the letters and numbers as a dot would be 0 and a dash would be 1, then you reverse it the dot would be 1 and the dash would be zero. Read up and down to get the plain text

I made a tool to help with this too.


Chapter 18: Traffic analysis


i identified the fbi cell phones that where calling eric by hacking into this ceppwxktmzsbhzc

This one is hex to start with and then we convert to ASCII. Next we run it thru a Vigenere decoder with the key IBFAL (the shortened and reverse of the previous answer).

Chapter 19: Revelations

te el ae fn ba et hs cv rd ni ya js pw rl
hr an mo af ig nw oe oe ie tt ws oe he ne

the real name of an fbi agent whose cover identity was joseph wernle

This one is a column cipher also. I discovered this one by accident using another tool I built that will split a string into how ever many characters you want up to the length of the input. When I split them in two and copied them to a notepad it just happened to only be wide enough for half of them to fit wrapping the remaining half to the next line.

Read up and down to see the plain text.



Chapter 20: Reverse String
yo kb pn oc ox rh oq kb oh kp ge gs yt yt hg sa li mt ob sa po po mk pl md


This is a playfair cipher using the key of fbi .

just a note some of the play fair ciphers were split into 2 chars.

Chapter 21: Cat and Mouse

darrell santo’s voice mail password was this

This is hex that converts to ASCII then  run thru a Vigenere decoder with the key TRW.

Chapter 22: Detective Work


This is a playfair cipher using a normal a-z alphabet minus the letter J and no keyword.

Chapter 23: Raided
1001 0111 01 00 0 0 101 011 1111 1110 1011 1111 101 0110 1111 1101 110 010 100 0 0100 11 1011 1011 000 10 101 01


This one starts out as Morse code with the 1’s and 0’s reversed (in my tool). Next it is run thru a Vigenére Autokey  tool with a key of DDI.

Chapter 24: Vanishing Act

code for a wanted person in las vegas

This one is a playfair cipher with the Key fibdonuts then reverse the output to get the clear text.

The trick here was the spelling of the key. “Donuts” not “Doughnuts”

Chapter 25:Harry Houdini

nhy ite kmn ryo ogm wef eho ctt ntn oau tto sum ooa lge i

i lost once working out at the gym the amount of money

This one was split into 3 chars and then stacked starting from left to right top to bottom

then read from bottom left up.

Chapter 26: Private Investigator

11 0100 000 111 010 0 011 0010 000 010 11 10 1101 01 01 1 000 1 1111 01 0 011 1 010 1 1000 000 010 01 00 01 01 011 00 1101 0010 1 010 1 10 0
001101 110010 001101 110010 001101 100 0000 1 10 101 0 111 0 10 010 0101 0000 11 10 001 10 1 011 00 100 1 10 0 00 0 00 1 000


i looked for infants  that were born in a different  _______  When researching new idendenties

This one starts out with the Morse code. We need the forward and reverse then stack them.

Read up and down zig zag to get the plain text.

I used the Blank space here to help me focus on the answer to the question revealed in this chapter.

Chapter 27: Here comes the sun
the host name which was used for the security bug database at sun microsystems

This is an autokey cipher using the the key of state.

Chapter 28: Trophy hunter


a security flaw in this program allowed me to break into novell’s firewall

This one starts with Hex encoding, we convert to ASCII. Next we use Vigenre Autokey with the key of elmer , next we reverse the output to get the clear text.

Chapter 29: Departure

the name of the employee that set me up an account on novell’s 3com dial up terminal server

This one is a playfair cipher using the key of sendmail. I used the decoder on this site instead of this one because to properly decode the cipher you had to uncheck the box dealing with double letters.

next reverse the output of that to get the plain text.

Chapter 30: Blindsided

the reason i was fired from the law firm in denver

This one uses the autokey cipher with the key Nunley . Next reverse the output to get the plain text.

Chapter 31: Eyes in the sky

this person was tricked into sending me numerous vms security holes

This one uses the Autotkey cipher with the key of consulting. Next reverse the output to get the plain text.

Chapter 32: Sleepless in Seattle

i compromised this user’s password through network monitoring to hack into shimomura’s server

This one is an Autokey cipher also with the key of Clift. Next reverse the output and to get the plain text.

Chapter 33: Hacking the Samurai

010 1 0001 101 0 111 000 100001 01 101 001 00 111 00 00 1111 000 01 111 1 10 000 0000 1001 000 11 0000 0 111 0 0 0101 010 110 111 111 0 1111 1
101 111 1101 110 01 00 010 111 000 0100 111 01 100 00

I was looking fo* * (the) source to this phone on shimomuras server

This one starts out as Morse code as 1’s and 0’s again. You have to get the forward and reverse of the output  stack them and then read zig zag from upper left.

Chapter 34: Hiding in the bible belt

this employee at intermetrics uploaded the motorola compiler for me

This one uses the Bifid Cipher and the keyword of oki. Next you reverse the output to get the plain text.

The interesting thing about this one is I used the tool located here to decipher it with. with more research on this cipher I discover that it also uses a “period” or length of text to work with. I then looked at these two online tools and

This is where I discovered about the period. So after some more investigation I discovered that this cipher was deciphered with a period equal to the length of the cipher text.

Chapter 35: Game Over

someone logged into my “marty” account on this system from the well

This Cipher is also a Bifid cipher, decipherd using the same tool as above.

Key = Marty and the “period” = Cipher text length.

Chapter 36: An FBI Valentine



Chapter 37: Winning the scapegoat sweepstakes


Chapter 38: Aftermath: A Reversal Of Fortune

001101 110010 001101 110010 001101 110010 001101 110010 11 00 011 00 10 110 0000 11 00 1001 110
0100 111 10 11 00 1101 1001 0100
10 100 11 01 101 0010 11 101 011 111 00 100 010 1001 001 1 101 01 010 1010 01 0 1110 10 0111 010 010


The use of statistics what not of much use in the solving of these ciphers in regards of Identification of them with the exception of the obvious things such as Hex,base 64 encoding Etcetera.

I found 3 online cipher ID programs and none came close to the ones I tried to run thru them.

One was from a program that is called Crypto Crack than can be found here: . It still has some bugs in it and I was able to crash it using several of the cipher crackers although the ID part did run without problems.

Next was from a online site here. . This runs the statistics on the input unknown cipher.

Last one is this one and it looks like it has been updated since the last time I tried it. .

This one gives extended information about the cipher.

The best use of statistics was the use of “N-Gram” files  for scoring potential plain text.

On this page for the Bifid Cipher I found information and a “C” version of a cracker program.

After converting the “C” to VB.Net I was able to then use the scoring system in several other programs.

See Bifid Cipher Under tools.

Using the tools to try and find what cipher I was dealing with the top result was always for the “Running Key Cipher” so being stuck on chapter 36 I made a tool for that.

See Running Key Cipher

The Index of Coincidence (I.C) I one method for testing what type of cipher it may be.

Looking at the results of 5 Playfair   ciphers used in this group of ciphers we see that the I.C. score is varied.

11: playfair cipher no keyword, just normal a-z alphabet -J  I.C. = 0.0384  (38 chars)
15: playfair cipher no keyword, just normal a-z alphabet -J ,reverse string  I.C. = 0.0346  (48 chars)
22: playfair cipher no keyword, just normal a-z alphabet -J   I.C. = 0.0541   (30 Chars)
24: playfair key= fbidonuts,normal a-z alphabet -J, reverse string   I.C. = 0.0506    (30 Chars)
29: playfair key of sendmail, do not Encode double letters (down and right one spot), reverse string output. I.C. = 0.0411  (72 Chars After Clean extra)

As we can see by these results the ones without a key had low scores along the lines of a Vigenère cipher with the exception of the one that was only 30 Characters long.

The last one had a lower score than the two biggest I.C scores.

So and I.C. score does not always prove what kind of cipher it may be.


I have shown a few tools above but will show a few more below but will not go into great detail on how they work because of the complexity of them would require an article about them on their own.

When I find time I will do one on the Hill 2 Cipher and the plain text cracker I made.

Bifid Cipher:

This was the first tool I made with the scoring system so the source code is kind of ugly but works.


Here we see the unsorted result of running the keyword list thru the program. The keyword list is the list of words from the previous result in this case this is Chapter 35 cipher with the keywords from the result of Chapter 34. From that list the program will create a new list of keywords using the original keyword forwards, backwards and spiral which is why there are so many close together.


Here is a sorted list, since these are negative numbers the lower the number the closer to Zero it is the better the score. Some online tools would change the keywords into several different directions on how they laid out in a alphabet. As you see in this example the keyword was prepended to the alphabet and those letters were removed from the remainder of the alphabet.

The interesting thing here is whether the alphabet was used forwards or backwards it still decrypted the text the same.

I have updated this with the new Quicker Score output to speed this up.

Running Key Cipher:

The running key cipher uses a section of text, perhaps from a book or a newspaper, etc. to encrypt  the Phrase that you want to hide.

Here we will use text from chapter 35 that I was able to locate online.

Here is the Phrase we will encrypt pulled at random from the chapter 35 text.

Plain: Several weeks earlier JSZ had set up an account for me on escape com

Here is the text we will use to encrypt it by, again chosen by random.

ET: Shimmy was winging his way to Raleigh JSZ sent me a message that left me up in the air Hi This AM my dad had

Although this text is longer than the Phrase to encrypt the tool will only use what it needs.



When I first built this tool there was no automation so I would pick a section of text and step thru it 1 letter at a time but after working out the scoring system I added the automation.

This program will clean all formatting including punctuation, Spaces,number etc. .

Here we assume that the key text is somewhere in in the chapter 35 text so we will load the N-Gram file in this case Bigrams(2 Characters) and  the entire text from chapter 35 that I have a previously cleaned version to speed things up a bit.


A newer version of this program and others I added an extra part of the scoring system to only output the top scores that greatly improved the performance of the programs that used this system.

So far the Bi-gram file was good enough to discover the correct output in every cipher tool I have built so far as long as I had the correct input for the cipher type, as in the wrong input key list will not return decrypted text properly.


In conclusion I would like to thank everyone that posted papers or created web pages on the many ciphers that are out there.

Next I may try and tackle the Kryptos K4 cipher I have a few Ideas that I would like to try.

(None of those worked out but this came close )

Here it is now in November 2016 and I have not had the time to find the solution to the last 3 ciphers but will post this anyway since I could not find any others with this many online.

I will update this if and when I get the answers to the last 3.

If you made it this far, Thank You for reading this rather long blog article and I hope you learned something  from it as well I as I did writing the programs and discovering the inner working of so many ciphers.

Posted in Ciphers, Programming | Tagged

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 . 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 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 , , | 3 Comments

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

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

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  , 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

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 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 , | 5 Comments