02.08.2007
Nmap Spoofing, Real Deal or Just a Nonsense

 - Carbonwind.net and the author do not condone or approve the illegal use of this tutorial in any way.
 - We must not scan hosts that do not belong to us. If you are a network admin and you want to scan the network you administrate you must first get written permission to do so.

A pretty interesting topic is how to use Nmap for spoofing.
If we spoof a remote host obvioulsy we are not going to get any results.
But what if we spoof a local host ?
Imagine that we have a firewall connecting us to the Internet. This firewall has an internal interface. Behind it are located multiple devices connected through a switch. The network administrator wants to filter the traffic and thus creates some filters. Let’s say that only computer X is allowed to pass DNS traffic through the firewall. The admin achieved this using IP and/or MAC address “authentication”. Also he applies the same principle for the firewall in order to dictate who’s able to access its admin interface(obvioulsy this admin interface needs a password).
An atacker(which can be an internal user) will be interested to map our network in order to see who’s accessing what. Nmap can serve as a tool to demonstrate what an atacker will find out.
Let’s see nmap’s options first:
The “–S” parameter can be used to specify the IP address that nmap will use as the source address. It can be our real IP address or we can spoof the IP address with one that we might need.
However in order to get some results when adding this parameter some conditions must be accomplished. If we use as the spoofed address a remote IP address we won’t get any results because of the simple reason that this IP address lies at another location an thus if there are any responses, for example for our –sS scan, these responses will be sent to the remote location of the spoofed IP address(unless depending on how “remote” is this host, we “fix” this issue). That’s why we need the idle scan using a zombie(for this to function further requirements need to be accomplished).
The “--spoof-mac” can be used to specify the MAC address that nmap will use as the source address.
The “-e” is needed to specify the interface nmap will use.
Here in our lab, we are on the same Ethernet broadcast domain with the spoofed IP address. We can have two different situations: the target(the destination IP address, not the spoofed IP address which is the source address) lies with us on the same ethernet broadcast domain or the target is a remote IP address that does not lies in the same ethernet broadcast domain.
Depending on what we scan and spoof, many devices might be involved into the equation, making the hunt for results more tricky. Obviously the first device to trick is the switch.
The switch(Layer 2 Switch), maintains a table of  MAC addresses and associated ports . Once a frame will come on one port, the switch, by analyzing the source MAC address, will create an entry or update it(if that entry already exists) in its table, entry composed from that port associated with that MAC address. In this way the switch will know that the host with that MAC address is located on that specific port and will forward traffic destined to that host only on that port.
Ethernet devices(like PCs), hold ARP tables, which are populated with IP addresses and associated MAC addresses so that they can communicate with other hosts located on the same subnet. This table is tipically build using ARP Requests and ARP Replies. When a host X wants to communicate with host Y located on the same subnet it issues an ARP Request. When this ARP Request reaches the switch the switch will forward it on all ports except on the one it has receveid it because the destination MAC address in this frame is a broadcast address. All hosts connected to the switch will see it but only host Y will reply to it. After these both host X and Y have updated theirs ARP tables and also the switch has done this with its MAC table.
With all these in mind let’s see what will happen.

 1. The target lies on the same ethernet broadcast domain
In the first case where the target lies on the same ethernet broadcast domain(alright no firewall here) when running an –sS scan, nmap will always issue an ARP Request for the target IP address, in this way creating on the switch a wrong entry(if the entry is dynamic) because in this ARP Request the spoofed IP address is asociated with our MAC address.
This is also the moment when an Windows alert appears on the host( and our MAC address will be logged, if it is running an Windows OS) to which the spoofed IP address belongs because there is only one IP address bind to two different MAC addresses and since this ARP Request has as its destination a broadcast address the spoofed host will see it(if we monitor the traffic on it we will only see the ARP Request which was sent to a MAC broadcast address because the respond packets generated by our scan will be directed to our machine by the wrong entry in the switch table and by the wrong entry in the target’s ARP table).

As just said this ARP Request will also create a wrong entry onto the target’s ARP table associating the spoofed address with our MAC address(this can prevent the target to communicate with the spoofed host until the ARP entry expires or the spoofed host issue an ARP Request for our target). To be noted that nmap will not sent the RST segment if the port is open when the target replies causing the existance of an half open connection.
If we replace our MAC address contained in this ARP request with the real MAC of the spoofed host(with --spoof-mac), then once again on the switch the wrong entry is created(by adding the spoofed MAC address to the port to which our host is connected) but that alert does not appear anymore on that spoofed host and on the target a correct ARP table entry will be created or updated. A RST segment will not be sent.

2. The target is a remote IP address that does not lay in the same ethernet broadcast domain
When the target is a remote IP address that does not lay in the same ethernet broadcast domain map’s –sS scan will issue some ARP requests if our host does not have the gateway’s MAC address or the local DNS server’s MAC address(in case the target’s name needs to be resolved because it is a FQDN (obviously we should not scan hosts that do not belong to us) and nmap does not know the IP address in order to contact the host even if we use “–n” it will still need to resolve this host thus it will contact the local DNS server) in its table. If our host does not know either the gateway’s or the local DNS’s MAC address it will issue two ARP Requests. First ARP Request will be for our DNS server from the correct MAC and IP addresses. The second will be for the gateway address with the wrong IP address. We can spoof or not our MAC address.
If the DNS server is not local, then the first ARP Request will be for our gateway from the correct MAC and IP addresses. After that the host name will be resolved, then nmap might issue for the gateway an ARP request, this time with the spoofed IP address. We can spoof or not our MAC address.
The big difference here is that the gateway(might be the default gateway) needed in order for the remote address to be reached is involved. This gateway also maintains an ARP table.
So if our host knows the gateway’s/local DNS’s MAC address no ARP requests will be issued for them.
If we do not spoof the correct MAC address too then the Windows Alert will appear on the spoofed host(in case of an ARP request). But we will get the results. Then the gateway will forward the frame with the incorrect destination MAC address so the frame will reach the switch which, based on the incorrect MAC table, will forward the frame. Obviously this port will be the port to which our machine is connected. No RST segment this time.
 If we spoof the MAC address the switch will learn from our frame that the spoofed MAC address lies on the port to which our machine is connected. So the switch will forward the reply on our port. On the gateway a correct entry is created. Nmap will get results. No RST segment this time.

If no ARP Requests, then the problem is that the gateway might not know the spoofed host MAC address. So it will issue an ARP Request. Correct entry in its table and on the switch and possible no reply to us. If we spoofed the correct MAC address then it is possible to get results based on the delay from the first SYN sent by nmap and the second one(because it has not received an answe.r nmap's -sS will issue two SYN segments).
As you can see there are some variations when performing this type of scan. We will not going to detail any further(with printscreens…) what nmap does. It was just a “brief” explanation.  Results might differ because the ARP entries expire or the spoofed host start passing traffic through the switch and gateway.

The point is that we can get results, as Nmap itself says:

"Use -sS or another raw scan if you want to completely spoof your source address, but then you need to know what you're doing to obtain meaningful results."
To see it yourself use Wireshark. I have used Nmap v4.20 for this article.

 3. Nmap Quick Notes:

 –sT means that nmap will complete the three-way handshake and then it will send a packet with the Reset flag set to kill the connection. You can choose it if you want to see the completion of the three-way handshake. In this case ports can came as open, closed and filtered(same for –sS “SYN scan”). Not working with -S, only if you use one of your IP addresses.

 –sS means that nmap will not complete the three-way handshake. It will issue a SYN and in case of the receiving an SYN|ACK it sends back a RST segment.
 –P0 for nmap means no ping(no echo request threat all host as online) . When we are on the same network as our target, nmap will “ARP ping” it instead of issuing an echo request. In the case of –sT it will not issue an ARP request unless our host does not have the MAC address of the target in its table(nmap will always issue the “ARP ping” for a –sS no matter if you specify –P0 or not).
 –n means don’t resolve the specified name or IP address.

 Pay attention to the fact that we can scan for open ports and for closed ports. For closed ones we can use: –sN(TCP Null scan, no flag set), –sF(TCP FIN scan, FIN flag set), –sX(TCP Xmas scan, FIN, PSH and URG flags set), which according to RFC793 in case of a closed port when sending to it segments which do not contain any of the SYN, RST or ACK flags set this port will reply with a Reset segment(if the port is open these segments will simple be discarded). Also the –sM scan(Maimon scan) will send a packet with FIN/ACK flags set which according to the same RFC793 will cause either an open or closed port to send a Reset segment:

"Briefly the meanings of the states are:
LISTEN - represents waiting for a connection request from
any remote TCP and port.
CLOSED - represents no connection state at all(CLOSED is
fictional because it represents the state when there is no TCB,
and therefore, no connection.
SEGMENT ARRIVES:
If the state is CLOSED:
An incoming segment not containing a RST   causes a RSTtobesentinresponse.IftheACKbitison: <SEQ=SEG.ACK><CTL=RST>
If the state is LISTEN:
second check for an ACK. Any acknowledgment is  bad if it arrives
on a connection still in the LISTEN state.  An acceptable reset
segment should be formed for any arriving ACKbearingsegment. 
The RST shouldbe formattedasfollows:<SEQ=SEG.ACK><CTL=RST>
fourth other text or control:
Any other control or text-bearing segment (not containing SYN)
must have an ACK and thus would be discarded by the ACK processing.
An incoming RST segment could not be valid, since it could not have
been sent in response to anything sent by this incarnation of the connection. 
So you are unlikely to get here,but if you do, drop the segment, and return."

So if we want to remain stealth we can scan a port with –sM which in the case of an open/closed port will caused a RST segment to be sent. If so then use either –sN,  –sF  or –sX and if no response is generated the port is open. If a RST segment is received then the port is closed. For this technique to function the target system must play by the rules. In reality this is not the case for many OSs. Also if there is a stateful firewall along the way this kind of packets will be dropped with no responses because they are not part of any established connection and they are not SYN packets needed for starting a connection. Since we are using Windows in our lab it is good to know that Windows will simple respond with a RST segment to such scans(its default behaviour) so we cannot know if the port is open or closed, only that the host is there(exists, actually its existence cannot be trully defined after only these scans rather only the fact that “something” responded to our packets). Normally only a poor “firewall”(if we can call it like so these days will forward or generate some responses to these packets). If for example we have enabled the Windows Firewall on the target will be enough to further mess the results. Only open ports will respond to our –sN,  –sF ,–sX or –SM samples with a RST segment. So if we scan the target in this case and TCP port 445 will come up as closed then in reality will be opened. The term “stealth” is also a nonsense because a real IDS will easily detect these scans(for example Snort). Please read Nmap’s Help for more details. It can be easy concluded that sometimes not being “RFC compliant” has its advantages. As we have seen Windows is somewhat “RFC compliant” since it sends the necessary RST segment except that it is doing so “more often” but in reality this has no impact or compatibility problem because segments of these kind are just trash and now any modern and real firewall its dropping them without any reply(they are exploiting in a delicate way a subtle hole in RFC793).