A Look under the hood of a batch encrypted file

The sample in question today is thanks to a Twitter thread by Nick Carr @ItsReallyNick and Daniel Bohannon @danielhbohannon of FireEye located Here about this builder being used to encode batch scripts.

After downloading the sample from VirusBay @virusbay_io that Nick linked to, and after removing the first 2 bytes (byte order mark) from the file I was able to open it up in Notpad++.

Here is what we are greeted with.


That is a lot to deal with so lets take a closer look.


Looking at this we can see several things that stand out. It is using environment variables  in the form of  “%os:~-4,1%” .

This is actually a 2 part operation. The left part “%os%” will get the expanded environment variable for the OS the right part separated by the “:”  “~-4,1” will get the position to start getting characters at and the length. Notice here though that the first value is “-4” so this means we start from the end of the  expanded value and work back 4 characters and then get 1 character.

Lets see this in action on the command line.


So here we can see that the 4th value back is a “s”. We do the same for the others.

The other thing you may notice from the boxes in the screenshot above is some plain text in between the environment variables. When the text is encountered it will be passed onto the output as plain text and no need for other processing.

One final thing you may also notice is there is a very large block at the bottom of similar looking strings like the environment variable from above but instead of something like “os” we have ‘ just a single quote. The only problem is we have to decode the top part to see if it tells us how  to decode the bottom part.


So now we have enough information to build a tool to decode this based on the observations so far.

So after a day of building, testing and bug hunting we end up with this.


Here we can see the top seems to somewhat decode to something but the bottom part is just gibberish. So so what is the problem and how to figure it out ?

Well thankfully Michael Bailey @mykill of the FireEye FLARE Team came out with a tool called “De-DOSfuscator” that works for this type and a blog post Here . After studying the blog post several different times I was noticing that the output of my tool was similar to what his tool output in Figure 7 was in his blog post . So I guess I’m on the right track but how to get the rest of this to decode.

If we take a closer look at the first part that gets decoded we can see that there is a set variable in 2 places  to set ‘ single quote  = [long string of characters] and then an “&” at the end.

We can see this better if we split all of the strings at a single “&” .



Now we can see how the value for working with the bottom part is set.

So after trying several variations of this string and no luck decoding any of those values in the bottom section I finally break down and install “De-DOSfuscator” on a VM. After after several false starts and some help from @mykill I get it set up and running the way it is shown in the blog post.

By using this tool you don’t have to understand how cmd.exe parses the files as it lets the cmd.exe interpreter do the parsing and just logs the results.

You may notice that one of the commands in this decoded part of the script was a shutdown command. Upon running the tool and the batch file I was not disappointed and the VM started to shut down, but not before saving a log file thru  “De-DOSfuscator”  of what commands it had run up to then. Here is what I saw upon restarting the VM.


Although the output is very similar in my tool as it is here, something is different.


If you are able to zoom in, my tool output a much longer string. So what is the difference ?

As the “De-DOSfuscator” intercepted the parsed values cmd peeled off the the extra “^” characters.

If we download the “Dosfucation ” White Paper from Here we can see some information about the use of the character “^”on page 13  and on page 18 we can see a screenshot of a script similar to what we are working on here.

So the next step is to hard code this value into my tool instead of extracting it and using the raw string and see if it will decode the remaining values correctly.


Great, it looks like it decoded part of it but the rest is still a mess so another new tool to just work with this part.

We now take the key/ string value from this tool and load it into the new tool along with the full section of remaining index values that start with the “%’:” (percent, single quote, colon.)


This tool will extract the decoded string thru to the final “echo “ and double quote  and then also return the remaining unused variable indexes.

Oh , this looks like there is another layer with a different index string/key.

While comparing the output from the  “De-DOSfuscator” to the decoded value from my first tool what I discovered what I needed to do was, do a string replace of “^^^” with “^” to get the correct index string/key. I added this option to automatically do this in the tool. I did it by hand the first time thru.

So after multiple passes we get to level 11 and we can see that we have whittled down on the array values quite a bit.


And finally pass 12.


Further testing of this tool to figure out what the last remaining values were revealed that it was a bug in the way the it extracts the remaining values to output. The program had reached the end and wrapped back around to Zero so it output the entire input string instead of returning nothing. I’ll have to fix that.

A closer view.


This took 1 pass to get the original “key” and 11 passes to get the final decoded string.

So thanks Nick Carr @ItsReallyNick  for trolling Daniel Bohannon @danielhbohannon .

This was a very interesting learning experience.

That’s it for this one I hope you learned as much as I did.

Thanks for reading.

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

Understanding Invoke- “X” Special Character Encoding

I say Invoke- “X” because it can be found in both Invoke-Obfuscation and in

We can find a reference to the encoding scheme in this Twitter thread Here where @danielhbohannon references the the blog post from 2010 by @mutaguchi where they demonstrate a “Hello World” encoded string. I had to translate the post to view it. You can find the post here .

We can also find the link to the site in the Invoke-Obfuscation master folder in the script “Out-EncodedSpecialCharOnlyCommand.ps1”.

The script we are going to be working with today is from another Twitter thread on September 12 2018 located Here . It is a pastebin link from @James_inthe_box.

Here is what this script looks like.


And a smaller sample view.


Just looking at this it looks like total junk code.

After reading the other blog post we have a few ideas of how to work with this so lets clean this up a bit. The first thing we want to remember is that the character “;” is used as a command separator so let separate these to a new line to make it easier to read.


Now that we have the commands on there own line we need to understand what the first one is doing.


What this first command is doing is creating a hash table to contain the values on the left side of the “= ++” to the hash table name of “${‘].}” on the right hand side.

As it goes down the list it will set the index position in the has table equal to the value Inside of “{ }” on the left.

What this will do next , or as it sets the values it will do a string replace or “lookup” of the value and the string like “${$}” will get replaced with the number 0 on the rest of the script.

Here we see what happens when we replace each value with the index number.


(I’ve restored our left hand values after doing the replacements. Always do replacements on a copy)

Now lets take a look at the next command and see what it is doing.


As we can see we now have some number inside of the “[]” like this “$(@{})”[  7  ]”

The best I understand is that this taking the the hash function name of “System.Collections.Hashtable” and in this case  taking the 7th character to build a string.

So if we take a indexed list of that string and get the 7th Character we end up with “C”.


So we go thru and replace the 3 characters and then get to this one.


In Short the “$?” will evaluate to true or false if something succeeds or failed. In this case what it gives us is the string “True” and then we take the character at index 1 of that string which  = “r”.

So now that gives us. “${*@}  =  “[Char]”  ;” and we can do the replacements for that.


Our next line will do replacements similar to the one we just did so lets do those.


So now we can see that it decoded to the string “insert”. But the way it is called it will set the value of “${‘].}” to the Signature of the function in the form of 
“string Insert (int startIndex, string value)” and you can find a list here.

So now we have 2 “+” on this next line. The first 2 are like the last 2 lines so lets do those replacements.


Now for the last value we are setting the value of  “${‘].}” to (“ie” + the Insert Sig.) character at index 27.


So index number 27 = “x”  so that makes our string now “iex”


So the last step for this level of encoding is to do the char code replacements.

There are multiple ways to get the char codes decoded from this point but I will go thru and format it so I can just run it thru my tool.


You may also notice that there is a “|” and the variable name for “iex’ at the end here.


The Final Decode.


In the usual fashion after going thru this by hand I like to build a programs to be able to just copy paste the encoded string , click a button and get the decoded value back.


As you can see from the output, the decoding for this piece of malware is far from being complete but this is as far as we will go with it in this post though.

Thanks for reading.

Posted in Malware, PowerShell, Programming, security | Tagged , | Leave a comment

What is in this file ?

The other day I was pinged about a very large .jason file that appeared to contain a large  Base 64 string that took up almost all of the file. There was a problem extracting the base64 string do to the size of the file. See the Twitter thread Here and the location for the Jason file Here on https://beta.virusbay.io/ .

When we first look at this file it is in fact a json file.


The size of this file is 2,7151,069 (0x19E4ADD) bytes / Chars long. In my experience anything over 500K chars will take to longer to render in a “Windowed” tool which also explains why Notepad++ choked on this file and sent my CPU into overdrive trying to render the text. I do have some tools that I had to increase to 700K to handle the sample code but takes a bit longer to render and refresh.For what ever reason the Hex editor seems to handle very large files fairly quickly. For this one reason is why I usually reach for a hex editor first to look at files.

After scrolling thru this file with a hex editor to verify that this is just one long base 64 string instead of many smaller ones, we need to make a working copy.

Once we have a copy of this file so we don’t mess up the original and can always start over in case we make a mistake. We need to open it in write mode and remove everything that is not part of the base 64 string and save this file.

Next we need a tool that can input this file and then output a new file that is base 64 decoded.

I wrote a tool just for dealing with large base 64 string like in this case. You could also use python or even PowerShell or another language to do the base 64 decoding. Just stay away from a windowed tool for this file.

After we get the file base 64 decoded we can then open this file up in the hex editor again and we see this.


Going into this blind with no information to go on all we have to figure this out is the way this file “Looks”.

What is the first thing we notice ? There are several repeating strings.

So this is encoded somehow but by what method ?

If this was Aes or RC4 or some other type of encryption there should be more diffusion of the encoded characters.

What else could this be ? From experience my first guess would be Xor. It could also be adding or subtracting a value for the Char code.

So what happens if we take the first 4 bytes in the third line that repeats several times and Xor the first part of this file with those values.


At the top we see the “MZP” and the highlighted part we se the “PE” part of an executable file header.

So we are on the right track but don’t yet have the full key so lets let take 12 bytes up to the first “FF” and see what we get.

That is worse so lets reduce the length until we get back to 4 bytes or we get something better. Well that didn’t help so lets just go to 16 bytes and see what that does.

Well 16 bytes (just a random amount to try) gave us some more information on this file.


If we look at a normal file that start with “MZP” we see this.


So since this appears to be what it looks like decoded we can take all of the bytes from the start to the end of the “Win32” and Xor the equal amount of bytes of the encoded file to possibly get the decoding key.


As we can see here we have a repeating pattern which is our decoding key.

Here we are doing a ‘Plain text attack” any known plaintext Xor’ed by it’s corresponding  encoded text will reveal they pattern and thus the key.


Our final step is to use a tool that will Xor the full file by the key we just extracted.

Again do to the size of the file I would warn away from Windowed tools for this.

Here we have the final decoded binary.


If you looked at the Twitter thread you may have noticed this turned out to be “banload” malware.

That’s it for this one. I’m sure there is a easier way to do this but that is just what I tried in real time on the twitter thread.

Going in with Only the file to look at we can not be sure of the contents.

So take what we know and apply it to what we don’t know and keep learning.

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

A look at a Word document macro using Invoke-DOSfuscation

The sample from this one comes from  Packet Wire @packet_Wire. Twitter thread here 

After getting the location of the Word document and downloading it. The file name was “Auditor-of-State-Notification-of-EFT-Deposit” with hash values of.

Sha1: 4C7C8B1897CA22E4E477C361DAF676D471A4F4AF
Sha256: EBDA287F6B33A0C7A689E1D8FDE7ABC708C9DFBCA2759A56CD055868B2CC0911
MD5: 35756ECC87405E42F62DEEEEF18FD43A

Let’s dive into the macro.

Using LibreOffice we can see in the code under Document objects –> vUwdwkwHZAwSRz –> Private Sub Document_open() .  It will eventually launch VBA[.]Shell with a reassembled string.


Looking at the bottom we see it contains 3 scripts.


So we can now extract these 3 scripts and open them up in Notepad++ or your favorite text editor.

Before we leave the document we also want to check if there are any property’s we may need for decoding or any forms that may have any pre-filled values that we may also need later. In this case there are none.


The screenshot above goes over the various parts that makes up this “Style” of encoding. I have decoders/string builders for 5 other versions and I am sure I have missed a few more in-between.

If we search for the two values in the beginning of the “VBA.Shell” line and to the left of the “CVar(“C”)” there are no other hits on the names so those are just junk inserted and will get handled when not found with the “On Error Resume Next” routine.

If we take a look at the script we saved as “BlUkafEw” then we can see that this entire script contains junk code that does not get used except as a distraction/time waster.


One of the next things we may notice is the heavy use of  “CStr”.


Here we see the “CStr” wraps the “Chr” function to convert a numeric char code to string. Searching the other value names inside currently return no other hits so in this case they can safely be ignored.

That leave us with the value of  CStr(Chr(99))  which is “c”.

Next let us put both of the remaining scripts into 1 document to make searching for strings easier between the 2 scripts.

As we look and search for the string to get rebuilt we can get a count of how many times the string is found. If it is only found once then it most likely junk. That does not mean that earlier in the code it does not decode to the string you are looking for.

In this case no. We still have junk as the second value after “CStr”.


The next value though has 3 hits.


So lets take a closer look at this first function that will reassemble part of the final string.


Doing a few string searches we can see that this first function contains a lot of junk code so lets clean it up to get a better idea of how the function works.


Now we can have a better understanding of how this works. The original line of code will call each function name and then each function will reassemble a string and return that to be tacked onto the original call.

So one of the first things we will want to do is go thru all of the “CStr” function and replace those with the char for that char code.

So another new tool. We input the combined 2 scripts and the string we are looking for “CStr” and it will find and replace all of them with the char.


Now that the char codes are replaced with the Char we can go onto the next tool that will reassemble the final string.



Now that the easy part of rebuilding this long encoded string is complete we now move on to the harder part, interpreting what this is doing.

After viewing this Twitter thread from Shiao Qu @ShiaoQu17 here it got me looking at this in a different lite. We need to break up the string in sections.


The first section that is highlighted will build the cmommand for cmd.exe to launch the decoded part.

The next section is the Encoded string.

The final section is the directions how to decode the center part.

Here is part 1 cleaned up a bit. Although I still don’t fully understand “exactly” everything it does. I do have a real good idea how it works.

Part 1Cleaned

In the second part, everything after the first equals sign to the closing parentheses “)” is the encoded text we will be working with.


In part 3 we will get an idea of how this string in section2 gets decoded.


That is still hard to read so lets clean that up some.


I may have gotten carried away cleaning this string but the important part for me is the 2 values highlighted “2153, –6”.

What this does is takes the encoded string and set an index value of “2153” which is the string length and takes the last character in the string then advances backwards 6 chars to the next value. So our first char will be “p” and then count backwards every 6 chars to get our decoded string.

In my tool I just reverse the string and count forwards.

I seen the video here by Karsten Hahn @struppigel for a different type and he does a better job of explaining the way that the call works at the end for that type and returns the decoded value.

The trick here is that when it will automatically remove the extra characters as it runs under cmd.exe. If the string is not cleaned correctly when decoding by hand the the index will be off and return the wrong output value for the decoded script. One other thing I found was in Powershell we generally get rid of the tick mark “`” as an escape char but here it appeared that it was paired with “^”  looking like it would be removed also. After more testing I only ended up removing the Cmd escape char of “^”. Or in the case of my current tool I do a string replace of “^`” with “*” which is one character that was not used in order to keep the proper length. The replacement really was not needed in this case.

Here is the decoded script and tool.


And the final decoded script formatted for better reading.


Although this looked very complicated from the start. Especially if you already read the scripts of the builder here by Daniel Bohannon @danielhbohannon or read the white paper located here it did not turn out to be as difficult as it first appeared to beat the encoding .

If you don’t care to really understand how it works you can always drop the document on ANY.RUN @anyrun_app Like this sample was here .

Just scroll down the right till you find the poweshell.exe process , select on that. Then view more information to get this screen.


I still have a lot more to learn about how some of the obfuscation works. I was still able to extract the final payload which was the whole point anyway.

That’s it for this one I hope everyone learned as much as I did.

Posted in Malware, PowerShell, VBScript | Tagged , , | Leave a comment

A closer look at “NetSupport”(Rat) top 2 layers

This post is based on the blog post by FireEye located Here.

I was given a private .saz to look at by someone else that gave me the entire infection chain.

In this post I will only be doing 2 levels of decoding..

While looking at this saz file, FireEye published the post above. This gave me a better idea of what to expect as I was pulling these files apart.

What I will be showing here is a more lower level on how the script is decoding the first 2 levels. After that it requires that the server  for the second level that it calls out to, to still be online and available to get the next level to download.

This sample is after it has already fingerprinted the system and sent the encoded data to the server.

At the end of the FireEye post there is a list of several hashes of files. We will be using “229f69a0b21740c91bfd0174e63cc0b7be3a7f5f9d6819cc3bdf3cf117ada9ff”  which can be found on Hybrid Analysis Here , Virus Total Here , (I re-uploaded to) VirusBay Here in case those that want to follow along only have an account there.

Now that we have our sample lets take a look.


That is pretty dense so lets make a copy and then make it “Pretty”


That is a little better but it is still highly obfuscated. It appears to have a hex string at the bottom that gets reassembled and is using a crazy method of string replacement / rebuilding. The clean won’t get output if you just walk thru the code in the debugger. So we have to figure out what each section decodes to and then do the string replacements by hand for our first script..

If we take a closer look at what this script is doing we can see the first part here is just putting the first few letters back together then is has a “Choice” in the parentheses.A

For some reason which I don’t fully understand yet it will always choose the last char in that array. So the next value to tack on is “i”. Now this would be a pain to go thru by hand so what else can we do ?

If we look close, they are in brackets and we can decode each section using some simple html code.

First part looks like this.


Second part of the line.


So now it goes from the long crazy string to this decoded version.


So lets use this method and decode the rest of the lines and see what we have.


When using the above decoding method to extract the decoded string be sure to mind the matching pairs for the square brackets. If you add any extra code including the string like highlighted in the green you may end up with other results.

Also note that this would most probably not run after we do the replacements but does help to understand what it is doing.

Lets take a closer look at the decoding function. By the time we get here the hex string at the bottom has already been reassembled and converted to a byte array and assigned to the the array variable of “ kijuqmoha”


So what is this thing actually doing ?

It starts with the last char of the key then

Xor’s the byte array with that value. Next it adds 1 more char to the left then Xor’s the bytes from the last output by these to Chars.

It will continue on until is uses all of the chars for the key.

I wrote a tool to help visualize the output. This came about from a conversation between Lee Holmes and myself.  He has a post Here


In this tool I started with the full key then reduced to the last char. The decode starts with 1 char and increases to the full key. That is the way I made this decoder.

In this test we can see we can start with the full key or the last char as long as we add/remove the same direction.


Next I wrote another tool to test the same idea but reducing to first char instead of the last.

As you can imagine, changing sides using the same data and key will give different output.


Back to decoding the first level hex values.

We input the cleaned up hex string and the key of “c~J=e~~kk” we get get back this.


We can also step thru the code in the web browser debugger until it outputs the decoded value in a anonymous function then extracting it from there.

If we look at the bottom of the code after we pretty it up we see this.


This second level will use the same decoding function to decode the hex array at the bottom but with a twist. It will input the original function code as a string and the current running code as a string and a “Seed Key” as a decimal array thru the function “encKey” to to generate a new Key to finally decode the hex array at the bottom.

If we look at this part of the code we see if is sending the 2 pieces of code into the key builder .


One other thing we notice here is in the caller function it is tacking on something else to the Caller code.

If we step thru the code in IE debugger we end up with this “MozillacallerFunctionText” getting tacked onto the original code that gets run.

After messing with this for a few days and not getting anywhere I started to wonder if this was supposed to fail with the catch block.

If we look at this comment  in the code below it appears as if this code is supposed to be run by Windows script host rather than the browser scripting engine.


I developed this tool to try and generate the key needed for the decoding tool.

Stepping thru the code in the browser debugger can give us an idea of what needs to be run thru the function to output the proper decoding key.

Our first try using the added string will produce this.


Testing that key  in the decoder failed to properly decode the hex string at the end.

Back to the drawing board on what to input. After failing several more times I started to look for a way to brute force the key. If I understand the math correctly it would be 256 to the 10th power possible combinations to find a key. That is way to many to try them all.

The way this is set up you can not do a normal plain text search to find the Xor Key.

I wrote another tool to test brute forcing a 10 Char key using a know plaintext search which worked very well on a normal 1 level Xored data.

Do to the nature of the way the function works in this case the key would be thoroughly diffused  and you can not look for a string the same way as a normal 1 level Xor.

The decoding is tied to the way the key gets cut up and used in the rounds. So even if you had a know plain text and know encoded text I have not found a way to run it backwards to get the key.(yet)

So that leaves us with figuring out what has to go into the key builder.

This code is similar to a hashing function in that if you change 1 item it can drastically change the output.

After lots of trial and error and dumping what gets output by the debugger we end up with this for the original calling input.


And for the current running code we use this.


You may notice that both inputs do not have the hex arrays in the strings.

We also need the Seed Key  “var key = [181, 205, 244, 42, 206, 126, 77, 88, 31, 20];”

We are finally able to generate a proper key and use that to decode to the next level.

There is nothing like seeing the proper output after so many hours of researching.


Here is what it looks like pretty.


If we take a closer look at the top there are 2 values that are encoded and use the function “geturl” to decode.


All this function does is go thru the string and if the index mod 2 = 1 then that char gets saved to the output.  After that it is a simple reverse string to get the final string.


In the original saz file I was looking at, the early scripts were using this same function for decoding some values.

Since the server was down for this URL that was as far as I could go on decoding the levels and have not gotten anymore recent samples to try and go further.

That’s it for this one. I hope you learned something like I did.

If I left any questions unanswered catch me on Twitter @Ledtech3

Thanks for reading.

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

PowerShell encoding used for Emotet Downloader

I first ran across the SecureString usage in this twitter thread where  @Anyrun_app is talking about a version of “Fake Net” to get all of the C2’s here https://twitter.com/anyrun_app/status/966227622899351552

There are a few methods listed in this thread by different people to run the PowerShell malware to get the output but as usual I like to dig deeper to see how it works.

This link below was actually the first thread I had seen, with “PO3T @PO3T1985”. All of it does not show in in the first link.


We also see the thread here from @JAMESWT_MHT of a long thread of malware documents used with Emotet.


So lets dig in and figure out how the encryption works.

Lets take a look and see what the original PowerShell script I seen looks like.

If we look on the anyrun_app site at the extracted PowerShell script we see this.


And if we copy it to Notepad++ we see this.


After a little more digging we find out that this was most likely generated using @danielhbohannon Invoke-Obfuscation Out-SecureStringCommand.ps1 found here https://github.com/danielbohannon/Invoke-Obfuscation/blob/master/Out-SecureStringCommand.ps1

So how exactly does this thing work ?


The first part is just standard setup script encoded using Invoke-Obfuscation to run this next part that we are really interested in at this point.


This is “Marshaling” managed to  unmanaged code to decode the encrypted data (that is in the base 64 string) into memory as a “SecureString” then run the decrypted code.

We can get more info here on SecureString.  https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.security/convertto-securestring?view=powershell-6

The last part is where it gets piped into ConvertTo-SecureString with a key value.


The 2 dots between the two integers represents that it is an array from 224 down to 201.

You will also see it go the other way from low to high and the length depends on the key length chosen.

That will be the numbers used for the key to decrypt the data.

Lets Base64 Decode using Unicode encoding this string to bytes and see what we have.


If we look close we can see a possible delimiter of the char “|”  a possible base 64 string and what looks like a Unicode Hex encoded string with a null byte after each value. The first part of that looks like garbage.

Lets take a closer look at the beginning of this base64 string.


All of the samples I looked at had the same hex value at the beginning but what is it?

After some more searching I stumbled onto this page.

This is found in the source for PowerShell itself.


We now see that it is a header to indicate that this data was a Secure string exported to an encrypted string.

So what does our bytes look like after we ignore the header bytes and base 64 decode the remainder of the string ?


Now that is looking a bit different. We now have a #2 , a base64 string and hex bytes.

If we go to here we can now see the format of how this data works.

So we now split to Version | IV | Encrypted Data . We only need the IV and data.

The IV is the middle base 64 string that we will decode to byte() in Unicode format which in this case will give us 16 bytes of data for the IV. While testing decoding to UTF-8 encoding did not produce the correct bytes for the IV.

The next thing we need is the key.

So I built a tool to speed up building the array.


From the example from the builder we can see you can also supply the key as a full array.


We now have all of the pieces to the puzzle and just need to decrypt the data.

It says it is AES but does not say which Version / Flavor to use .

I had a Rijndael Managed version handy so I used that using PKCS7 padding mode to decrypt with.


So now we end up with these decrypted bytes.


Although it is readable it is still in UTF-16/Unicode format. So I need to convert the bytes to UTF-8.


And we finally end up with these UTF-8 bytes.


A little better view.


As we can see here it splits the string of Url’s using the Char “?” and attempts to download and run a file from each one.

The “NSB” appears to be a random number value used for a file name that gets run.

Going back and looking at the PowerShell source code we find in “SecureStringCommands” the function called “ProcessRecord()” on how to unpack and decrypt this Base 64 string.


It is nice to find this at all. I keep forgetting the the PowerShell source code is available online now.

I also found the plain version of the AES class https://msdn.microsoft.com/en-us/library/system.security.cryptography.aes(v=vs.110).aspx

The one without the different Modes (CBC,EBC, etc..) It looks pretty much the same code I used.

Well that it for this one I hope you found the discovery as interesting as I did how how the internals worked.

Posted in Malware, PowerShell, Programming | Tagged , , | Leave a comment

Hidden .Net Resources “Are Your Tools Finding Them” ?

This file was found thru Twitter https://twitter.com/0x7fff9/status/936301229612961792 and https://beta.virusbay.io/sample/browse/106366f1fe0f39232bc86be49ecbad4a

This sample appears to be a test piece of Ransomware written in dot Net with 2 binary resources that do not show up in normal tools. No obfuscation was used to “Hide” the resources. I was able to build my own test program that would respond the same way.

So really, they are not necessarily hidden, it’s just that some tools don’t see them.

I have run across this problem before but don’t see it very often when viewing the decompiled dot Net files.

If we look at the recourses in few different tools we don’t see this data.

Lets start with PEStudio , I had reported this problem a couple of times and have gotten no response about it.

Here we see PEStudio next to ILSpy


It can be found here https://www.winitor.com/binaries.html

Next we have MITEC  EXE Explorer


It can be found here http://www.mitec.cz/exe.html

Finally we have Resource Hacker


It can be found here. http://www.angusj.com/resourcehacker/ (I assume this is the same one everyone else uses)

The only thing I can think of is they are not enumerating every type of resource or because the data has no file extension associated with it is not being seen.

So lets save the resources data to a file. We end up with a file called “gray.resources”

Opening it up in a hex editor we  see this.


This would not be easy to extract without more information, so after some trial and error I got a tool to extract the binary data to .bin files.


This simple tool will enumerate all of the resources, list the names and type then extract just the data of  “Type Byte[]” to the folder with the name and a .bin extension.

As you can see this one only had 2 items. I have not tested it yet on other files.

Lets take a look at the first one.


And the Second


These look to be encrypted/encoded so lets go back to ILSpy and see how.


The highlighted area is where it tells us what to do with the extracted resources.

At the top we see the key used for decryption and test4 at the bottom is AES CBC mode.
It also has a hard coded Salt value.

Since I didn’t have a tool for this type yet I just borrowed the code from them and after fixing 1 bug that may have been introduced in the decompilation  I got it working.


Notice anything in the out put ? 0x4D5A(MZ)

So we now have an extracted and decrypted binary.

Here is the second one.


They just used the AES function to hide the registry “Run Path”.

What we end up with is the program that does the actual “Bad Stuff” including encrypting various files using a folder/ file extension list.


As of Last night that Bitcoin value did not exist.

Towards the bottom we have a “Random” password generator. The problem is it does not appear to save it anywhere to use for decryption later that I have found so far.


They are also nice enough to delete the shadow copies too.


I also looked up the GUID and you can find it used in several places.

I have no Idea if this thing will even run and do what the code suggest it will do.

The point to this whole post was not to show the malware, but to highlight the problem of mainstream tools not being able to find or show these types of resources.

There could be more than meets the eye that is not being shown as it was here.

That is for this one. Go check your tools.

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