DOS Obfuscation Part 2

[Resheph]

This is the continuation of DOS Obfuscation Part 1. I wanted to make it in one piece but the post just got too long. So lets dive right in.

A beginning and ending parenthesis can be useful on obfuscating commands. But why stop at just one?!

(dir)
(di^r)
((di^r))
(((    ((di^r))    )))

Our command separator "&&" also works with the technique as with most other techniques we have done so far.

cmd /c (  ((dir))  )&&(  (  ( dir )  )  )

Needless to say that two "dir" commands are less useful but I think you get the point.

When looking at a script to see what it does it is by now very obvious that just looking at the left most column will not tell you what the complete like of code or command does. We have seen that with the "set" command already but other commands can make things less obvious. It is possible to "echo" text and pipe that output through to cmd.exe as shown below.

echo dir | cmd
(echo di^r|cmd)

You can use the "echo" command with environment variables as in the previous examples. To spice up the next example the letter substitution is done with a special character to make it harder to read. Here the "@" is being replaced with an "i" creating the "dir" command.

set [email protected]&&echo %ob1:@=i%|cmd

Another option is to replace characters with - nothing. If you tell the Command Prompt to replace the "@" but does not tell it what to replace it with, it will replace it with "nothing" meaning it will simply remove it. Even if you have more than one "@" stored in the environment variable.

set [email protected]&&echo %ob1:@=%|cmd
set [email protected]@@r&&echo %ob1:@=%|cmd

We have been setting a lot of environment variables but one trick that might be useful is to use variables that already exists. You have to make sure the exists and some language issues might exists on hosts not using the same settings as you. If I do a "set AL" command on my system it will show me the "ALLUSERSPROFILE" variable which is a common one.

C:\>set AL
ALLUSERSPROFILE=C:\ProgramData

Do you see it? it contains a "D" and as the Command Prompt does not care about upper or lower case we can build that into our "dir" command without actually having the "D" in our command.

cmd /c "%ALLUSERSPROFILE:~10,1%ir"

The next one is an odd one. The Command Prompt seems to concatenate text in quotation marks with text right up against it.

cmd /C "d"ir

Using more than one quotation mark in a row unfortunately only works with commands that are an executable file in itself. Not that it is a problem as we it shouldn't be necessary to use obfuscation when executing the "dir" command. Commands like PowerShell make wake the interest of an analyst watching what triggers the EPP sensors.

cmd /C ""Power""Shell    
p""o""w""e""rshell
p"o"w"e"rshell

We have already talked about using spaces, lots of spaces but how about no spaces? You really doesn't have to be very lucky to get the syntax right when using the Command Prompt.

cmd/C"d"ir

It seems that the Command Prompt is treating commas and semicolons as if they are not there. I have no explanation for this but the important thing is that it works. And it works well for what we are doing.

,dir
,dir,
;dir
;dir;
,;,dir
,;,;,;,dir,;
,;,echo;dir,;,|;cmd
,; ,echo;dir, ;,|;cmd
(,;d^ir)

Commands can also be started by other commands to make them less obvious. The "start" command is just one of them.

start /b /min dir

It is entirely possible to run the "cmd.exe" without even having it in your command - even without replacing characters. The environment variable "COMSPEC" contains the physical path to "cmd.exe" including the executable itself so it can be used for executing commands.

C:\>set COMSPEC
ComSpec=C:\WINDOWS\system32\cmd.exe

%COMSPEC% /b /c start /b /min dir                    
%COMSPEC% /b /c start /b /min echo dir |cmd

Above commands works like a charm.

To make it a bit less readable you can cut the content of the COMSPEC environment variable. You need the full content so you can cut the full content. It seems trivial but it does make it a little less readable by automated tools. Below environment variable is "cut" from the first letter to... the last letter of the variable content. So we get everything anyway.

%COMSPEC:~0% /b /c dir

You can also cut the first 27 characters, starting from the left, of the content of the COMSPEC variable. This will still give us the full command because it is 27 characters long but makes the command less readable.

%COMSPEC:~0,27% /b /c dir

Or you can do it the other way around. It doesn't really matter as long as you get everything the variable contains.

%COMSPEC:~-27,27% /b /c dir

Actually, rather too much than too little. The Command Prompt does not fail if you try to get too much. Below we are trying to get 99 characters from the COMSPEC environment variable even though it is only contains 27 characters.

%COMSPEC:~-99,99% /b /c dir

As we did earlier this can be combined with techniques from other examples. You can shuffle some upper and lower case characters into the mix and add a handful of spaces.

%ComSPeC:~   -99,   99% /b /c dir

Another way of putting it all together is to use COMSPEC but cut it into a few pieces and then put it back together before we execute it.

%COMSPEC:~0,25%%COMSPEC:~25,2% /b /c dir

It is all about making it harder to read for both the automated tools and for the analyst assigned to the task. We have seen how we can replace one character in an environment variable with another. We have also seen we can replace them with nothing. The next one also comes down to the Command Prompt is stubborn and resist to fail. Would it work if we attempt to replace characters that is not even present in the content of the variable? Yes, it works.

%COMSPEC:A=B% /b /c dir
%COMSPEC:*XX=B% /b /c dir

Here we attempt to replace an "A" with a "B" even though there are no "A"s in the value of the environment variable. Even replacing "*XX" with "B" does not fail even though there are no such thing in the variable.

The Command Prompt treats slash, "/", and backslash, "\", the same when used in a path. In combination with the "." (current directory) you can make the path to cmd.exe harder to catch using string comparison.

c:\windows/system32\.//\\\./\/\/.\cmd.exe /c dir

I bet you know the traditional path traversal trick with those "../../" or "..\.." in a file path. These ones goes up two folders in the file hierarchy. If they are not quoted they are dynamic. So if you start at one location, say in "C:\Windows\System32" you can add random folder names that doesn't even have to exist because you go back two folders in the same path right after the traversal. This will work with almost any number of folders as long as your full command line doesn't exceed the maximum.

c:\windows/system32\RANDOM\FOLDER\..\..\cmd.exe /C dir

Some other things to keep in mind is that the Command Prompt is very flexible. Some commands accept both "/" and "-" for command arguments so small details like that will help mask commands and hide them from EPP sensors. Those small details are important as they can be the difference that makes it work. Below two netstat commands do the exact same thing.

netstat -an
netstat /an

Some attacks from the FIN7 APT has been using loops that cycle through arrays to generate words used in commands. I must say it is very creative and combining these techniques together gives a very complete way of obfuscating commands.

Links
https://docs.microsoft.com/en-us/win...s-commands/cmd

Source
https://www.fireeye.com/content/dam/...ion-report.pdf