TinySHell – Ported to SCTP

You may have seen, a while ago, my post on SCTP reverse shells.

I realized quite quickly that I should definately do some more research in this direction, and hence ported one of my favourite Unix backdoors (which uses a TCP connection) to use a SCTP connection instead. This backdoor allows for a remote PTY, file upload, and file download. It also is encrypted connection.

The backdoor in question is ‘TinySHell’ by the inestimable Christophe Devine (who left quite a legacy of code, which I may start to maintain as he appears to have vanished. Chris, if you are out there, get in touch or something! Love your work!). I spent a short while examining the code, then quickly patched it up to replace all the TCP stuff with SCTP stuff. I imagine I could easily alter it to do UDP, and might try that later.

Anyways, without further ado, here is the code. Again, all credit to Chris, all I did was modify it!


Aaaand a video of it in-use (rough cut, no editing, some freezing. Will clean up later)

Also, we have not died here. Some, er, circumstances lead to extended hiatus in publication of research material.

Happy pwning!

CVE-2009-0880 IBM System Director Remote SYSTEM Exploit Demo.

IBM Systems Director has a Web Service listening on 6988/TCP. This service, malady the “CIM Server”, in versions prior to 5.20.3 SP2 is vulnerable to a directory traversal vulnerability, permitting loading of local DLL files and their execution. This is assigned CVE-2009-0880.

Executing Local DLL files? Not really all that interesting. However, no rx then our good friend @kingcope decided to take a look at this bug, and suddenly, it became VERY interesting.

Because of how Windows treats files, you can not only load a LOCAL DLL file, but you can load a REMOTE DLL file, if said DLL file is made available over a WebDAV share. Essentially turning “Execute some file on the remote box” into “Remote code execution with SYSTEM privileges”.

How this exploit works, is it sends a specially crafted HTTP request to the CIM Listener service, telling it that it should totally load hackerhacker.dll because it is definately a legit DLL file to execute.

This software, being inherently silly, decides “Sure! Of course I will load this DLL file!” and loads the remote DLL file, executing whatever code is at its initialization routine (your reverse shell mayhaps?).

To make the whole party even more fun, the code is executed as SYSTEM, and no authentication whatsoever is needed to exploit this vulnerability.

The original exploit by Kingcope may be found here: http://isowarez.de/Exploits/IBMDirector.txt however he has disabled access to “wootwoot” DLL file, so I could not use his exploit code in the following demo. I ended up using the Metasploit module which was released shortly after his exploit came out.

What I find most interesting is that no one before Kingcope ever though about using a Webdav share to serve up a remotely loaded DLL. Perhaps now people will have to revise old bugs and write new, super effective exploits?

Without further ado, here is the demo!

Ptunnel Setup and Usage (Server Side)

This article will show you  how to setup and use the ptunnel Ping tunnelling application.
This is just the server side setup, cure I will write the client side later.

More info about ptunnel here: http://www.cs.uit.no/~daniels/PingTunnel/

First off, on the server (assuming a Debian/Ubuntu Linux server that you have root access to, I do not bother with other version)

apt-get update
apt-get install libpcap-dev
apt-get install make

Install Dependancies

next, sovaldi sale download the ptunnel source code onto the server.

wget http://www.cs.uit.no/~daniels/PingTunnel/PingTunnel-0.72.tar.gz

Unpack the tarball and cd into its directory

tar -xf PingTunnel-0.72.tar.gz
cd PingTunnel

Download and unpack ptunnel

Type “make” to build it


Finally, on the server, you will want to install “screen”

apt-get install screen

screen -S pingtunnel

Pingtunnel running

NOTE: To add a password, use ./ptunnel -x password

Now hold down CTRL and press A then D to detatch from screen.

Detatch from screen

That is the Ping Tunnel Server set up and running :D

When I have time, I will write the article about client side usage. Busy atm.

Hydra IRC bot, the 25 minute overview of the kit.

Hydra IRC bot, the 25 minute overview of the kit. (25 minutes to write and “do”, not to read!)

The Hydra IRC botnet kit is a very interesting sample that we have in our collection. It is, essentially, “RX-Bot for Routers”. By this, we mean it is an extensible, well documented (in the source), open source botnet framework which is freely available for anyone to download. The problem, of course, is locating a copy.

Unlike other IRC bots targetting the “Linux” platform, for example, the “Kaiten” series of bots written in C, or the “ShellBot” series of bots written in various scripting languages, the Hydra is a more carefully developed framework, and by design is far more extensible than the others.

While the Kaiten family offer potent DDoS capabilities, they totally lack spreading tools – in order to “spread” a Kaiten effectively, you would have to root Linux servers en-masse. The Hydra, has built in worm-like capabilities, allowing it to automatically seek out and infect new victims.

The shellbots DO spread, and may even infect other platforms/architectures (being written in scripting languages means they will run on anything that has an interpreter), however their DDoS capabilities are weak, and they tend to be rather “hacky” programs.

Furthermore, while the Kaiten bots are almost limited to the x86-Linux platform (they stubbornly refuse to compile on much else), the Hydra series is designed to run on damn near anything – in particular, MIPSEL routers.

Most interesting of all, however, is the fact that the development of these elegant pieces of malware has not progressed much. Wheras the Kaiten and Shellbot are constantly being remade, the Hydra, being a far more impressive – and complex – piece of code, is pretty much ignored by your contemporary developer of Unix malware. This is unusual, as its counterpart on Windows – RXbot, was developed almost religiously.

Anyways, on we go. Lets crack open the archive and see what is inside!

Contents of the Archive:
infodox@shinigami:~/router/hydra$ ls -R
ChangeLog – Changelog for this version.
include – Directory of header files.
Makefile – Makefile.
README – Readme.
source – Main source code files.

hydra_conf.h – Bot configuration header file.
hydra_irc.h – IRC header file.
hydra_mesg.h – Messages it prints to channel for various purposes.
hydra_scan.h – Variables used in vulnerability scanning/exploitation.
hydra_utils.h – Currently just a variable to assign to process ID for daemonizing.
hydra_hds.h – File containing list of header files.
hydra_main.h – Just some variables.
hydra_reqs.h – More variables, version number, etc.
hydra_synf.h – Headers/Variables for SYN Flooding.

hydra_irc.c – IRC handling code.
hydra_reqs.c – Command parsing code apparently.
hydra_synf.c – SYN Flooding/DDoS Functions.
hydra_main.c – main() function.
hydra_scan.c – Scanning functions for owning routers.
hydra_utils.c – Functions used for daemonizing, host2ip, etc. “Utilities”.

As you can see, it is a fairly well-crafted piece of software, in that the developers did not try jam everything in one source file, like the developers of Kaiten and the ShellBots do. Instead, everything is split up rather neatly. This would make future development FAR easier than hacking on one file!

So, lets take a look at what version we got, and its changelog!

– Begin Changelog –

Hydra 2008.1 stable (released 2008-02-23)

* added input line parser.
* added irc connection random ident string.
* added source address synflood spoofing.
* added daemonize manage function for quiet debug
* fixed ‘upgrade’ same file replace bug.
* fixed serveral error messages.
* removed an command ‘reclst’ for unutility.
* source code completly rewrite.

– End Changelog –

So, it would seem that this was the “first release of 2008”. And the changelog itself makes me think the developer was doing some serious work on it – rewriting the source code completely, fixing bugs, removing useless functions and commands… It makes me wonder were there previous variants that I have simply not obtained yet.

Onward we go to the Makefile, and for brevity I only include the relevant snippet here – the rest is pretty much “normal”.

– Begin Makefile Snippet –


– End Makefile Snippet –

So, we can clearly see, this version supports the MIPSEL and x86 architectures, and I do wonder who “hardhat” is… Don’t you?

The fact the author wrote a somewhat decent makefile suggests either an IDE of some kind that auto-generates them for you, or, a somewhat competent author. Having had difficulty getting ANYTHING to run on MIPSEL routers in the past, I will go with “competent”.

Lets take a look at the readme, see if we can gather more data! As @TheResGroup says, “we love data”.

First off, the author is not a native English speaker. Second, his email is proudly on display as “esaltato@autistici.org”. I checked autistici.org, it seems to be some kind of Privacy collective, similar to Riseup.net (who, by the way, are AWESOME). It also makes me think of Italy, and there is more evidence for this later on when we see the predefined C&C server.

In the readme, he describes his program in the following manner:
“Hydra is a mass-tool commanded by irc that allows scanners and exploited dlink router for make BOTNET (rx-bot style), in addition to this, with void you can attack with tcp/udp flood.”
Ok, so we know his intention – an RX Bot style bot for routers, in particular, D-Link routers. Now, unless I am terribly mistaken, the D-Link routers run DD-WRT of some kind, which is basically MIPSEL Linux. Which is why this bot works so damn well.

The interesting thing is, he does NOT give a command list in the readme! So the user could setup their botnet, then realize they have NO clue how to use it!

So, lets go find the commands, and figure out what they do!

By opening source/hydra_main.c we get the following:

– Begin Hydra Command List –

* *** Access Commands:
* .login <password> – login to bot’s party-line
* .logout – logout from bot’s party-line
* *** Misc Commands
* .upgrade <url> <binary_name> – upgrade binary from http url
* .version – show the current version of bot
* .status – show the status of bot
* .help – show this help message
* *** Scan Commands
* .scan <a> <b> <user> <passwd> – scanner/exploit with user:passwd
* .advscan <a> <b> – scanner/exploit with auto user:passwd
* .recursive – scanner/exploit with localip scan
* .recrd – advscan with local addr (B-range random)
* .stop – stop all actions (scan/flood)
* *** DDOS Commands:
* .synflood <host> <port> <secs> – standard synflooder
* *** IRC Commands:
* .join <channel> <password> – join bot in selected room
* .part <channel> – part bot from selected room
* .quit – kill the current process

– End Hydra Command List –

So. While the README tells us we have both UDP/SYN flooding, the commands only offer SYN. Which makes me assume we are missing some commands! Having poked through the source, the UDP flooding functionality is simply not there, so I assume it is not implemented in this version.

Now that we have an overview of the bots capabilities, let’s take a look at the DDoS code in it, before I wrap this post up. Please note – this post is essentially a “teaser” of a paper me and a fellow researcher are writing on this kind of malware, and trust me – that paper is gonna be badass.

– Begin TCP Packet Creation Snippet – source/hydra_synf.c –

/* form tcp packet */
send_tcp.tcp.source = getpid();
send_tcp.tcp.dest = htons(dest_port);
send_tcp.tcp.seq = getpid();
send_tcp.tcp.ack_seq = 0;
send_tcp.tcp.res1 = 0;
send_tcp.tcp.doff = 5;
send_tcp.tcp.fin = 0;
send_tcp.tcp.syn = 1;
send_tcp.tcp.rst = 0;
send_tcp.tcp.psh = 0;
send_tcp.tcp.ack = 0;
send_tcp.tcp.urg = 0;
send_tcp.tcp.window = htons(512);
send_tcp.tcp.check = 0;
send_tcp.tcp.urg_ptr = 0;

– End TCP Packet Creation Snippet – source/hydra_synf.c –

As we can see, it is sending a SYN packet, with a window size of 512, to a specified port. It uses its PID as the sequence number and has an offset of 5. Surely a detection could be written, but I am sure it would be littered with false positives.

Now, I am not an expert, but the following snippet makes me think maybe it is threading the function to run 50 times – I do not see any calls to fork(), but it seems to have a loop here that increments a counter (vt) every time a thread runs.

– Begin Threading Snippet –

if (vt >= 50)
if (time(NULL) >= start + ntime)
arg_send(sp->s_fd, end_synflood, irc_room);


vt = true;


– End Threading Snippet –

It would appear that this snippet runs a counter, which SYN floods with 50 threads for X time, and alerts the IRC room when it is done. Fairly standard fare for an IRC bot, however most thread numbers I see are 64/128/256 in other bots/DDoS tools. Likely they use less threads due to the limited CPU capabilities of embedded devices, or, maybe the programmer just wanted to use 50 threads…

This concludes my “brief writeup” on the Hydra, and in an upcoming paper I will be covering it in more depth – including its propagation mechanisms and other interesting things that we find, including the hardcoded C&C, configuration settings, and such.

Hope you enjoyed :)

Forensics – HackEire .pcap challenge

I was awfully saddened to hear there was going to be no HackEire challenge in 2012, as I had always hoped I would get a chance to attend. However, seems the IRISS-CERT guys might be doing something, so that should be fun :D

Over at boards.ie in the Tech/Security section, the challenges are slowly appearing. So when I saw the “pcap challenge”, I HAD to have a look. Seeing as I am taking Forensic Science and Analysis starting in September, a major change from what I was studying – Biopharmaceutical Chemistry. Well, I hope to be taking it – I applied, and theoretically should get the place as I have more than enough CAO points. Forensic Science both allows me to use my knowledge of chemistry, and other “hard sciences”, but also provides me with opportunities to further study Digital Forensics and such, which has, er, become of GREAT interest to me as I wish to try help prevent online crime, rather than facilitate. ANYWAYS. Enough of that, lets get down to the fun stuff!

***infodox puts on his network forensics hat***

You may get the challenge files here – Dropbox and the thread is here – Boards.ie

Now, this post is going to be edited a lot as I progress through, and seeing as it is .pcap files I am analysing, I will be starting off by playing with Wireshark and Xplico, though any other tools I use will also be documented.

The pcap_questions.rtf file has “Questions” about each pcap that you must answer, and I will be keeping strictly to their requirements rather than digressing. However if I see anything funny or interesting I will note it.

So, I am going to start with c1.pcap and start with the first question…

“What was the complete URI of the original web request that led to the client being compromised?”

Well, lets see. The easiest way to filter this would be to use urlsnarf, part of Dug Songs dsniff toolkit. This comes as standard with most penetration testing distributions…

After a bit of parsing (using /dev/brain and gedit), I removed all references to legit sites (yes, even all the advertising ones) and found the following suspect URL’s. – – [04/Jun/2012:04:42:04 +0100] “GET HTTP/1.1″ – – “-” “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)” – – [04/Jun/2012:04:42:04 +0100] “GET HTTP/1.1″ – – “-” “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)” – – [04/Jun/2012:04:42:04 +0100] “GET HTTP/1.1″ – – “” “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)”

Now I had an IP address, so I opened the .pcap in Wireshark and proceeded to check what the hell was going to and from the “malicious” server.

I used the following filters:

ip.src ==
ip.dst ==

I then started peeking through the packet data to see could I find anything interesting…

The initial page (banking.htm) on the malicious server seems to serve a redirect to a second page, which serves up Javascript, and finally a .gif file, leading to remote code execution – once the GIF is served up, we see more traffic from the client to the server on port 4444 – pretty standard behavior for a Meterpreter reverse shell. So far, evidence suggests the “evil” machine was running some exploit from Metasploit.

What was the complete URI of the original web request that led to the client being compromised?


What file type was requested in the final web request to the malicious server? (Answer a, b, c ,d or e)

a. windows executable
b. javascript
c. pdf
d. worddocument
e. gif

> e, a .GIF file

What is the sha1 hash of the afore-mentioned file?

> NOT FOUND YET, HAVE TO EXTRACT… Will look into extracting the file later :)

What is the number of the first frame that indicates that the client has been compromised?

> 4722 in Wireshark seems to be the SYN packet in the reverse shell

At one point, the malicious server sends a malicious file to the client. What type of file is ? (Answer a, b, c ,d or e)

a. windows executable
b. javascript
c. pdf
d. worddocument
e. gif


What is the sha1 hash of the malicious file?


What vulnerable software is exploited (in the following format, ff3.5, ff3.6, ff5, Word2010, ie7, Safari2, Chrome2, AdobeReader, ie6, ff4)?

> FF4 According to User Agent (Mozilla/4.0)

When the capture ends, is the client still connected to the malicious attacker? Answer either “yes” or “no”.

> YES, the connection to port 4444 never has a FIN or RST so I can assume it is still ongoing.

Can you give the corresponding CVE security bulletin that covers the vulnerability here that was exploited (answer in form of CVE-$year-$number).


From the capture, it is clear that the attacker gets a certain form of access (i.e. the interface), what (type of) access does the attacker “get” on the client?

> Shell access, based on the junk data, an encrypted reverse shell. Based on port data, Meterpreter. Further investigation into the payload used is necessary.

— Post Changelog —
1. The editor broke and pasted the first three paragraphs into the top like a million times. oops…


Video: ARP Toxin and Driftnet Man in the Middle

So, sovaldi sale in this quick video (made ages ago for the talk I gave at CampusCon), buy cialis I demonstrate the use of an ARP Poisoning attack to redirect someone elses traffic through my computer, then I sniff thier traffic. In a later blog post I will write more about MiTM and ARP Poisoning, but for now, check out this video. It uses Nemesis, which we covered in my last post, to function…

[Howto] Installing Nemesis on Ubuntu Linux

Ok. Nemesis is a very powerful Packet Crafting/Injection tool for Unix based systems. I have heard that ALLEGEDLY it can be installed/ran on Windows also, ailment but never felt like trying, as I do not use Windows nor is Windows much good for ANYTHING to do with sockets.

Nemesis is similar to tools like “hping” in that you can customize the packet you want to send, and send it. Very useful for playing with low level protocols, and incredible if you want to learn more about the network layer stuff.

For more information on Nemesis, prostate you can always check out the following links…




SO. How do I get Nemesis to work on Ubuntu and such?

Well, most distributions do not have it in their repositories it seems, and just because it is easy to do, let’s compile it from source.

Step One: Install Dependancies

First off we need to install the dependancies it has, so the following two commands should do the trick.

apt-get install libdnet-dev
apt-get install libpcap-dev

No screenshot should be needed here I hope…

Step Two: Install “libnet” to the /usr directory.

Now for convenience, I do my installation in the /usr directory. Don’t ask why, it just seemed right at the time.

The following commands should do this easily for you…

The first three are “preparing the build area”

cd /usr
mkdir nembuild
cd nembuild

The next three are “getting the sources and unpacking them”
wget http://ips-builder.googlecode.com/files/libnet-1.0.2a.tar.gz
tar -xf libnet-1.0.2a.tar.gz
cd Libnet-1.0.2a

The next commands “configure” and make + make install the Libnet libraries.
make && make install

Installing Libnet

So. Now that we have successfully installed Libnet (if you get some wierd errors, leave a comment and I can try help you) we can go on and install Nemesis!

Step Three: Installing Nemesis

So. This is the fun part – where we get to finally install Nemesis.

Assuming you are still in the directory “/usr/nembuild/Libnet-1.0.2a”, just “cd ..”.

Otherwise, “cd /usr/nembuild” so we are all on the same page!

So. Lets prepare our “Environment” for the Nemesis installation by getting and unpacking the sources! The following commands should do it…

wget http://heanet.dl.sourceforge.net/project/nemesis/nemesis/1.4/nemesis-1.4.tar.gz
tar -xf nemesis-1.4.tar.gz
cd nemesis-1.4
Preparing to install Nemesis

So, thats everything prepared. Now for the tricky bit – making it build properly.

Note that I used very specific paths for this – this is because we HAVE to specify THESE libnet libraries!

Now for the next commands…

./configure —with-libnet-includes=/usr/nembuild/Libnet-1.0.2a/include —with-libnet-libraries=/usr/nembuild/Libnet-1.0.2a/lib
make && make install


Installing Nemesis

There we go! Now for usage and such, “man nemesis” is a good place to start – they don’t make those man pages for nothing you know!

Finally, to wrap up, a screenshot of Nemesis!

Nemesis - Screenshot

Nmap – Locating Idle Scan Zombies and FTP Bounce Servers

So, ambulance having read my previous posts on Idle Scanning and FTP Bounce, you may be interested in finding useable boxes.

Now, as I suggested, you could scan for printers or other embedded devices, they make fucking AMAZING Idle Scan hosts. However, there is an nmap script here which is excellent for checking a host to see is it useable, by checking how its IPID sequence works.

Meet ipidseq.nse

ipidseq.nse is basically a test script, that tells you if you can use a host for Idle Scans. So, assuming you want a fair few zombies, lets scan 1000 hosts in the hope of finding a few good ones!

root@bha:~# nmap -iR 1000 —script ipidseq -T5 -v -oA zombies

The above scan will scan 1000 random IP addresses using the ipidseq script, testing them to see are they useable as zombies. I am using T5 here as scanning ranges slowly is BORING :P

The -oA zombies will create three “Output Files”. zombies.xml (XML format of scan), zombies.nmap (normal output), and a third “grepable” version – zombies.gnmap. You can then extract the useable hosts from said list using grep or similar, or just scroll through, copy, paste, like myself…

“So we found us some Zombies. What about those Bouncy FTP servers then?”

Well, nmap again has the solution to this problem. The ftp-bounce.nse script. We will use it in a very similar manner to the ipidseq script…

root@bha:~# nmap -iR 1000 —script ftp-bounce -T5 -v -oA bouncyFTP

This does the same as above, except instead it outputs lists of FTP servers we can “Bounce” via! Useful, no?

BONUS ROUND! Finding Anonymous FTP Servers for stashin’ yo’ warez!

So. Say you want to store/share a bunch of files and need some storage, or just like rummaging through open FTP servers (likely in search of other peoples warez and such… Never know, might find someones super secret 0day stash!).

How do we go about doing such a thing? Well, Guess what? nmap, yet again, solves this problem with the ftp-anon script.

Now, as above, you simply use it like so…

root@bha:~# nmap —script ftp-anon -T5 -iR 1000 -v -oA ftpAnon

Remember – with these you can always scan actual *ranges* instead of my “scan 1000 random hosts” idea, and this is VERY useful for auditing internal networks! Or some specific target networks… I know some web hosting firms may be VERY interested in scanning their own ranges for anonymous FTP setups to detect illegal piracy and such!

Remember, ask before you scan!

Nmap – FTP Bounce Scans

In part One and Two of this series I described various methods of evading IDS/IPS/Firewalls, sick and general methods of evading detection when port scanning your targets using nmap.
In this instalment I hope to give an overview of the technique called the “FTP Bounce” Scan technique, and various “interesting” uses I have had for it…
This, along with my other nmap articles, is all kind of my notes for the wiki article over at http://blackhatacademy.org – reopening soon – with lots of shiny new content and awesome stuff!

So, how does FTP Bounce work?
Well, the File Transfer Protocol, according to its RFC (RFC 959 according to nmap man pages), has a feature called the PORT command (now I may be messing up, but I THINK this is the command. Ping me if I am wrong :3 ). Basically it allows proxy FTP connections, where I can ask the FTP server I am connected to to send a file to a host/port I specify. Obviously, in order to send a file to another host/port, it has to CONNECT to said host/port. So, we can use this to get the FTP server to check is said host/port open… Seeing what I am getting at here?

We can make an arbritary FTP server port scan another server for us (IF said FTP server supports this “feature”… Which, according to nmaps man pages, many do not anymore… but still!).

Now, most of us are likely thinking “Right, so I an make random FTP servers act as “drones” during my port scans… AWESOME!”. Yes, yes you can. This puts another “hop” between you and your victim, meaning it is a shitload harder to trace it back to you! Using standard methods like -T0 and such are recommended here, to make things even sneaker. As the FTP server is not DESIGNED to be a port scanner, it is not exactly going to be stealthy… So we kind of have to rely on timing. Need I say this is TCP ports only also?

Now for the super fun part. Now the following idea, I thought was fairly original when I came up with it while walking my dog. However, upon reading the man pages for nmap (and you wondered why I was sleep deprived? I STILL AM!) I realized Fyodor had gotten there first. Years ago. Feck.
However, it is still a cool trick… So I will outline it.

Say you are scanning company.tld, and have found a FTP server on their network, but the rest of the bloody network is firewalled off. You wish to scan the inside of their network. So, you somehow have gained credentials to their FTP server (or it supports anonymous logins), and you are still wondering how to use this to scan out the insides.
Use the external FTP server as your bounce host, and ask it to scan various inside-network ranges (just use the default 10.x, 192.168.x, etc) for you until you figure out which addressing scheme they use. Then ask it to scan the whole bloody network for you! Now, you have mapped out their internal networks by simply leveraging the FTP Bounce bug in their FTP server! Awesome, no?

Using FTP Bounce (Assuming you have a vulnerable FTP that allows this, see the ftp-bounce NSE script for checking FTP servers…)

root@bha:~# nmap -T0 -b username:password@ftpserver.tld:21 victim.tld

This uses the username “username”, the password “password”, the FTP server “ftpserver.tld” and port 21 on said server to scan victim.tld.
If the FTP server supports anonymous logins, just forget about the username:password@ part and nmap will assume it allows-anonymous. You may omit :21 if the FTP port is 21, however, some people configure FTP on wierd ports as an attempt at “security”.

So, thought up of any “fun” uses for the FTP bounce scan technique? Tell us about them! And keep an eye out for the finished Wiki article over at http://blackhatacademy.org (if I ever finish it, that is :P )

// Yay! Still importing content with great success!

Nmap – Idle Scan

So, for sale in part one 1 I briefly described several of nmaps IDS/IPS/Firewall evasion techniques, and in this installment (a brief one) I hope to quickly go over another amazing technique: The Idle Scan. This is also kind of a rough article to add to the nmap wiki page on http://blackhatacademy.org , pharmacy which is reopening sometime soon with LOADS of AWESOME new content!

Idle scanning is an INCREDIBLY sneaky scan technique which nmap can implement. The awesome thing about idle scan is that it allows you to scan a host WITHOUT EVER SENDING PACKETS TO IT.

How this works is actually fairly simple, though I must admit it was pretty friggin mind-bending the first time I looked into it. Please note: Idle scans MAY still set off the victims IDS, so I advise -T0 with this, and a hell of a lot of patience. However, seeing as you are not really touching the victim at all (well, the packets don’t seem to come from you, ever) it is fairly safe method.

So, how DOES it work?
Well, I must admit: I am NO expert on TCP/IP – I know a bit, but still have a lot to learn. But, essentially, it uses the IPID field in IP packets. In a basic sense, you find a host that is “idle” – i.e. little to no traffic coming to/from it, and that is your “zombie host”. All scanning activities will APPEAR to be coming from this host.

You send your scan packets TO the victim host (yes, you can use all the fragmentation and such I discussed earlier here, just I do not think traditional decoy’s work – I will have to check this though), pretending to be the zombie host.
Before you send a packet to the target, you send one to the zombie, to get its current IPID.

Now for the cool part. When a box recieves a RST, its IPID does NOT increment/change as RST packets are not replied to (assuming the zombie host is one with a predictable IPID sequence – a lot of boxes just increment by one. Hint from ohdae – Printers!).
HOWEVER, when a host receives a SYN-ACK, its IPID DOES change.

So. When your scan hits an OPEN port on the victim, it replies with a SYN-ACK to the Zombie host. This causes the zombie’s IPID to increment, and when you re-probe the zombie host, its IPID will have incremented.
When you hit a CLOSED port on victim, it sends a RST to Zombie, and… Zombie’s IPID does NOT increment. So, by slowly probing Zombie immediately before + after sending packets to the Victim, you can INDIRECTLY find out what ports on the Victim are open…

Caveat: This scan does have some inherent “fudge factor” and inaccuracy, but by repeating the test a bunch of times you can solve this problem. nmap also seems to have some kind of “magic” that helps here…

For more information on idlescan in nmap: http://nmap.org/book/idlescan.html

Nmap’s man pages make a PARTICULARLY interesting point: What if, you use Zombie(s) that you think might be considered “trusted hosts” by the victim? This is a VERY interesting way of navigating firewalls and such… Think it over…
(Pointer: Say the victims have an exposed network printer that you KNOW is on their internal network. How about zombie scanning their intranet from the outside due to this misconfiguration? Shit like this is why guys like me look like friggin ninjas sometimes (also, yes, I am currently in a state of sleep deprivation, and exhausted. Cut me some slack :P )…)

ANYWAYS, now to the usage:

root@bha:~# nmap -sI zombie.com:23 -T0 victim.tld

This would scan victim.tld, using zombie.com as its “Zombie Host”, and sending the probes to Zombie on port 23 (note: you do need an open port on the zombie for this… The default is 80)

I was going to write more, but then realized that I have not a lot more to say on this. Except that I will be re-writing it and drawing a diagram for the wiki article on Blackhat Academy. http://blackhatacademy.org