Laura Chappells Trace File Library

No.
00029

Name
137port.pcap

Description
It looks like NetBIOS It feels like NetBIOS but it doesn't smell like NetBIOS. Something just feels wrong. Follow TCP Stream on this communication to find out what it really is. Consider using protocol forcing (right-mouse click, Decode As) to make port 137 traffic get decoded as FTP. It's a cat fight! Watch the change of direction in the scan process when one aggressive honeypot gets scanned by another aggressive honeypot. Consider making an IO Graph with two filters: black line: ip.src==24.6.137.85 && tcp.flags == 0x02; red line: ip.src==24.6.138.50 && tcp.flags == 0x02. You may need to adjust the X axis tick interval. Turn on the green graph line without any filter applied. This scan was performed by LANguard Network Security Scanner. Look for the illegal ICMP Echo request packet (Type 8; Code 19) which is the signature for LNSS.

00003

2-specters-fighting.pcap

00005

active-scan.pcap

00163

aida32-connection.pcap

Even though Wireshark doesn't recognize this application, a quick examination of the data being exchanged reveals that this is AIDA32 traffic. If Wireshark doesn't have a dissector for your traffic, examine the payload to look for the name or look up the port on www.iana.org.

Copyright 2008 Protocol Analysis Institute, Inc.

Page 1

Laura Chappells Trace File Library

00048 anotherlousyhotelnetwork.pca p This trace begins with a really slow DNS response. In fact, the client sends out two DNS queries. When the first DNS repsonse arrives, the client shuts down the listening port and responds to the second DNS respons with an ICMP Destination Unreachable/Port Unreachable. How much delay was caused by packet loss? ARP packets are minimum-sized packets and must be padded to meet the minimum 64-byte length for this Ethernet network. When we look at the padding on these packets, we see something frightening there's data in the padding! This is a security flaw that surfaced back around 2003. Seems the NIC driver was padding the packets with information from cache. I still see this every once in a while how long have your systems had the same NIC/driver? This is a classic client bootup sequence beginning with the DHCP Request/ACK sequence (indicating the client is still within its lease time) and moving on to the gratuitous ARP process before sending out an ARP to the default gateway defined in the DHCP ACK [P2]. This isn't a fast process however. Users typically accept sluggish boot processes, but not slow login sequences. This trace shows the startup sequence for using a newly-assigned IP address. What might be the cause for the delay between the Gratuitous ARP and the ARP for 10.1.0.1? Do you see recognizable ARP padding in the ICMP Echo request?

00162

arp-badpadding.pcap

00161

arp-bootup.pcap

00047

arp-ping.pcap

Copyright 2008 Protocol Analysis Institute, Inc.

Page 2

Laura Chappells Trace File Library

00021 arp-poison.pcap Consider taking out a pen and paper to sketch the communications (pay close attention to the MAC header as well as the advertised MAC address in the ARP packets). Using a combination of ARP and ICMP Echo requests, a system is poisoning and testing the poison process. Can you determine the IP address of the poisoner? This trace depicts an ARP reconnaissance process. What would explain the nonsequential target IP addresses? Can you determine the subnet mask of the transmitter by the ARP target addresses?

00087

arp-recon.pcap

00135

bittorrent-idle-crap.pcap

We let a BitTorrent client sit idle for an extended period of time (24 hours) and then decided to check in on it to see if it was talking. Look at all the outbound handshakes! And after sending SYN packets to a number of these folks the BitTorrent client performs some DNS PTR queries to resolve their names. We think we were lucky this client didn't make a connection to tracker.bittorrent.com. A BitTorrent tracker is a server that 'assists in the communication between peers.' Thanks, but no thanks. Simply launching BitTorrent causes a connection to the BitTorrent website as well as surveymonkey.com, questionmarket.com and zedo.com (billing itself as Third Generation Technology of Ad Serving). Is this really the traffic you want on the network? The query for 'madonna' took 3.5 seconds not the fastest bolt of lightening. Maybe they should talk to Google.

00134

bittorrent-launch-searchmaddona.pcap

Copyright 2008 Protocol Analysis Institute, Inc.

Page 3

Laura Chappells Trace File Library

00134 bittorrent-launch-searchmaddona.pcap Simply launching BitTorrent causes a connection to the BitTorrent website as well as surveymonkey.com, questionmarket.com and zedo.com (billing itself as Third Generation Technology of Ad Serving). Is this really the traffic you want on the network? The query for 'madonna' took 3.5 seconds not the fastest bolt of lightening. Maybe they should talk to Google. Don't you just love that BitTorrent stuff? Well, your network doesn't! This is the background traffic from starting up BitTorrent on a clean system. Build an IO graph to see the packets/second and bytes/second rate. You couldn't pay me to put that junk on my network! What a bunch of crap! <IMHO> We aren't seeing the beginning of the Blaster connection in this trace (no SYN/SYN ACK/ACK sequence), but we can assume the connection was established successfully. Follow TCP Stream to learn what commands are exchanged between the client and server processes. Blaster was easy to spot based on the payload. What would you filter on at the firewall or IPS device? Someone is attempting a brute force password crack on an FTP server (creditus.com). Apply the following filter to display all packets with the USER and PASS commands: ftp.request.command==USER || ftp.request.command==PASS.

00104

bit-torrent-startupbackground.pcap

00046

blaster.pcap

00059

bruteforce.pcap

Copyright 2008 Protocol Analysis Institute, Inc.

Page 4

Laura Chappells Trace File Library

00103 chargen.pcap I can't imagine why someone would want Character Generator (CHARGEN) services on their network. Maybe they don't know how to do connectivity tests using UDP or TCP traceroute? This trace depicts an ugly pair of devices exchanging CHARGEN traffic between them. What if one of them had selected a source port of 19? Life would get really painful really fast. I can't imagine why someone would want Character Generator (CHARGEN) services on their network. Maybe they don't know how to do connectivity tests using UDP or TCP traceroute? This trace depicts an ugly pair of devices exchanging CHARGEN traffic between them. What if one of them had selected a source port of 19? Life would get really painful really fast. A client system (172.16.1.10) is in trouble. After it boots up the CPU utilization climbs to 100% and the system locks up within 3 minutes. You can see many problems in the trace - incoming DCERPC communications and the client establishing TFTP and IRC communications to remote systems. Follow TCP Stream on the IRC communication. This client is infected with a variant of the sdbot worm. [also in .cap format] You can learn a lot from DHCP ACK packets (that are typically sent to the broadcast address)! In this trace we can find out the host name of a device as well as their bootfile names and even their TFTP server addresses!

00103

chargen.pcap

00024

clientdying.pcap

00125

dhcp-ack-info.pcap

00124

dhcp-discover-strange.pcap

Something is terribly wrong with this host we need to get it off the network a.s.a.p. Check out the Client MAC Address field in the DHCP packets. How can this be? What are your thoughts on the cause of this unusual traffic?

Copyright 2008 Protocol Analysis Institute, Inc.

Page 5

Laura Chappells Trace File Library

00178 dhcpjerktakesaddressnopermi ssion.pcap The DHCP server is down, but the client remembers its last address and decided just to take it back. Of course it does a gratuitous ARP [P3]. The client uses router solicitation (ugh) to try to find a default gateway as well. Finally, 12 seconds in to the trace the DHCP server resurfaces [P8]. You can learn a lot about the other devices on the network even if you are hanging off of a switch or you are on the other side of a router (as long as their DHCP traffic flows across your network). DHCP Offer packets sent to the broadcast address go everywhere on a switched network and contain some interesting information. Look at packet 3, for example. DHCP Discovery packets are also ripe with information. Compare the source MAC address in the Ethernet header with the Client MAC Address inside the DHCP packet to note that this communication is coming from the DHCP Relay Agent to the DHCP Server. The client sends a Requested IP Address and begins with a DHCP Request because it is still within it's lease time. The DHCP client is unsuccessful in renewing its IP address from 10.1.0.1so the client broadcasts the DHCP Request in hopes of finding a new DHCP server. When the DHCP client doesn't get an answer, it gives up its IP address and begins the process of discovery from scratch [P7]. This trace shows the two different DHCP Discover packets used to locate rogue DHCP server on the network using NetScanTools Pro. Look in the client ID field in the DHCP packet for the difference.

00123

dhcp-offer-info.pcap

00044

dhcp-relay-serverside.pcap

00043

dhcp-renewtorebind.pcap

0802

dhcp_server_discovery2_types.pcap

Copyright 2008 Protocol Analysis Institute, Inc.

Page 6

Laura Chappells Trace File Library

00122 dhcp-server-slow.pcap You know it's going to be a bad day when the first one you talk to ignores you. In this case the client sends a DHCP Discover out and waits six seconds without a reply (you could hear a pin drop). When the server does finally answer [P3] the client already has another Discover queued up and ready to send out it goes [P4]. Let's hope the rest of the day goes better. This dictionary password crack is focused on breaking into the Administrator account. Apply the following filter to display all the passwords attempted: ftp.request.command==PASS. Does this look like your typical dictionary or could it be a special word file customized for the target. This dictionary password crack is focused on breaking into the admin account on an FTP server. Apply the following filter to display all the passwords attempted: ftp.request.command==PASS. Did the cracker try using a blank password?

00058

dictionary.pcap

00057

dictionary2.pcap

00019

dns-error-domain.pcap

When a client tries unsuccessfully to get the IP address of www.us.gov, it appends its domain information to the query. This, of course, generates a response of "No Such Name." The client is configured to "Append parent suffixes of the primary domain suffix." Compare the DNS lookups required to access www.winpcap.org, www.msnbc.com and www.espn.com. Check the DNS traffic generated when you connect to your corporate servers. Consider baselining that traffic.

00160

dns-misc.pcap

Copyright 2008 Protocol Analysis Institute, Inc.

Page 7

Laura Chappells Trace File Library

00159 dns-misc2.pcap Browsing to www.cnn.com, www.microsoft.com and www.espn.com generates lots of DNS queries and responses (filtered out in this trace) as they direct you to their ad and data streaming affiliates. Many of the server names imply they are advertising sites. Our client is only looking for the Mail Exchange (MX) server for www.packetlevel.net. The response [P2] includes the name servers and their IP addresses.

00120

dns-mxlookup.pcap

00119

dns-ptr.pcap

If you see an excess number of DNS PTR queries, look at the source. Make sure it's not your Wireshark system (turn off network name resolution to squelch the DNS PTR traffic from Wireshark). Why are other devices on the network performing these DNS PTR queries - don't they know the network names of the targets? This DNS query for <Root> generates a response with the MNAME (primary master server name) value of A.ROOT.SERVERS.NET. The reply indicates that the responsible authority's mailbox is at Verisign and the receiver can only cache this information for a measly 6 minutes and 19 seconds. DNS server failures [P4] [P17] [P23-P25] don't indicate that the name was not found they indicate that the server couldn't get a positive or negative response. Perhaps the upstream DNS server didn't respond in a timely manner (or at all). Consider building a display filter for dns.flags.rcode==2 to view these DNS server failure responses.

00118

dns-root.pcap

00157

dns-serverfailure.pcap

Copyright 2008 Protocol Analysis Institute, Inc.

Page 8

Laura Chappells Trace File Library

00042 dns-slow.pcap Compare how quickly the first and second DNS response packets come to the delay before the first DNS response is sent. Is the DNS response time better later in the trace [P98]? This client can't get to a website because DNS isn't resolving properly. It's not the normal Name Error or Server Error response, however. Something strange is happening. Look at the source of the ICMP packets, the type of ICMP packets and the original DNS query packet contents spit back inside those ICMP packets. Which device would you examine first? This DNS 'walking' operation begins by looking up the SOA (Start of Zone Authority) for a domain and then the NS (name servers) for the same domain. After doing some research on the name servers, the client begins a TCP-based Zone Transfer (AXFR) [P7]. Note the number and format of replies [P14]. This DNS 'walking' operation begins by looking up the SOA (Start of Zone Authority) for a domain and then the NS (name servers) for the same domain. After doing some research on the name servers, the client begins a TCP-based Zone Transfer (AXFR) [P7]. Note the number and format of replies [P14]. The client complains that there is a problem with the Internet connection - they are trying to download the OpenOffice binary, but it is just taking too long. Use the Expert Info and Expert Info Composite to identify the problems in this trace file. What are the three primary causes for the poor performance? [also in .cap format]

00084

dns-ttl-issue.pcap

00117

dnswalk.pcap

00117

dnswalk.pcap

00083

download-bad.pcap

Copyright 2008 Protocol Analysis Institute, Inc.

Page 9

Laura Chappells Trace File Library

00139 download-bad-to-good.pcap This user tries to download the OpenOffice binary from one site, but the performance is pitiful. They cut off the download process and connect to a mirror site. The download process is much faster from the second site. Is the problem at the server? The client? The link? The file? The IO Graph tells the story high spiky mountains are preferable to long rolling hills. Separate out the two TCP data streams and pull the Expert Info for each. The users are relatively happy with the download time required to obtain the OpenOffice binary depicted in this trace file. How long did the file transfer take? What is the average bytes/second rate? . You've got to kiss a lot of frogs to find a prince! And you've got to connect to a lot of ad servers and media streaming servers to get your sports fix! When viewing this trace, look at the Statistics > HTTP > Packet Counter to see how many redirections and 404 Not Found errors the client experiences when connecting to www.espn.com. This great trace file shows someone running ettercap's 'Check for Poisoner' function. The IP ID field of these ping packets contains the signature 0xe77e (eleet-speak for 'ette' which is short for ettercap). Systems that answer back with the same IP ID value are most likely running ettercap as well. Don't get distracted by the ICMP ID value of 0xe77e responders all must echo back that value so the echo requests and replies can be associated properly.

00082

download-good.pcap

00102

espn-moved.pcap

00156

ettercapcheckforpoisoner.pcap

Copyright 2008 Protocol Analysis Institute, Inc.

Page 10

Laura Chappells Trace File Library

00144 evilprogram.pcap A truly classic trace file of a system infected with the Stopguard browser hijack spyware/malware/scumware program. It's imperative that the client not reboot, but luckily we got the trace. Create a DNS filter to see the client look up Virtumonde's website. That's when the troubles begin. Check out www.spywarewarrior.com - a great reference for spyware/adware/malware/scumware, etc. This client has a personal problem. The HTTP server sends a FIN ACK and the client ACKs back. After that the client uses the TCP backoff algorithm at it sends a series of FIN ACKs back to the server in desperate hopes the server will send a final ACK to terminate the communications. Sorry the server has moved on to other things. Something is definitely wrong here. Look inside the Destination Unreachable/Fragmentation Needed packets to locate the IP header Total Length field. Was the triggering packet too long? What is the MTU of the next hop advertised? Consider applying the following display filter on the traffic: ftp.request.command == "USER" || ftp.request.command == "PASS". This reveals all the that the password cracking attempt is only focused on the admin account and the passwords are coming from a dictionary that includes names. Looks like they are cycling through the password list we caught them on the letter M, but they start at the beginning later [P4739]. [TCP checksum offloading causing all packets to register checksum errors.]

00133

fin-unhappy-client.pcap

00025

frag-needed.pcap

00081

ftp-crack.pcap

Copyright 2008 Protocol Analysis Institute, Inc.

Page 11

Laura Chappells Trace File Library

00142 ftp-download-good2.pcap An FTP user wants to download a file, but not until it knows the size of the file [P12]. There are a few lost packets along the way, but nothing too significant. Consider setting Time Display Format > Seconds Since Beginning of Capture and then setting a Time Reference on the first data transfer packet [P16]. Scroll to the end of the trace to find the download time. This is an interesting trace of an FTP file upload process that seemed to take forever and then generated an error. What happened here? Can you figure out which direction packet loss must have occurred on? In this case, an FTP download is unsuccessful because of a limit imposed by the FTP server. The response message is quite clear [P38]. An FTP client sets up a passive mode data transfer to an FTP server. All seems to work well for a 0 byte LIST transfer, but when the client tries to use the STOR command [P38], the server abruptly shuts down the connection [P41]. The server sends a 425 Error code explaining that it fears a possible FTP Bounce Attack or FXP Transfer [P42]. Someone went a little overboard when sanitizing a trace file. Can you learn anything worthwhile about this communication just by looking at the limited information available? Although this FTP server seems to accept the PASV command [P30], when the user attempts to connect to the offered port, the server doesn't answer. Even though the FTP server shuts down the FTP data connection, it makes a snide remark to the client. [P39]

00101

ftp-failedupload.pcap

00039

ftp-filesizeproblem.pcap

00192

ftp-fxp-cutoff.pcap

00080

ftp-pasv_scrubbed.pcap

00190

ftp-pasv-fail.pcap

Copyright 2008 Protocol Analysis Institute, Inc.

Page 12

Laura Chappells Trace File Library

00018 ftp-putfile.pcap The client uses the STOR command during an active FTP connection. Note the Wireshark decode of the PORT command packets [P16] [P37] [P55] [P71]. What data is being transferred across the secondary connections established by the server? What is going on in this FTP communication? First of all, the traffic is not efficient. Secondly, it would raise the red flag of the security team. This is definitely a non-standard way of sending FTP traffic to a server.

00079

ftp-tcp-segment.pcap

00028

ftp-transfer.pcap

This FTP transfer process consists of five TCP connections. Reviewing TCP Conversations information is the best way to see which connection supports the majority of the traffic. There are some problems as indicated in the Expert Info window as well. Trying to upload a file (you can see the PPT file name in the trace), but the connection is lost. Note the retransmissions leading to a whole slew of FIN ACK packets. A background process in an application automatically makes an FTP connection to a server and performs a write check using the MKD and RMD commands. This is the type of background traffic to watch on the network.

00204

ftp-up-disconnect.pcap

00188

ftp-writecheck.pcap

00187

ftp-wrongpwds.pcap

This simple trace file depicts a user who provides the wrong FTP username and password several times. The username IEUser@ has been submitted because the user is performing FTP from inside Internet Explorer.

Copyright 2008 Protocol Analysis Institute, Inc.

Page 13

Laura Chappells Trace File Library

00116 gettime.pcap A client connects to pool.ntp.org on port 123 to time sync its system. You can see the static structure used in both the NTP client mode and the NTP server mode. Notice that there are 12 IP addresses provided in the DNS response [P2]. Gnutella is a peer-to-peer (P2P) platform that supports numerous clients including Morpheus, Bearshare, LimeWire and Mutella. Our Gnutella client is running BearShare [P199] [P433] [P434]. Notice that our client is trying desperately to connect with other "Gnutellians" on port 6346. In addition, our client is relaying requests on behalf of others - our client never made a request for a single file on its own. Try the filter gnutella. This HTTP trace depicts someone using the HEAD command instead of the GET command. The HEAD command is similar to the GET command except it does not expect the file to be transferred - it just obtains the associated header lines. For example, if the HEAD command is followed by the If-Modified-Since line, the sender can determine if there is a newer version of a file on the HTTP server. This client has more than one connection to a streaming video server, but nothing happens when they begin the stream viewing process. A quick review of the trace file indicates that the client rudely sends TCP RST packets [P28] [P29] to shut down the connections. The fault is at the client. Most likely a popup blocker process is getting in the way.

00038

gnutella.pcap

00027

http1.pcap

00132

http-client-refuses.pcap

Copyright 2008 Protocol Analysis Institute, Inc.

Page 14

Laura Chappells Trace File Library

00147 http-espn.pcap My favorite 'ugly' website (other than www.ebay.com) is www.espn.com. Consider selecting Statistics > HTTP > HTTP Packet Counter to view the number of redirections (Code 301 and 302) and client errors (Code 404). Now why is the client blamed for these 404 errors? It's ESPN's fault that we looked somewhere we weren't supposed to! Harrumph! Although this company has a nice feedback form online, when you fill out the form and click submit they rudely send an HTTP error code 403 [P10] [P13]. Someone needs to let the webmaster know the form is broken! The HTTP client receives a 301 Moved Permanently redirection from the HTTP server. Follow TCP Streams makes it easier to follow what is happening in this trace file. Browsing to www.msn.com is more complicated than it seems. When reviewing this trace, consider running Statistics > HTTP > Requests (do not apply a filter) to see how many systems the client actually connects to. HTTP allows us to retrieve partial content of a file loaded on a web server. For example, perhaps we just want to get the artist information for an MP3 file, but we don't want to download the entire file yet. This trace depicts a user sending a partial content query as noted by the 'Range: bytes=x-y' header field. Cool! An interesting trace file of a video streaming application. If you watch the stream traffic [P136-P1033], you notice the MSS is at 1380 bytes, not the expected 1460 bytes. A closer look at the TCP handshake process reveals the server limiting the MSS. Why?

00175

http-fault-post.pcap

00174

http-general.pcap

00050

http-msn.pcap

00115

http-partial-content.pcap

00131

http-pushy-flash-movie.pcap

Copyright 2008 Protocol Analysis Institute, Inc.

Page 15

Laura Chappells Trace File Library

00078 http-slow-filexfer.pcap Another problem file download caused by packet loss. Use the Expert Info Composite window to determine how many packets were lost in this file transfer. The client is trying to ping 10.4.88.88, but it appears that the local router can't locate the device on the next network. The local router sends an ICMP Destination Unreachable/Host Unreachable message indicating that it tried to ARP for the target, but didn't receive an answer. You MUST learn ICMP in depth to secure, optimize and troubleshoot your network effectively! This trace contains some interesting ICMP traffic. If you look closely you can spot two systems that are behaviing strangely on the network. What is triggering the ICMP Destination Unreachable/Protocol Unreachable responses?

00155

icmp-destinationunreachable.pcap

00077

icmp-lotsostuff.pcap

00154

icmp-payload.pcap

ICMP Echo Request are not supposed to have data in the payload, but that's what we see in these packets. You would want to ensure that the payload doesn't contain data coming off the local system. There is an old exploit called 'Loki' that tunneled traffic inside ICMP Echo packets. When you see ICMP echo request packets on the wire, check the payload to see if you can identify the application sending the data. Try using the following display filter: data contains "from".

00017

icmp-ping-2signatures.pcap

00016

icmp-ping2signaturesagain.pcap

These two pings come from a Windows system (notice the partial alphabet in the padding) and a Network General Sniffer system (try using a data contains "cinco" filter).

Copyright 2008 Protocol Analysis Institute, Inc.

Page 16

Laura Chappells Trace File Library

00153 icmp-redirect.pcap A clear case of ICMP redirection. As you examine this trace, pay close attention to the MAC address in the packets and the contents of the ICMP Redirect packet [P2]. That packet contains the IP address of the recommended router to get to 10.3.71.7. The client must already have the MAC address of that router (or perhaps the analyst filtered out ARP traffic). Wow my DHCP server [10.1.0.1] wasn't up when I needed to renew my IP address. When it did restart it offered me a different address and a bogus address for my default gateway. That triggered my system to perform ICMP Router Solicitation. This is typically not a good ICMP packet to see on the network. [Yes, you can see my name in the trace file. Why hide it I'm the one that killed the DHCP server in the lab and I paid the price.] The ICMP traffic in this trace is suspect. Consider filtering on the ICMP traffic only and examining the payload. Also consider looking at the IP Conversations information to see if traffic is flowing bi-directionally between any devices.

00152

icmp-routersolicitation.pcap

00006

icmpstrange.pcap

00151

icmp-traceroute-normal.pcap

This is a classic ICMP-based traceroute operation shows the dependency on the ICMP Time to Live Exceeded/Time to Live Exceeded in Transit response that is used to locate routers along a path. One of the routers doesn't generate these responses though. This traceroute client is excruciatingly slow between some of the TTL increment sets. What triggers the ICMP Destination Unreachable/Port Unreachable message sent to the client [P64]? How many hops away is the target?

00037

icmp-tracert-slow.pcap

Copyright 2008 Protocol Analysis Institute, Inc.

Page 17

Laura Chappells Trace File Library

00138 io-ftpupload.pcap No one will live long enough to upload files to this FTP server. Is the server at fault? The client? The network? Examine the Warnings and Notes in the Expert Info Composite to get the whole picture. The client is sending fragment ICMP Echo packets to the target. Try setting up Wireshark with and without IP fragment reassembly to note the difference. Edit > Preferences > Protocols > IP. [also in .cap format] You're being hunted! This IRC channel was established by a system that was loaded with malware. Follow TCP Stream to see the entire IRC communication in plain text. Do you notice the file download commands? Not a good sign at all!

00036

ip-fragments.pcap

00099

irc-channel.pcap

00061

is-pwdxfer.pcap

Invisible Secrets is one of my favorite tools - I use it primarily for steganography, but it also can do secure password transfer. This trace shows the secure password transfer process. Note the cleartext indication that this is an Invisible Secrets 4 communications. Is this really just a TCP scan? It appears so in the beginning. Examine the timing in this trace to see how the flow of the scan changes.

00023

justascan.pcap

Copyright 2008 Protocol Analysis Institute, Inc.

Page 18

Laura Chappells Trace File Library

00098 keepalive.pcap Don't get sidetracked by the TCP Checksum Incorrect messages - this NIC does TCP Checksum Offloading so Wireshark doesn't see the correct checksum value before the packets are sent out. What is interesting in this trace is the keepalive process that is triggered by an application. It appears to read from a file at offset 3584 for a maximum of 512 bytes (check out that data in the responses) [P1] [P5] [P9] [P13] [P17]. Not a pretty site. What was that programmer thinking? This live chat to a support line creates a nice secure connection. Oh, wait... make that 122 nice secure connections. Whazzup with that? Isn't that overkill? Look at Statistics > Packet Length to see how much of the traffic uses little itty bitty stinkin' packets! Although the client can get to the Google toolbar page, it can't get to the Verio home page. It doesn't appear that there is a path to the target. Why aren't there any TCP RST packets or any ICMP Destination Unreachable packets. Dug Song created Macof to flood network switch MAC address tables and cause them to go into 'hub mode.' This tool still reaks havoc on the network. Can you identify the signature in this flood traffic?

00126

live-chat.pcap

00076

lost-route.pcap

00075

macof.pcap

00022

madclient.pcap

This client complained that the network wasn't working. A short packet capture reveals the truth. This application, although not recognized by Wireshark, identifies itself in the payload. In addition, it contains an error message that explains why things didn't work as the user hoped.

Copyright 2008 Protocol Analysis Institute, Inc.

Page 19

Laura Chappells Trace File Library

00074 messenger-ugly.pcap Anyone who buys product based on Messenger popups deserves what they get. This popup was refused using an ICMP Destination Unreachable/Port Unreachable response [P2]. The message is in cleartext format in both packets because the Windows target system includes the entire original request in the ICMP response (unnecessary since the spec says you only have to include the first 64 bits of the original datagram's data). Nessus (www.nessus.org), the penetration testing tool, doesn't try to be sneaky. Use the Find feature to search for the string 'nessus' in this trace file (do not search case sensitive). You'll find the 'nessus' signature all over in this trace file. In addition, you'll see the illegal ping packet [P3] used by Xprobe2 when the Nessus scan runs. One host is performing a Nessus penetration test on another host. Fortunately, Nessus does not try to be stealthy. Use Edit > Find Packet to look for the string "nessus". Wow! A decent IDS looking for this signature should alert us immediately to a Nessus scan on our production network. The NICNAME application traffic (using port 43) is generated by a WHOIS query. In this case, the query is based on an IP address. Is the query successful?

00114

nessus.pcap

00060

nessus2.pcap

00073

nicname.pcap

00072

nicname-packet-level.pcap

This query uses RWHOIS (Referral WHOIS) on port 4321. RWHOIS extends the capabilities of WHOIS in a hierarchical structure. This trace shows a successful RWHOIS query handled by root.rwhois.net.

Copyright 2008 Protocol Analysis Institute, Inc.

Page 20

Laura Chappells Trace File Library

00035 nimda.pcap There are some suspect HTTP GET requests in this trace. No one should be looking for root.exe or cmd.exe on the network. This is a Nimda client performing discovery. Follow TCP Stream to note the reference to Kazaa.

00071

nmap-fragscan.pcap

This trace file depicts a system sending an IP fragment scan. If you examine the IP header, the protocol field indicates that TCP follows. You can manually decode the TCP header to identify the purpose of the TCP packets. Do you see the follow up fragments? This is the kind of traffic you never want to see on your network someone is doing an IP scan... not a UDP scan... not a TCP scan. This person wants to know what services are supported directly on top of the IP header. Examples include EGP, IDRP, ICMP and encapsulated IPv6. Sort the Info column heading to see all the protocols queried for. This trace depicts an Nmap scan. Open the Statistics > Conversation window and examine the TCP conversations. Do you see any common port number used by Nmap to perform this scan? Did Nmap hit any ports more than once?

00137

nmap-ipscan.pcap

00054

nmapscan.pcap

00053

nmap-see-short-ping.pcap

There are some strange ICMP Echo requests in this Nmap scan [P1] [P8]. What data is supposed to be echoed back? What is the payload in the other ICMP Echo requests? There are also some unusual scans on port 1 which trigger ICMP Destination Unreachable/Port Unreachable responses.

Copyright 2008 Protocol Analysis Institute, Inc.

Page 21

Laura Chappells Trace File Library

00034 nosmtp.pcap A user (10.1.0.1) complains that they cannot send email to the SMTP server (10.2.23.11). Examine the trace and determine if the fault lies with the client, the server or the network. . The AXFR command sticks out like a sore thumb. Someone is trying to do a DNS zone transfer and their request is being refused. Notice that this trace shows the two types of DNS queries - UPD-based and TCP-based.

00015

nst-axfr-refused.pcap

00014

nst-nslookup-mx.pcap

Someone is looking up the name service entry for the mail exchange server (MX). This type of query isn't normal to have on the network and should send up a red flag!

00049

nstpro-automatic-recon.pcap

NetScanTools Pro (NSTPro) is a great multi-function tool. This trace shows the automated reconnaissance process on the wire. As part of the process, NSTPro performs a realtime blacklist check, a WHOIS query, name server lookup, traceroute [filter on ip.ttl < 10]. Also build a filter to look for successful FTP connections using the following filter: (ip.dst==67.169.189.113) && (tcp.flags == 0x12). When analyzing a one-half of a redundant link between switches, we learned that the switches were not load-balancing. They had created two one-way paths. Data was being lost download - we could tell by the retransmissions (we had to assume the server received duplicate ACKs that triggered the retransmissions).

00113

one-way-drops.pcap

Copyright 2008 Protocol Analysis Institute, Inc.

Page 22

Laura Chappells Trace File Library

00013 osfingerprinting.pcap Someone is doing ICMP-based OS fingerprinting on the network using ICMP Echo, Timestamp, Address Mask and Information requests. Consider applying the following filter to identify illegal ICMP Echo request packets: (icmp.type==8) && !(icmp.code==0x00). This yields a signature for the OS fingerprinting application. This website sign-up has a problem -the password setting process crosses the wire in cleartext [P4]. Whoops.

00070

password-setting.pcap

00069

ping-routerequest.pcap

This is a really interesting trace. The sender is attempting to use the IP header option Record Route. Expand the IP header option subtree to see the format. Was it successful?

00184

pop3problem.pcap

The POP email application gives no indication as to why it is taking so long to pick up mail. In this trace we can clearly see the problem lies with the email server that is sending back an '-ERR-' response [P5]. Users can't get their email. It appears that their email programs just hang when they try to send/receive. In truth, we can see that there are spam messages with large attachments (.pif) that take a long time to download. Users need to be patient and the company needs to consider filtering this spam before it gets to the client systems. Follow TCP Stream on any POP packet to view the spam messages.

00182

pop-spamclog.pcap

Copyright 2008 Protocol Analysis Institute, Inc.

Page 23

Laura Chappells Trace File Library

00112 port-3128.pcap This isn't a normal communication on the network. It appears to be an HTTP communication over a non-standard port (3128). Follow TCP Streams to get an idea of which application is generating this unusual traffic.

00172

portscan.pcap

Setting your Time Display Format to Seconds Since Previous Packet reveals a subtle change between the beginning and the end of this TCP port scan. Notice the open ports on the target system [P14] [P19].

00068

proxy-problem.pcap

The client can't get off the network because of errors getting through the proxy server. You can read the proxy response in clear text - Follow TCP Stream. Also note the slow handshake response time. Not a good day for this user.

00111

rbl-check.pcap

It's interesting to see how a Realtime Blacklist (RBL) check works. Using DNS, the investigator sends numerous DNS queries out with the IP address and the domain name of the blacklist servers. Although most of the responses come back negative, it looks like the target IP address has been found on two of the blacklist servers, blackholes.five-ten.sg.com [P16] and dnsbl.sorbs.net [P26]. Somone is looking for a system that supports PCAnywhere running on port 5632. One target did not respond with an ICMP Destination Unreachable/Port Unreachable message [P21]. This may indicate that the system does have a service running on port 5632.

00033

scan-pcanywhere.pcap

Copyright 2008 Protocol Analysis Institute, Inc.

Page 24

Laura Chappells Trace File Library

00129 secret-ftp.pcap The traffic is already ugly on this new system that just had BitTorrent loaded on it. Look in the trace for the background FTP connection. The client didn't have any idea this connection was being established in the background. Some research indicated that all HP Media Center PCs included the game console program that made a secret FTP connection. Ugly. This client hits an IRC channel as user l l l l (four lowercase Ls separated by spaces) [P14] and later begins to do a scan on the network for anyone with port 139 open. Feels like a bot looking for other systems to infect. Look at the rapid rate of the scan that's why the response are bunched up at the end of the trace. [Note: Turn off the colorization on this trace or your head may explode. We ran this trace through an IP address cleaner program but it didn't recalculate the checksums.] Symantec: Wargbot; MS: Graweg; Trend: Worm_IRCbot; McAfee: Mocbot; F-Secure: IRCBot. [also in .cap format] While watching a Skype call being established and terminated, we noted the numerous UDP connections that were required and what appeared to be a command channel using TCP during the beginning and end of the call. Strange that it didn't terminate the TCP connections. This trace shows what happens when the DNS lookup for an SMTP server works fine, but the actual connection attempt does not. In a normal SMTP connection the user doesn't send a user name or password. Follow TCP Stream to clearly view the entire message. During the initial communication process, the server indicates that it supports pipelining and imposes no limitation on email size [P8].

00136

sick-client.pcap

00128

skype-call-connectdisconnect.pcap

00011

smtp-fault.pcap

00181

smtp-normal.pcap

Copyright 2008 Protocol Analysis Institute, Inc.

Page 25

Laura Chappells Trace File Library

00180 smtp-relaytest2.pcap Someone is running an SMTP relay test on our server. At no point do they send data they are simply watching the response to MAIL FROM: and RCPT TO: commands. Follow TCP Stream to view the entire communications more clearly.

00179

smtp-vrfy-bad.pcap

Someone is running the SMTP VRFY command against the SMTP server. Although the server doesn't support the VRFY command, its responses to MAIL FROM: [P17] and RCPT TO: [P20] can be used to verify the email address in question. This trace includes a simple SNMP queryresponse pair of communications. Are they all looking for the same information? Perform some Internet research to locate .1.3.6.1.2.1.25.3.2.1.5.1 (or search for SNMP MIB-2.25.3.2.1.5.1). You'll notice the response code of INTEGER 5 indicates that the stated of the device is 'down.' After performing an SQL connection test to port 1433 ms-sql-s), the attacker makes a login attempt with the client name SYD-S21-ESXI and username sa. The response indicates an error because the login for user sa failed. Filter on the SQL Error Number 18456 by using the following syntax: frame[65:4]==18:48:00:00. During the establishment of this SSL connection (HTTPS) there appears to be communication problems causing retransmissions. What on Earth is the scanner doing? Look at the TCP Flag settings in the scan packets. What is triggering the "TCP ACKed lost segment" expert notfication in Wireshark?

00096

snmp.pcap

00056

sql-attack.pcap

00067

ssl3session.pcap

00066

strangescan.pcap

Copyright 2008 Protocol Analysis Institute, Inc.

Page 26

Laura Chappells Trace File Library

00198 sym-404.pcap Look at all the 404 File Not Found responses during a Symantec LiveUpdate process. This type of update problem should be of concern to you. Look at all the 404 File Not Found responses during a Symantec LiveUpdate process. This type of update problem should be of concern to you.

00198

sym-404.pcap

00001

sym-failed.pcap

Filter on http to see what's happening more clearly. This will remove the handshake packets and the ACK responses. Why did this Symantec LiveUpdate process fail? The client renews its subscription for the Symantec product with minimum HTTP 404 response codes. There appears to be a periodic GET request (in 15 second intervals) [P20] [P415] [P431]. Filter on the http.request.uri field in one of these packets to find out how often this query goes out. Are all the replies the same? This Symantec update process doesn't seems to work very well. Consider building a filter for http.response.code == 404 and note the number of "File Not Found" responses. Now compare these two display filters and explain the difference in your results: (1) !http.response.code == 404 and (2) http.response.code !=404. Good lesson! This trace shows SYSLOG traffic traveling over port 514 on the network. If SYSLOG is used to transfer firewall or IDS alerts, imagine what someone can learn about your security system. Eek.

00065

sym-update.pcap

00095

sym-update2.pcap

00110

syslog.pcap

Copyright 2008 Protocol Analysis Institute, Inc.

Page 27

Laura Chappells Trace File Library

00032 tcp-ack-scan.pcap An ACK scan isn't used to find an open port - it is used to determine whether there may be an unfiltered path to a target system. For example, the fact that we get a TCP RST response [P3] to the ACK scan to port 80 (HTTP) indicates that this outbound port value is not filtered at a firewall or router. Sort the Source column heading to view all the response from 12.234.14.63 - if a response was received from an ACK scan on a port, then that port is not blocked by an intermediary device. This is a plain and simple TCP handshake process. Consider setting your TCP Preferences so Wireshark does not use relative sequence numbers - you can see the actual sequence numbers of the communications. In this short trace you can witness the 'phantom' byte that increments the Sequence Number value during the handshake process. You probably don't want to see this on the network - traffic to TCP Echo port (7). Consider the implications if both the source and destination ports were 7. Ugh. This trace shows the normal TCP FIN process. There are actually two common variations of this process - FIN, FIN ACK, ACK or the four-packet process shown in this trace. Note that the TCP connection is still active and waiting for a timeout now.

00031

tcp-con-up.pcap

00010

tcp-echo.pcap

00009

tcp-fin.pcap

Copyright 2008 Protocol Analysis Institute, Inc.

Page 28

Laura Chappells Trace File Library

00109 tcp-handshake-problem.pcap An amazingly simple communication that went all wrong because of the TCP handshake. Each packet of the handshake looks good [P3-P5]. When the client begins sending data to the RWHOIS server, however, it receives SYN ACK packets in response. All this trouble just because the third packet of the handshake never arrived. The duplicate ACKs are asking for Sequence number 1 again - unfortunately two of the client's packets have this same sequence number. This will never get resolved. An application that wants to keep the TCP connection open during a long idle time can trigger the TCP Keepalive function. This trace shows just such a process for traffic maintaining a connection between ports 1863 and 2042. Is there any data contained in these TCP Keepalive packets? How do you think Wireshark determines that these are TCP Keepalives? This HTTP file transfer is never going to achieve the maximum throughput potential because of a Maximum Segment Size (MSS) issue. Does the problem reside with the client or the HTTP server? The Flow Graph indicates that the client is communicating with more than one HTTP server. Is this problem evidence on the second server as well? When you set the Time Display Format to Seconds Since Previous Packet, you can easily see the TCP retry process with five retransmissions of the packet that did not receive an ACK [P2]. [also in .cap format]

00064

tcp-keepalive.pcap

00094

tcp-low-mss.pcap

00055

tcpproblem.pcap

Copyright 2008 Protocol Analysis Institute, Inc.

Page 29

Laura Chappells Trace File Library

00063 tcp-window-good.pcap This trace depicts a large TCP window used for a file transfer. There are moments when the receiver advertises a Zero Window, however. How much delay do these Zero Window conditions inject into the file transfer. Analyze > Expert Info Composite > Notes > expand the Zero Window entry. As you click each Zero Window packet in the Expert Info Composite window, the trace file highlights the corresponding packet. What file is being transferred? Which side of the communication is trying to terminate the TCP connection? What is the response from the other side of the connection? What size is the file being transferred? Do you think the entire graphic file was received by the client? Someone makes a telnet connection to a Cisco router to run the 'show version' command which is echoed back, as is the 'exit' command. The password, however, is not echoed back. Follow the DO, DON'T, WILL and WON'T command as the client and server negotiate the connection behavior. Yes, it's true there are still people who play text-based games... and now they are online. This telnet session depicts a user connecting to a MUD (Multi User Dungeon) game. Try out your 'telnet' display filter to find that you lose the handshake process and the ACKs. Try using tcp.port==23 instead. One of my all-time favorite trace files! Hopefully the towel.blinkenlights.nl telnet site will be up for you to try someday. You MUST select Follow TCP Stream to watch a text-based Star Wars adventure. Some people have too much time on their hands... but then again, I analyzed the Star Wars traffic... <sigh>.

00093

tcp-wont-shutup.pcap

00171

telnet.pcap

00170

telnet-batmud.pcap

00169

telnet-funny.pcap

Copyright 2008 Protocol Analysis Institute, Inc.

Page 30

Laura Chappells Trace File Library

00092 telnet-questionable.pcap Examine this trace to determine if the telnet client and telnet server agree on the communication settings. DO, DON'T are demands being made from the source to the target. WILL, WON'T are statements from the source indicate what it is willing or not willing to do. How long did it take to get to the Login prompt? This client's telnet connection request is refused by the target in the traditional TCP RST/ACK method. An excessive number of RST/ACKs on the cable may be indication of a TCP port scan. In this case it is just one wayward telnet client. Interesting to see someone telnet to a server using a guest account and already have mail waiting [P38]. There's more than one telnet session in this trace file.

00168

telnet-refuse via rst.pcap

00167

telnet-torfree.pcap

00091

tftp.pcap

This TFTP communication raises eyebrows on the network. Why can't you Follow TCP Stream on this communication? Do you see any readable data in the payloads?

00008

timesync.pcap

This trace shows a system performing a DNS query for tock.usno.navy.mil and then running a Network Time Protocol request on port 123. Interesting to plug into the corporate network and find TiVo discovery beacons flying about.

00197

tivoconnect.pcap

Copyright 2008 Protocol Analysis Institute, Inc.

Page 31

Laura Chappells Trace File Library

00149 ttl-counting.pcap This trace is actually more than just an ICMP-based traceroute operation. There are some really ugly ICMP packets in there, but we are focusing on the IP header Timeto-Live (TTL) value in the first set of packets in the trace. When packets use an incrementing IP TTL value, they are most likely being used to locate routers along a path. Although most people think of ICMP Echo Requests and ICMP Echo Replies when you mention the term "echo," there are also TCP and UDP echo communications. Can you identify the port used for this UDP communication? What would happen if the source and destination port was set to the echo port? DHCP, DNS, NetBIOS Name Service and Microsoft Messenger make up the UDPbased communications in this trace. You wouldn't wish this NetBIOS and Messenger traffic on your worst enemy what a filthy network. This trace contains just the UDP traffic from a NESSUS scan and the numerous ICMP Destination Unreachable/Port Unreachable responses the scan has triggered. View Statistics > Protocol Hierarchy to see the range of target ports hit in this penetration test. This UDP-based traceroute targets a series of bogus port numbers starting with 32767. In this case the scanning system is also performing name lookups using DNS PTR queries. What is the target of the scans? Do you see any communications that do not match this pattern?

00090

udp-echo.pcap

00166

udp-general.pcap

00165

udp-pentest.pcap

00052

udptraceroute.pcap

Copyright 2008 Protocol Analysis Institute, Inc.

Page 32

Laura Chappells Trace File Library

00108 udp-tracert.pcap When a ping connectivity test won't work because the target doesn't answer pings, consider a UDP connectivity test. This UDP-based traceroute is targeted at bogus port numbers starting with port 32767. The process relies on the target sending back a Destination Unreachable/Port Unreachable response [P59]. It looks like this UDP traceroute utility does name resolution as well. Scanning a port once isn't good enough for this persistent little application - it needs to scan each port six times to figure out whether it is open or not. The first four packets of the trace could be an ACK scan on port 80.

00030

uglytrace.pcap

00089

using-time.pcap

Scroll through the entire trace file before making any assumptions on the cause of poor performance for this client. This trace illustrates the importance of paying attention to the time values in trace files. The ugliest communications are not necessarily the cause of poor performance. Identify the most time-consuming fault in this trace. Examine the "If-Modified-Since" lines in the HTTP GET requests from this client. How does that parameter affect the file download process? Are there any 404 response codes in this trace? Is the video stream bursty or steady? This user must have recently browsed to www.packet-level.com based on the high number of HTTP 304 Not Modified responses (39 in all) sent from the server. If the user complained of slow performance in the previous connection and we are troubleshooting the problem, we need to ensure they do not receive any HTTP 304 Not Modified responses they should download all files and not pull them from cache.

00088

video-streaming.pcap

00164

web-browse-ok.pcap

Copyright 2008 Protocol Analysis Institute, Inc.

Page 33

Laura Chappells Trace File Library

00127 webcast-keepalive.pcap This videocast ended 130 seconds into the trace file. Build an IO graph to watch the keepalive process as the video concluded and the client kept the connection alive [P2562] [P2572] by sending a GET request for caption.aspx?filetype=1 every 6 seconds. This occurs all during the video download as well. This is an unusual scan - the TCP flag settings are illogical - FIN, RST, ACK. We would expect a target to send back a RST.

00007

weirdscan.pcap

00107

whois-podbooks.pcap

This WHOIS query begins with a DNS lookup for ANY DNS entries related to podbooks.com and progresses to learn the contact email address. Next the researcher contacts the ARIN WHOIS database using port 43 (NICNAME), but the server says there isn't a match. This WHOIS query begins with a DNS lookup for ANY DNS entries related to podbooks.com and progresses to learn the contact email address. Next the researcher contacts the ARIN WHOIS database using port 43 (NICNAME), but the server sais there isn't a match. A window frozen condition can kill file transfer speed. Set the Time Display Format to Seconds Since Beginning of Capture and right click on the first ZeroWindow packet [P30] to Set Time Reference. How much time did this condition waste?

00107

whois-podbooks.pcap

00106

window-frozen.pcap

Copyright 2008 Protocol Analysis Institute, Inc.

Page 34

Laura Chappells Trace File Library

00196 window-scaling-bad.pcap It would have been nice to set up TCP window scaling for this HTTP connection. The client advertises a window scale of 2 (multiply the 65,535 window by 4) [P1], but the server doesn't support TCP window scaling. Sigh. Now this is the life! The client advertises a TCP window scale of 2 (multiply the window value by 4) and the server supports window scaling as well (although with a window scale of 0 which does it no good on the receive side of things). Check out Wireshark's ability to calculate the correct window size [P3] for the client. This is a feature you can turn on/off in the Preferences > TCP area. The client and the server can do window scaling, but when we look at the scaled value for the client [P3], it's only set at 5840. Shouldn't it be higher (5,840 times 4)? Highlight the TCP window field and you'll find out why we are still at 5,840. Bummer. It's a weird HTTP communication anyway. World of Warcraft is glitching darn it! Just when Im about to level up! Consider reassembling the TCP datastream to see what crosses the network in plain text. Something about this communication just feels wrong. Follow TCP Stream to find out what's really going on here. Now is the time to protocol force the correct decode on the traffic.

00195

window-scaling-good.pcap

00194

window-scaling-wishful.pcap

0802

wowprop.pcap

00105

wrong-port.pcap

Copyright 2008 Protocol Analysis Institute, Inc.

Page 35

Laura Chappells Trace File Library

00062 xprobe2.pcap Xprobe2 is an OS fingerprinting tool developed by Ofir Arkin <www.syssecurity.com>. This trace depicts the ICMPbased process using ICMP Echo, Timestamp, Address Mask and Information requests. Notice the illegal ICMP Echo request code field value [P3]. This is a signature of Xprob2. This Nessus scan begins with an Xprobe2 OS fingerprint operation. Build the following filter to weed out illegal ICMP Echo request packets: (icmp.type==8) && !(icmp.code==0x00). Do you notice anything unusual in Packet 6044? Review the Statistics > Protocol Hierarchy to see the pattern of a scan. This is a normal ZoneAlarm update - it's important to know how your personal firewall and virus detection tools perform their updates.

00051

xprobe-and-nessus.pcap

00201

zonealarm-update.pcap

Copyright 2008 Protocol Analysis Institute, Inc.

Page 36