We had a reader who sent an email to us tonight asking for some guidance "when tearing into packets".  They are wanting to expand their skills at packet analysis.  Since Guy was asking for packets earlier in the evening, it was a timely question.  For many of people, packets are a mystery.  I think back many, many (its been a while) years ago when I first started looking at packets.  I was so anxious to learn it and become really good at it but had no idea where to start.  Over my years of looking at packets, I have become completely convinced that packet analysis is well and truly art form (and alot of learning).  Each person will have their own style and approach to looking at packets and traffic.  However, there are some fundamental things to start with.

The reader submitted an question and initial list of things he/she thought they should look at first.  I'm going to include that question and list, then add to it.

Question submitted from reader:  "What are the top 10 or so questions (what & why ask) you would ask yourself when looking at packets you suspect contain evil?"  Two things with this question.  First, the indicators you received, alerts, users calling, etc. are a good way to point yourself in the right direction of things to look at initially.  Start narrow and work your way wider when looking at the packets.  Second,  I would modify the thought process when looking at packets.  Don't automatically assume evil!  Why you might ask?  Because I have watched people try to force packets into being malicious in nature to support their theory, when in reality something was just broke or it was normal behavior!   Yet they were convinced something evil was going on and had management all spun up.  Look at packets from a clean slate of what are they telling you!  Don't assume one way or other.  The packets are innocent until proven guilty:)  Here's a past diary example of suspicious behavior being "normal":  

Here is what the reader submitted: 

1. Look for what IP went to an IP of interest --> Who followed a link, uploaded some data, etc.
2. Look for a file that was downloaded --> Looking for malicious files to see if machine got infected
3. Look for when (time) a file was downloaded --> To see if data exfiltration or strange behavior started soon after
4. Look for the dst IP and port used --> To review the data going out the door
5. Check DNS TTL --> Low TTLs might be an indication of malicious intent or Flux botnet

This is really tough, because there are so many things that you can look for in packets.  First and foremost, I can't stress the importance of learning normal!!!  Once you learn normal, the abnormal just jumps out at you.  The RFCs are a great place, but have coffee handy.  There are alot of website that have good information about packets, but beware, I have ran across incorrect data too.  Here are a few more things to look at.  I can tell you why I look at it, but its the totality of information that helps you figure out what is going on.

6. What protocol is being used?  Are we dealing with TCP, UDP, ICMP?  It will help focus where to start based on why you went looking in the first place.  What made you suspect the traffic and what protocol would it use.
7. Do you think the issue is at the application layer or is something going on in the transport layer?  What are your indicators to help narrow your focus?
8. Look at the source port -->  Is it staying constant or is it changing?  A source port should stay constant for each session, but change (usually incremental) for the next session.  A constant source port can indicate a poor coding (or deliberate) in a tool or malware.  It is a characteristic that might eventually help you ID what tool/malware it might be.
9. Look at the sequence numbers -->  Are they changing like they should or are they staying constant.  It can indicate many things depending on the scenario.
10. I look at the TTLs (same IP but widely varying; etc), IPID/fragID (fixed or changing), flag fields (IP and TCP headers), etc.  Any of the packet fields to see if the traffic is behaving normally.  (if its a large capture, this is much more difficult and time consuming)
11. If you use wireshark to do your packet analysis, it has some great features to give you statistics about your packet capture.  This can help you find interesting pieces of traffic to start your analysis.
12. What's in the payload is always of interest.  Sometimes, you find glaringly obvious things like:  "This program cannot be run in DOS mode" which is a good indicator for an executable being downloaded. 

As a note for my analysis approach, I like to line up fields up as much as possible.  Sometimes a little work up front to do this pays off in a quick visual inspection of the data.  You can see anomalies better. 

Packet analysis is such a amazing, interesting and fun field of interest.  I really enjoy seeing and understanding how other people approach the analysis. If you have any tips or advice for becoming good at packet analysis, please send them in!  There are alot of young and old analysts out there who would appreciate it.