If you would like to read the other articles in this series please check out:
- Packet analysis tools and methodology (Part 1)
- Packet analysis tools and methodology (Part 2)
- Packet analysis tools and methodology (Part 3)
Packet analysis 101
Over the course of the past three articles we have seen how to set up our own little intrusion detection system and analysis lab. In this final part we will see how we can use these very same tools to do some analysis. Not many people actually do packet analysis for several reasons. A lot of people are not familiar with TCP/IP at the packet level, and there are not many jobs that actually require you to do this. If you have followed this article series you can mitigate these reasons to an extent, and advance your skills.
Quite often a system administrator is also given the task of managing security on their network. Being a system administrator is a hard enough job as it is, let alone adding the task of security to the mix. Learning TCP/IP can also be a daunting task, but it will pay dividends for you in many ways. After all, TCP/IP is the absolute bedrock that computer to computer communications are built on. It pays to be able to have a very good grasp of it. There are many fine tools out there which will break things down for you, but they don’t really make you understand the theory of it.
On with it!
Well enough chit chat for now lets get to the meat of the matter. First please download the binary log file that I have created. This will allow you to input the exact same commands that I am using, and therefore get the same results. In essence you can follow along with me, as I do my cursory analysis. For this you will need to take the binary log file, and process it through Snort. Doing this will result in your having an “alert.ids” file in your log directory. It is this log that you in turn will process through Snortsnarf. In case you forget the syntax to process the binary log file will be as follows;
C:\snort\etc> c:\snort\bin\snort.exe -r “binary_file” -c snort.conf -A full
I am also assuming that you are doing this in win32. There are various ways to invoke Snort to do the job. The way that I have shown you above is the quickest way to get Snort working for you. You can do some modifications to the snort.conf later when you are more comfortable with the program. So you will now have done the above, and generated an “alert.ids” file. This will be in your log directory. You may get an error when doing the above. It will concern not being able to access the “log” directory. What you can then do is simply create a log directory in C:\snort\etc This is done as follows;
“mkdir log”
After having done this your initial syntax above for snort will work. Now that you have the file we will process it via Snortsnarf. The syntax is as follow;
C:\SnortSnarf-021111.1> snortsnarf.pl -win -rs alert.ids
This program will take the “alert.ids” file, which is the output of Snort, and output it in some nicely formatted HTML pages for us. Snortsnarf is very nice for it will give us these nice pages, as well as some excellent hyperlinks to sites for lookups etc. Now that the program is ready it will have generated a directory called “snfout.alert.ids” It is this directory that you will want to navigate to via a web browser.
So we can see from the above picture that we have an “index.html” file. Lets click on it as this is where all of our high level info will be. Below is a picture of the exact alarms that were generated by myself. You should have the same as well. There may be a slight variance if you have included rules other then the standard ruleset that comes with Snort.
Now we will click on the first alert titled “NETBIOS SMB DCERPC LSASS” and see what is going on. We will click on the summary link included, as this will give us a summary as advertised of what is happening with this alert. Well we now see that there were nine alerts triggered by 192.168.1.102 that were directed to 192.168.1.101. From here I would click on 192.168.1.102 as that will give us some more information on this alert. Specifically we will see the exact packet that first triggered this alert. Please see below;
[**] [1:537:12] NETBIOS SMB IPC$ share access [**][Classification: Generic Protocol Command Decode] [Priority: 3]03/13-11:15:24.142705 192.168.1.102:32781 -> 192.168.1.101:139TCP TTL:64 TOS:0x0 ID:24062 IpLen:20 DgmLen:127 DF***AP*** Seq: 0x3A7C1D85 Ack: 0xFA4695E6 Win: 0x5B4 TcpLen: 32TCP Options (3) => NOP NOP TS: 5456290 4504
With this in hand we can now go to our binary log file and investigate further what it is that happened. With the above information we will build a BPF filter to help us navigate to this packet quickly. I would personally build a filter based on the source IP address and source port. Reason I would do this is that the source port of 32781 is an ephemeral port that is unlikely to reappear in the file after the session is done. Lets try it! Please note that you will have to bring up a DOS prompt and do the below noted via windump.exe
C:\windump.exe> windump.exe -r "binary_file" -nXvSs 0 ip and host 192.168.1.102 and src port 32781 |more
Having done this command we notice that we are at the start of the three way TCP/IP handshake between 192.168.1.102 and 192.168.1.101 At this point we notice that once the handshake is done we have a packet there at timestamp 11:15:24.119210 as seen below.
11:15:24.119210 IP (tos 0x0, ttl 64, id 24060, offset 0, flags [DF], length:
152) 192.168.1.102.32781 > 192.168.1.101.139: P [tcp sum ok]
981212356:9812124
56(100) ack 4198929678 win 1460 <nop,nop,timestamp 5456266 4504> NBT Packet
0x0000: 4500 0098 5dfc 4000 4006 5848 c0a8 0166 E…].@[email protected]…f
0x0010: c0a8 0165 800d 008b 3a7c 1cc4 fa46 950e …e….:|…F..
0x0020: 8018 05b4 80dc 0000 0101 080a 0053 418a ………….SA.
0x0030: 0000 1198 0000 0060 ff53 4d42 7200 0000 …….`.SMBr…
0x0040: 0018 0120 0000 0000 0000 0000 0000 0000 …………….
0x0050: 0000 d815 0000 7b46 003d 0002 4d45 5441 ……{F.=..META
0x0060: 5350 4c4f 4954 0002 4c41 4e4d 414e 312e SPLOIT..LANMAN1.
0x0070: 3000 024c 4d31 2e32 5830 3032 0002 4e54 0..LM1.2X002..NT
0x0080: 204c 414e 4d41 4e20 312e 3000 024e 5420 .LANMAN.1.0..NT.
0x0090: 4c4d 2030 2e31 3200 LM.0.12.
What the above packet tells us is that the tool Metasploit is being used, and probably the LSASS exploit as well due to the LANMAN reference in the ascii content. Though it may not seem as if you have done alot by following me, you have definitely done so. You have laid down the planks to further advance your packet analysis capabilities. With this in mind I will keep the rest of the binary log a secret if you will.
The challenge
Using both the Snortsnarf output, and the binary log to further your search I highly encourage you to ferret out just what is happening. One simple challenge for you! Can you tell me via email what is the exact timestamp of the packet where 192.168.1.102 obtains system level access on 192.168.1.101 via the LSASS exploit? Please email me with your answer, or questions if you cannot find it. For me to further go on would be to simply explain again the same process we have used so far. Barring an all inclusive knowledge of protocols and attacks one must use Google. If you don’t know something then use Google for it, and odds are someone else has seen it! I sincerely hope that this article series was an eye opener into the world of packet forensics and computer security. Remember that the greater your understanding of TCP/IP will result in a greater understanding of all things computer related.
If you would like to read the other articles in this series please check out:
