Camouflaging Nmap Scans

By: Whistler

It’s a boring Friday evening - mortals with brains the size of peanuts fill up the local joint exposing whatever is left of their gray matter to the savageness of fermented glucose whilst my DNA donors enjoy the comforts of the flickering images emitted by the crude cathode ray.

I decide to do something productive and as always, end up seated on my cat torn chair staring hypnotically at yet another cathode ray of a much finer resolution. It’s time to fire up my favourite tool and do some poking around. It is indeed odd how my idea of a perfect Friday night is spent cruising along electronic waves, woven and intertwined so perfectly as to permit transport from any one point to another. Ah the wonders of the world wide web. Enough ranting for now then! Let’s get down and dirty.

I like to hide my tracks whenever I am in the mood for a little snooping, or at least make it a little less obvious so I don’t have to go through the bother of reapplying for another ISP account. Not as though it has ever happened before in this part of the world! Some of us possess that little nagging fear every time we fire up a port scanner and some of us are numb to any sensation what so ever. To those of you who suffer from bouts of emotional distress, I will show you in this article how nmap can be used to help camouflage your scans.

Nmap was written by Fyodor. Its an awesome multipurpose tool and comes in handy during reconnaissance. Here are some of the port scanning features :

1) Various types of port scanning techniques

-sS (TCP SYN Stealth port scan)

o This option basically sends out TCP SYN packets to the target. To those of you who aren’t familiar with what a SYN packet is, go search for TCP/IP tutorials on the web or get a good book

o If the port is open / a service is listening on the port, the host will send a SYN ACK packet back to the source of the TCP SYN packet. The attacking machine will then send a RESET packet to terminate the connection. This is sometimes referred to as a ‘half-open’ scan.

o If the port is closed, the attacker’s system will receive either no response, a RESET packet or an ICMP port unreachable packet depending on the target machine type and network architecture.

Let’s look at a trace of a TCP SYN scan targeted at a Linux box. I have edited the output to display only relevant details of the scan.

10.230.100.201.43926 > 10.230.100.180.77: S 862546202:862546202(0) win 1024
10.230.100.201.43926 > 10.230.100.180.12: S 862546202:862546202(0) win 1024
10.230.100.201.43926 > 10.230.100.180.27: S 862546202:862546202(0) win 1024
10.230.100.201.43926 > 10.230.100.180.26: S 862546202:862546202(0) win 1024
10.230.100.201.43926 > 10.230.100.180.72: S 862546202:862546202(0) win 1024
10.230.100.201.43926 > 10.230.100.180.56: S 862546202:862546202(0) win 1024
10.230.100.201.43926 > 10.230.100.180.61: S 862546202:862546202(0) win 1024
10.230.100.201.43926 > 10.230.100.180.89: S 862546202:862546202(0) win 1024
10.230.100.201.43926 > 10.230.100.180.37: S 862546202:862546202(0) win 1024
10.230.100.201.43926 > 10.230.100.180.100: S 862546202:862546202(0) win 1024

The section above captures TCP SYN packets originating from host 10.230.100.201 and port number 43926. These packets are sent to various ports of the Linux host 10.230.100.180. If you notice, nmap sends out ten SYN packets and then waits for the reply. I scanned only ports 1 – 100 of the Linux host and as you can see from the trace above, the destination port number does not start at 1 nor does it increment linearly. In other words, nmap has randomized the destination port numbers. The reason for this? Signatures of intrusion detection systems sometimes detect port scans through a certain amount of packets destined to incrementing port numbers during a specific interval. Alas, IDSs have become smarter and utilize other methods to detect port scans.

Let’s look at the reply.

10.230.100.180.77 > 10.230.100.201.43926: R 0:0(0) ack 862546203 win 0 (DF)
10.230.100.180.12 > 10.230.100.201.43926: R 0:0(0) ack 862546203 win 0 (DF)
10.230.100.180.27 > 10.230.100.201.43926: R 0:0(0) ack 862546203 win 0 (DF)
10.230.100.180.26 > 10.230.100.201.43926: R 0:0(0) ack 862546203 win 0 (DF)
10.230.100.180.72 > 10.230.100.201.43926: R 0:0(0) ack 862546203 win 0 (DF)
10.230.100.180.56 > 10.230.100.201.43926: R 0:0(0) ack 862546203 win 0 (DF)
10.230.100.180.61 > 10.230.100.201.43926: R 0:0(0) ack 862546203 win 0 (DF)
10.230.100.180.89 > 10.230.100.201.43926: R 0:0(0) ack 862546203 win 0 (DF)
10.230.100.180.37 > 10.230.100.201.43926: R 0:0(0) ack 862546203 win 0 (DF)
10.230.100.180.100 > 10.230.100.201.43926: R 0:0(0) ack 862546203 win 0 (DF)

Here we see the replies to the ten TCP SYN packets sent earlier. The Linux box is sending RESET packets back to the scanning machine indicating these ports are closed.

10.230.100.201.43926 > 10.230.100.180.22: S 862546202:862546202(0) win 1024
10.230.100.180.22 > 10.230.100.201.43926: S 2778997755:2778997755(0) ack 862546203 win 5840 (DF)
10.230.100.201.43926 > 10.230.100.180.22: R 862546203:862546203(0) win 0

Port 22 on the Linux box is open. The short trace above shows you that port 22 returns a SYN ACK packet back to the scanning machine. The scanning machine then sends a RESET packet to tear down the session.

-sT (TCP Connect scan)

o This is a more polite scan that completes the three-way handshake with available ports. The attacker will start off by sending a TCP SYN packet to the targeted port. The target if listening will then return a TCP SYN ACK packet to the attacker. Instead of sending a RESET packet like the SYN scan, the TCP Connect scan will complete the three-way handshake by sending a ACK packet to the target and a FIN packet to politely tear down the connection. This scan is less likely to bring down the host.

o If the port is closed, the attacker will receive either no response, a RESET packet of an ICMP unreachable packet.

o TCP Connect scans will be detected by the target host e.g web server since a full connection is established. Nevertheless, even SYN scans are easily detectable by intrusion detection systems and firewalls with IDS functionality.

I will not attempt to walk you through a trace here since you probably would have gotten the idea of what happens during a scan from the earlier trace. Even better, fire up a sniffer like Windump if you’re a Windows user or tcpdump if you’re on Linux. Then fire off nmap, do a port scan and sniff away my luvlies.

-sA (TCP ACK scan)

o The ACK scan is typically used to get through packet filtering devices. A simple packet filter may prevent SYN packets from entering the network. This will prevent external hosts from initiating connections to the internal hosts. The packet filter will need to allow ACK packets into the network so that internal hosts can communicate with the outside world without the outside world being able to initiate any connections.

o This will not work with stateful packet filters that maintain the state of the connections via a state table and will only allow the corresponding ACK packets to enter the network.

o Nmap will send an ACK packet to the target. If a RESET packet comes back then we know that the ACK packet managed to get through the packet filter. If there is no response or an ICMP unreachable packet is returned, the nmap will assume that a packet filter is obstructing the packets and label the target port as ‘filtered’.

Do take note that the purpose of a TCP ACK scan is not to find open ports on a host but to audit the access rules of a packet filter.

There are also a variety of other port scanning techniques such as the TCP FIN, Xmas Tree and Null scans. These techniques however do not work against Windows based systems so unless we know the operating system of the target machine, will be of no use to us.

These scans did work against my Linux box though. For the Null scan, nmap sends packet with no flags set. Closed ports reply with a RESET but an open port does not reply. The Xmas scan sends out packets with the PUSH, FIN and URG flags set. Similar to the Null scan, closed ports responded with a RESET packet and open ports with nothing. FIN scans reflect a similar response by sending TCP FIN packets to the target.

Now that we are familiar with the main nmap scanning techniques, we shall delve into other features that will allow us to randomize our scans and camouflage our ip addresses.

Camouflaging your ip address

Here’s where I clear up a lot of misconceptions. Whenever there is mention of hiding ones ip address, the first thing I often hear is ip spoofing! Nope – wrong answer. This article is targeted at all you newbies out there who think ip spoofing will hide your ip address when you want to perform a ping sweep or a port scan so hear ye hear ye…

You cannot spoof your ip address and expect to receive a reply from a ping or a port scan

Calm down and think about it for a moment. Let me think of a good analogy. Ok got it. Think of packets as a letter (you know the ones you send to friends far, far away to keep in touch). On letters you write the destination address and the return address. Let’s say Adam writes a letter and sends it to Eve. Adam writes the destination address of Eve on the letter and his own as the return address. When Eve replies to Adam’s letter, she will address it to the return address. Similarly hosts will reply to packets based on the source address. It will send the reply of a packet for example an ICMP (PING) reply to the source address indicated in ICMP request packet.

Now if you spoof the ip, what you are doing is writing someone else’s address as a return address on a letter instead of yours. Think of is as Adam sending a letter to Eve and in the return address field, inserting the address of God. When Eve receives the letter, she will reply and send it to the return address, which is God instead of Adam.

So back to ip packets, if you spoof the source of the ip address to that of another remote host, the reply packets will be sent back to the remote host whose address you spoofed and not to you. You will never see the reply. Ip spoofing cannot hide your ip address when performing ping sweeps or port scans because you simply will not get the replies and that would in all sense defeat the purpose of a port scan or ping sweep.

How then do we hide our source ip when performing these dastardly deeds?

Nmap Decoys

The nmap decoy is available via the –D option. This option will allow you to insert the ip addresses of multiple hosts.

e.g D:> nmap –sS –D 1.1.1.1,2.2.2.2,3.3.3.3 10.10.10.10

Look at the first section... I have specified three decoy addresses : 1.1.1.1, 2.2.2.2 and 3.3.3.3

The decoy addresses do not have to be valid ip addresses but it would defeat the purpose if they weren’t. I’ll explain this later.

Fire it off and nmap will begin port scanning the host 10.10.10.10 using a TCP SYN scan. A brief look at captured traffic off my sniffer and you’ll realize that for every port scanned, nmap is sending out four packets each from a different source address.

1.1.1.1.34054 > 10.230.100.180.5: S 336535879:336535879(0) win 3072
10.230.100.201.34054 > 10.230.100.180.5: S 336535879:336535879(0) win 3072
2.2.2.2.34054 > 10.230.100.180.5: S 336535879:336535879(0) win 3072
3.3.3.3.34054 > 10.230.100.180.5: S 336535879:336535879(0) win 3072

The trace above is the result of my decoy scan. Four TCP SYN packets are sent out to the same port on the Linux host (port 5). The first packet with a spoofed ip of the first specified decoy 1.1.1.1. The next packet is that of my real ip address and the rest of the decoy addresses follow.

Each of the four packets contains one of the following as a source address :

1) 1.1.1.1
2) 2.2.2.2
3) 3.3.3.3
4) your real ip address

What is the point you may ask? Drum roll please…to hide your real ip address in a mass of foreign ip addresses making it more difficult to detect the real attacker.

You can always add as many ip addresses as you want to fill up the logs with even more garbage but bear in mind though that the more decoys you insert, the longer nmap will take to complete the scanning process. Instead of sending x amount of packets, nmap is generating 4x more in this case so be patient.

I mentioned earlier that it would defeat the purpose if these ip addresses were not valid. My example above consists of invalid ip addresses. If you find your logs filled up with port scans from four different source ip’s and three of them being invalid, could you not detect the attacking ip as fast as I can say Jack Rabbit ? Of course you could. What does this teach ya? Use valid ip addresses as a decoy.

Assuming valid ip addresses were specified as decoys, what about the replies? Remember that for every SYN packet sent, an open port will reply with a SYN ACK packet. This packet will be sent out for every SYN packet. Therefore your decoy addresses will be receiving either RESET, ICMP Port Unreachable if the port is closed and SYN ACK packets if the port is open. To the decoys, the source addresses of these packets will be that of your target and not your real attacking ip.

Here is the trace of the reply packets sent as a result of the decoy TCP SYN scan.

10.230.100.180.5 > 1.1.1.1.34054: R 0:0(0) ack 336535880 win 0 (DF)
10.230.100.180.5 > 10.230.100.201.34054: R 0:0(0) ack 336535880 win 0 (DF)
10.230.100.180.5 > 2.2.2.2.34054: R 0:0(0) ack 336535880 win 0 (DF)
10.230.100.180.5 > 3.3.3.3.34054: R 0:0(0) ack 336535880 win 0 (DF)

The Linux host is sending RESET packets to all the decoys including the scanning machine.

If the system admins of these decoys are diligent enough or looking desperately for a pay raise, they may follow up on these strange packets and report the offending ip.

Didn’t I just say that the source ip would be that of your target and not your attacking machine. Ah well – thus my next point. When specifying decoys, it is best to specify the ip address of the decoy rather than the host name, If the host name is specified, your real ip will show up on the DNS Server of the decoy when the host name is being resolved to the ip address.

Mr. nosy system admin would go through the logs of his DNS server and obtain your ip address from there.

Randomizing Scans

Port scanning is a very noisy process and the trigger of any sys admins panic attack. We’re being port scanned – heewllp!

How do we reduce all this noise? Unfortunately patience is indeed a virtue even for hackers. Nmap has a couple of timing options that controls the intervals between each packet sent. This way, the scans will be lost in all the other legitimate traffic and not as easily detected.

Here are the timing options to be appended after the –T option :

1. Paranoid – one packet sent every 5 minutes (oh gawd – is it the 30th century yet?)
2. Sneaky – one packet sent every 15 seconds (aah much better!)
3. Polite – one packet sent every 0.4 seconds
4. Normal – as quickly as possible
5. Aggressive – waits 1.25 seconds for a response
6. Insane – waits 0.3 seconds for a response

Aggressive and Insane will likely lose traffic resulting in missed open ports, so beware. To reduce scanning noise, select any option from 1-3. If you are the patient type then Paranoid would be good. Unfortunately I am everything but patient. Let’s just do a little sniff.

14:56:03.183074 IP 10.230.100.201.41433 > 10.230.100.180.24: S 1567124470:1567124470(0) win 3072
14:56:03.190951 IP 10.230.100.180.24 > 10.230.100.201.41433: R 0:0(0) ack 1567124471 win 0 (DF)
14:56:18.200542 IP 10.230.100.201.41433 > 10.230.100.180.20: S 1567124470:1567124470(0) win 3072
14:56:18.201568 IP 10.230.100.180.20 > 10.230.100.201.41433: R 0:0(0) ack 1567124471 win 0 (DF)
14:56:33.202345 IP 10.230.100.201.41433 > 10.230.100.180.15: S 1567124470:1567124470(0) win 3072
14:56:33.203360 IP 10.230.100.180.15 > 10.230.100.201.41433: R 0:0(0) ack 1567124471 win 0 (DF)

What’s happening here? The first SYN packet is sent at 14:56:03 to port 24 of the Linux host. The RESET packet returns almost instantly. The next SYN packet is then sent at 14:56:18 to port 20 of the Linux host. In a nutshell, nmap sends out a packet every 15 seconds when the Sneaky option is used. This is the command that I used :

Nmap –sS –p 1-30 –T Sneaky 10.230.100.180

Phew! Now that I’ve taken you through the steps toward stealthdom – enjoy your scans and save the whales.

That all folks! I will be back with yet another article soon if time permits. Drop me a line with queries and kindly redirect all flames to /dev/null. Thank you. I can be reached at Whistler@hackinthebox.org.

Reference Material

Just some material that would be good reading to understand the fundamentals of TCP/IP

TCP/IP Illustrated Vol. I – Richard Stevens – in my opinion the best!

TCP Primer – Heather Osterloh

1.) A Guide To A New Generation of Phreaking - Part 1 - decimalz
2.) MBSA: Microsoft Baseline Security Analyzer - adrenaline
3.) Scanning Networks - Krishna
4.) Mutual Trust Networks: Rise of a Society - Ruchir Jha
5.) Review of Yellow Dog Linux 3.0 - L33tdawg
6.) Camouflaging Nmap Scans - Whistler
7.) When your server ends up a Warez site - Obscure