Sniffing network traffic

Packet sniffing is one of the best ways to understand a network. It may look a bit antiquated to have a terminal window streaming text as packets are read by the NIC, but it is the basis of all network analysis. We show several sniffers, which you can use to steal cleartext passwords, map the IP addresses of all the responding machines, and collect NTLM packets with usernames and password hashes.

Basic sniffing with tcpdump

Tcpdump is a simple command-line sniffing tool found on most routers, firewalls, and Linux/UNIX systems. There is also a version that runs on Windows made by microOLAP, which can be found at http://www.microolap.com/products/network/tcpdump/. It's not free but there is a trial version. The nice thing about this version is it is one simple executable which can be uploaded to a system and used without installing extra drivers. It can be launched on a cracked system to which you have shell access. Your shell must have SYSTEM or Administrator level access to work because NICs will not run in the promiscuous mode without administrative privileges. Another packet dump tool is Windump.exe, available from http://www.winpcap.org/windump/install/, where you will also find WinPcap.exe, which you need on the machine to run tcpdump or windump.

On Linux/Unix systems and routers like Cisco or Juniper, it is likely to be installed by default. If you cannot find it on a Linux system, it is in every distribution repository.

Tcpdump's best use is not collecting data for real-time inspection, but capturing data to a file for later viewing with a tool like Wireshark. Because of its small size, portability, and use from the command line, tcpdump is great for this task.

Below, we see tcpdump running without saving to a file. Please note that we can see the packets as they pass through the interface.

The command we are running is:

tcpdump -v -i vmnet1

The -v puts the application into verbose mode. The -i vmnet1 tells the application to only capture the packets on the vmnet1 interface. By hitting the Enter key, tcpdump will start capturing packets and display them on the screen. To stop the capture, hit Ctrl + C.

Now, in this mode, the data is going to pass too quickly for any real use, especially on a large network, so next we will save the data to a file so we can view it at our leisure and with better viewing tools:

Now we will run the following command and pipe the output to a .pcap file. Note that there isn't the output to the screen that you saw earlier. The data is going to the file now and not the screen. Run the following command:

tcpdump -v -i vmnet1 -w kalibook-cap-20150411.pcap

Note we are adding -w kalibook-cap-20150411.pcap to the command. The flag -w tells the application to write out to the file named kalibook-cap-20150411.pcap. The file should have a descriptive name, and I am also including the date in the filename. If you do this kind of testing from time to time and don't delete the files from the system, it can be confusing, as several of these files are on the same system. .pcap is the standard file name extension used in the industry for packet files and stands for Packet Capture File. This file can be moved to another machine using file transfer methods:

Notice that this capture is done on a machine named wander. Wander is the firewall of our network, which is the best place to capture network traffic. We will now transfer it to our Kali box to inspect the packets:

First, on our Kali machine, we need to start up the SSH service. As we have mentioned before, Kali includes all the network services that you would find on any Linux server, but for reasons of security, all services are turned off by default and must be started manually for use. We'll fire up SSH with the following command:

service ssh start

We can see the SSH service start, and by running the netstat -tl command we can see we have the SSH service listening on all interfaces. We are now going to transfer the files from the firewall to Kali.

On the Kali command line, run the following command:

ifconfig

This will show you your IP address:

Now, from the firewall, transfer the file to Kali by running the following:

scp kalibook-cap-20150411.pcap root@192.168.202.129:kalibook/kalibook-cap-20150411.pcap

Accept the key warning by typing yes and then entering the root password when prompted.

Tip

Note:

Here, we tried to send it to the wrong directory. There isn't a directory named workspace. If you see this type of error this is most likely the reason. Notice we have moved this file directly to the project directory on the Kali box.

When you are done, don't forget to turn SSH off.

service ssh stop

So, this is good for systems with ssh built in, but what about Windows? SSH clients are thin on the ground in Windows-land. Most people seem to use putty.exe, but your cracked server system is unlikely to have putty installed. We'll fall back to good old FTP. Most Windows systems come with the FTP command-line utility. Sometimes the security-conscious sysadmin removes ftp.exe from the machine and this blocks this type of file transfer. Normally, it's there for your use. If it is not there, go to http://www.coreftp.com/ and download the Core FTP. They have a free version that would work for this application, and you can also get a paid license for more features.

We are now going to transfer the tcpdump utility to our cracked Windows machine to capture some packets.

First, we will need to set up the FTP service on Kali to transfer back and forth to. We will use our friend Metasploit for this. Metasploit has an easy to use FTP service for this purpose. We will need a folder to work from:

Open the computer on the Desktop on the Kali box.
Click on the Home link in the left-hand list.
Right click in the folders area and pick Create new folder.
Name it public, then right-click on the folder and go to Properties.
Click on the Permissions tab, give both the Group and Others read/write access and the ability to create and delete files, as seen as following:

Now copy the NDIS driver and tcpdump.exe to the public folder. You will want to rename the tcpdump file in case of anti-virus and/or IDS/IPS systems that might be in use on the target network. I have changed the name to tdpdump.jpg. The microolap_pssdk6_driver_for_ndis6_x86_v6.1.0.6363.msi driver file will normally pass OK. (These files are in the tools folder connected to the chapter.)

Now fire up Metasploit on the Kali box by going to Applications | Kali Linux | System Services | community/pro start to start the service. Once the service has started, open a Terminal window and type:

msfpro

Metasploit will start. Once Metasploit is running, change into your workspace for your project. My workspace is named kali-book-int-20150300:

workspace kali-book-int-20150300

Now we will configure the FTP server and fire it up. To load the FTP server, type the following.

use auxiliary/server/ftp
show options

You will see the configuration options.

We need to change the FTPROOT setting type:

set FTPROOT /root/public
show options

By running the show options command again, we can check our configuration. We're ready to go. Type the following command:

run

You'll see the output as the following:

You can see the service by running:

netstat-tl

Now let's copy over our files to our pwned Windows machine and capture some tasty packets! We will be using WinDump for this process on Windows.

More basic sniffing with WinDump (Windows tcpdump)

WinDump is the tcpdump for Windows. It is open source and under the BSD license. You can download it at http://www.winpcap.org/windump/.

You will also need the WinPcap drivers, so be sure to get them from the site also.

WinDump will work from a command line, Power Shell, or a remote shell. Like tcpdump, it will write to a file which you can download for offline viewing.

Now let's copy the files over to our pwned Windows machine. From either a command line, Power Shell, or from an exploited remote shell, log in to the FTP server on Kali. My Kali box is at 192.168.202.129:

ftp 192.168.202.129

The system will ask for a user name; just hit Enter. It will also ask for a password, so just hit Enter again and you'll be logged on. Then, type:

dir

This will show the contents of the directory:

More basic sniffing with WinDump (Windows tcpdump)

As seen above, we see our WinPcap driver and our undisguised WinDump.exe. To download them, just type:

get WinPcap_4_1_3.exe

Then

get WinDump.exe

We've got our files, so now log out:

quit

As we can see in the preceding screenshot, we now have our files locally by typing:

dir

We can also see the files being transferred on Kali from the running instance in Metasploit:

Now log into your pwned Windows machine either through RDP or start a VNC session from Metasploit. From the Desktop, go to the folder where you downloaded your files and double-click the WinPcap.exe file, as seen below:

Next you'll get the licenses windows, click I Agree button and move on:

The next screen starts the actual installation of the driver. Be sure to keep the check box checked to run automatically. This will be a big help later if you have to go back:

With this done, you are ready to capture some packets.

Fire up either a command-line window or Power Shell and go to the directory where you have WinDump. Here, we have it in the Downloads folder. Run the following.

.\WinDump.exe

Soon you will start seeing packets pass through the interface. How much you see on your screen depends on how much your system is talking to the network. You can tell if there is way too much data to try to understand in real-time. Also, in this mode, you are only seeing the header information of the packet and not the complete packet and its information. Below, you will see marked in yellow the running of the command, and marked in green that it is listening on the running interface. After that, you see the packets coming in.

Now let's dump our capture to a file so we can really see what we have by running the following:

.\WinDump.exe -w Win7-dump-20150411.pcap

The -w file tells WinDump to write to the file, Win7-dump-20150411.pcap. As you can see below, running WinDump with the -h flag will give you a short help if you ever forget the write flag. After running for a bit, hit Ctrl + C to stop the capture. You can now see we have a file containing our captured packets.

After the capture, we need to send the file back to Kali to analyze the packets.

Windows file sharing works for this. If Printer and File Sharing aren't turned on, enable it to share the files and return back to your Kali box.

Tip

Hacker Tip

This process may cause an alert if the network administrators have something like Tripwire running to check for configuration changes, or have ArcSight set up to alert logged actions by administrative users.

Kali has SMB file sharing and NetBIOS discovery built right into its file manager. Click on the Computer icon on your desktop and then click Browse Networks; you will see an icon for Windows Networks as seen below:

By clicking the Windows Networks, Kali will discover any Workgroups or Domains on the local network. As seen below, we see our local workgroup, IVEBEENHAD; click on it and you will see the computers on the network:

Next, click on the victim computer and log in with the Administrator account associated with the workgroup or domain you have the credentials for, and you will now see the shared directories on the system. Drill down into the folders and go to the directory where the packet capture is. For us it will be Users | Administrator | Downloads:

Now that we have gotten to where the file is, click on the Computer icon again and open up another File Manager window and go to your evidence directory for your project. Then, just drag and drop the file onto Kali's drive:

Now we're ready to read some captured packets.

Packet hunting with Wireshark

Wireshark is the industry defacto standard for packet sniffing and analyzing network packets. Not only does it work for TCP/IP but just about every other known protocol and standard. There are versions of Wireshark for every well-known operating system. You will need the WinPcap drivers from earlier in the chapter to run Wireshark on Windows. On Linux/Unix and OSX, the drivers are generally already there. Wireshark comes preloaded on Kali.

Wireshark is an extremely complex application. There have been many books written on its use. I do suggest getting one and learning the in-depth use of this tool. We will only cover the basics here.

What is the Internet if you really think about it? Some people point to their web browser and say there is the Internet. A SysAdmin might give you a long answer about servers and devices transmitting data across a network. Everyone is right in their answer but still really miss exactly what it is. The Internet is packets. Without the packet, the information goes nowhere. Most don't realize that TCP/IP are two different protocol suites which work independently of each other. There is IP and then there is TCP and UDP which run on top of IP. All of this then runs on top of Internet Frames.

We'll get back to Wireshark in a minute. First, we need to understand a packet.

Dissecting the packet

Let's have a look at a packet. Below is just one packet of information pulled from a captured data stream. Please remember that this is just one packet!

Oh, a little history here! If you look at the structure of the packet and look at the structure of an old telegraph message, you will notice the structure is the same. Yes, a packet is basically a telegram. Also remember, Morse code is basically a 4 bit binary language.

Note that first we have the frame. The frame contains basic information about the packet. You can see the bytes on the wire and that it was captured by Wireshark. This also keeps the timing of the packets, and this is used in the reassembly of the packets when received:

Frame 9: 188 bytes on wire (1504 bits), 188 bytes captured (1504 bits)
    Encapsulation type: Ethernet (1)
    Arrival Time: Apr 12, 2015 01:43:27.374355000 EDT
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1428817407.374355000 seconds
    [Time delta from previous captured frame: 0.002915000 seconds]
    [Time delta from previous displayed frame: 0.002915000 seconds]
    [Time since reference or first frame: 9.430852000 seconds]
    Frame Number: 9
    Frame Length: 188 bytes (1504 bits)
    Capture Length: 188 bytes (1504 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:ip:tcp:nbss:smb]
    [Coloring Rule Name: SMB]
    [Coloring Rule String: smb || nbss || nbns || nbipx || ipxsap || netbios]

Next, we have the IP section of your packet. We see that this contains the MAC addresses of the source and destination interfaces. Your MAC address is your real machine address. The IP part of the stack does the routing so that the two MAC addresses can find each other.

Ethernet II, Src: Vmware_07:7e:d8 (00:0c:29:07:7e:d8), Dst: Vmware_45:85:dc (00:0c:29:45:85:dc)
    Destination: Vmware_45:85:dc (00:0c:29:45:85:dc)
        Address: Vmware_45:85:dc (00:0c:29:45:85:dc)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Source: Vmware_07:7e:d8 (00:0c:29:07:7e:d8)
        Address: Vmware_07:7e:d8 (00:0c:29:07:7e:d8)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Type: IP (0x0800)
Internet Protocol Version 4, Src: 192.168.202.130 (192.168.202.130), Dst: 192.168.202.128 (192.168.202.128)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
    Total Length: 174
    Identification: 0x033f (831)
    Flags: 0x02 (Don't Fragment)
    Fragment offset: 0
    Time to live: 128
    Protocol: TCP (6)
    Header checksum: 0xe0b6 [correct]
        [Good: True]
        [Bad: False]
    Source: 192.168.202.130 (192.168.202.130)
    Destination: 192.168.202.128 (192.168.202.128)
    [Source GeoIP: Unknown]
    [Destination GeoIP: Unknown]

The next section of the packet is where TCP comes in and sets the type of TCP or UDP protocol to be used and the assigned source and destination ports for the transmission of the packet. This packet is being sent from a client machine (the source). From the above IP section, we see that the client IP address is 192.168.202.130. Below, we see the client's port of 49161. This packet is being sent to 192.168.202.128 (the destination) at port 445. This being TCP, a return route is included for returned traffic. We can tell just by the destination port information that this is some type of SMB traffic:

Transmission Control Protocol, Src Port: 49161 (49161), Dst Port: microsoft-ds (445), Seq: 101, Ack: 61, Len: 134
    Source port: 49161 (49161)
    Destination port: microsoft-ds (445)
    [Stream index: 0]
    Sequence number: 101    (relative sequence number)
    [Next sequence number: 235    (relative sequence number)]
    Acknowledgment number: 61    (relative ack number)
    Header length: 20 bytes
    Flags: 0x018 (PSH, ACK)
        000. .... .... = Reserved: Not set
        ...0 .... .... = Nonce: Not set
        .... 0... .... = Congestion Window Reduced (CWR): Not set
        .... .0.. .... = ECN-Echo: Not set
        .... ..0. .... = Urgent: Not set
        .... ...1 .... = Acknowledgment: Set
        .... .... 1... = Push: Set
        .... .... .0.. = Reset: Not set
        .... .... ..0. = Syn: Not set
        .... .... ...0 = Fin: Not set

In packet information like above, 0 is No and 1 is Yes.

    Window size value: 63725
    [Calculated window size: 63725]
    [Window size scaling factor: -1 (unknown)]
    Checksum: 0xf5d8 [validation disabled]
    [SEQ/ACK analysis]
        [This is an ACK to the segment in frame: 8]
        [The RTT to ACK the segment was: 0.002915000 seconds]
        [Bytes in flight: 134]

Below, we see that this is a NetBIOS session using the SMB protocol:

NetBIOS Session Service
    Message Type: Session message (0x00)
    Length: 130
SMB (Server Message Block Protocol)
    SMB Header
        Server Component: SMB
        [Response in: 10]
        SMB Command: NT Create AndX (0xa2)
        NT Status: STATUS_SUCCESS (0x00000000)
        Flags: 0x18
        Flags2: 0xc807
        Process ID High: 0
        Signature: 0000000000000000
        Reserved: 0000
        Tree ID: 2049
        Process ID: 2108
        User ID: 2048
        Multiplex ID: 689
    NT Create AndX Request (0xa2)
        [FID: 0x4007]
        Word Count (WCT): 24
        AndXCommand: No further commands (0xff)
        Reserved: 00
        AndXOffset: 57054
        Reserved: 00
        File Name Len: 44
        Create Flags: 0x00000016
        Root FID: 0x00000000

Below, we have been granted access to the data we are requesting. We can now see that this packet is involved with accessing a file. The user who has done this request has the below permissions to view the file requested. We can see from above that a successful status was given for the file request:

        Access Mask: 0x00020089
            0... .... .... .... .... .... .... .... = Generic Read: Generic read is NOT set
            .0.. .... .... .... .... .... .... .... = Generic Write: Generic write is NOT set
            ..0. .... .... .... .... .... .... .... = Generic 
            Execute: Generic execute is NOT set
            ...0 .... .... .... .... .... .... .... = Generic All: Generic all is NOT set
            .... ..0. .... .... .... .... .... .... = Maximum Allowed: Maximum allowed is NOT set
            .... ...0 .... .... .... .... .... .... = System Security: System security is NOT set
            .... .... ...0 .... .... .... .... .... = Synchronize: 
            Can NOT wait on handle to synchronize on completion of 
            I/O
            .... .... .... 0... .... .... .... .... = Write Owner: 
            Can NOT write owner (take ownership)
            .... .... .... .0.. .... .... .... .... = Write DAC: Owner may NOT write to the DAC
            .... .... .... ..1. .... .... .... .... = Read Control: READ ACCESS to owner, group and ACL of the SID
            .... .... .... ...0 .... .... .... .... = Delete: NO delete access
            .... .... .... .... .... ...0 .... .... = Write Attributes: NO write attributes access
            .... .... .... .... .... .... 1... .... = Read Attributes: READ ATTRIBUTES access
            .... .... .... .... .... .... .0.. .... = Delete Child: NO delete child access
            .... .... .... .... .... .... ..0. .... = Execute: NO execute access
            .... .... .... .... .... .... ...0 .... = Write EA: NO write extended attributes access
            .... .... .... .... .... .... .... 1... = Read EA: READ EXTENDED ATTRIBUTES access
            .... .... .... .... .... .... .... .0.. = Append: NO append access
            .... .... .... .... .... .... .... ..0. = Write: NO write access
            .... .... .... .... .... .... .... ...1 = Read: READ access
        Allocation Size: 0
        File Attributes: 0x00000000
        Share Access: 0x00000007 SHARE_DELETE SHARE_WRITE SHARE_READ
        Disposition: Open (if file exists open it, else fail) (1)
        Create Options: 0x00000044
        Impersonation: Impersonation (2)
        Security Flags: 0x03
        Byte Count (BCC): 47
        File Name: \My Videos\desktop.ini

All the above lines are to let one computer know that on another computer there exists a file named \My Videos\desktop.ini. 47 bytes of information was sent. Now, this wasn't the actual file but just a listing of the file. Basically, this would be the packet that makes a file icon appear in your window manager. It sure takes a lot to send just a little bit of data:

No.     Time        Source                Destination           Protocol Length Info
     10 9.431187    192.168.202.128       192.168.202.130       SMB      193    NT Create AndX Response, FID: 0x4007

Now that we know a bit about packets, let's get back to Wireshark!