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.