1 00:00:01,570 --> 00:00:07,540 Let's have another look at the diagnostic possibilities of Wireshark. 2 00:00:07,610 --> 00:00:14,150 The point is to detect a situation when someone tries to send a large amount of data well try out the 3 00:00:14,150 --> 00:00:20,830 data visualization capabilities of Wireshark to evaluate the contents of the file. 4 00:00:21,130 --> 00:00:23,160 Let's try to visualize them first. 5 00:00:28,250 --> 00:00:35,010 We look at the IO graphs from the statistics menu the image shown below is a graphical representation 6 00:00:35,010 --> 00:00:39,230 of units called packet Tich. 7 00:00:39,400 --> 00:00:41,560 The unit is not really intuitive. 8 00:00:41,710 --> 00:00:45,120 We can change it into bytes Tich. 9 00:00:45,180 --> 00:00:51,730 Now we see at what speed data is transmitted at a given point in time we see how the speed with which 10 00:00:51,790 --> 00:00:55,160 anyone sent or received data changed over time. 11 00:00:56,270 --> 00:00:57,710 It's presented as a summary 12 00:01:01,130 --> 00:01:02,780 looking at the statistics. 13 00:01:02,990 --> 00:01:08,480 We can notice that one of the computers who tried to establish a connection was identified by the address 14 00:01:09,050 --> 00:01:13,410 ten point zero point five two point one six four 15 00:01:16,340 --> 00:01:22,160 this information can be included in the graph. 16 00:01:22,180 --> 00:01:26,380 It turns out that we can visualize a variety of information on the graph 17 00:01:31,300 --> 00:01:34,770 after we've created a red graph representing a new rule. 18 00:01:34,930 --> 00:01:37,540 We can change the graph style to impulses. 19 00:01:37,930 --> 00:01:44,520 We can make the graphs overlapped based on the filters previously created in Wireshark. 20 00:01:44,590 --> 00:01:49,780 If we look at the example again you should notice that the client downloaded data from two different 21 00:01:49,780 --> 00:01:57,260 servers and in one case the bandwidth was small but in the other much bigger. 22 00:01:57,420 --> 00:02:05,530 In this example we're focusing on data visualization in Wireshark. 23 00:02:05,560 --> 00:02:12,700 Let's see another problem namely the case before what happens if wireshark is not able to properly interpret 24 00:02:12,700 --> 00:02:22,140 the data examining the above capture file you'd conclude that this is a net BIOS over TCAP IP session 25 00:02:28,770 --> 00:02:31,430 looking closely at the data presented by Wireshark. 26 00:02:31,530 --> 00:02:35,650 It turns out that the program does not interpret the data as SMB. 27 00:02:35,790 --> 00:02:38,160 It shows raw data. 28 00:02:38,210 --> 00:02:43,790 This is an example of a situation in which someone uses a protocol that utilizes the TCAP transport 29 00:02:44,740 --> 00:02:51,320 that wireshark is not familiar with or someone has changed the destination port and wireshark decodes 30 00:02:51,320 --> 00:02:52,470 the wrong data. 31 00:02:54,060 --> 00:02:55,970 What should we do in this case. 32 00:02:56,720 --> 00:02:58,880 First we'll try to decode it. 33 00:02:59,180 --> 00:03:01,860 If you suspect what could really have happened. 34 00:03:02,090 --> 00:03:05,780 Select any packet with the right mouse button and choose decode as 35 00:03:09,910 --> 00:03:13,480 from the list you can choose the protocol that you suspect was used. 36 00:03:14,410 --> 00:03:18,720 Let's try to decode data as T.P.. 37 00:03:18,900 --> 00:03:23,040 After playing the decoder the situation looks better right away. 38 00:03:24,160 --> 00:03:27,090 We have a correct interpretation. 39 00:03:27,150 --> 00:03:33,300 We can now track the selected packet by using the follow TCAP stream from the right mouse button click 40 00:03:33,300 --> 00:03:33,810 menu 41 00:03:38,630 --> 00:03:42,640 it turned out that it was actually a TCAP session. 42 00:03:42,730 --> 00:03:49,180 We can see who connected to which server and what folders they browse through if in the main wireshark 43 00:03:49,180 --> 00:03:51,600 window under the subheading data. 44 00:03:51,680 --> 00:03:53,890 There's not information about the protocol. 45 00:03:54,110 --> 00:03:59,870 Try decoding it as a different protocol this operation almost always succeeds. 46 00:04:01,620 --> 00:04:04,630 Shortly we'll look at another capture file. 47 00:04:04,890 --> 00:04:11,370 It'll be the record of a process which we mentioned in one of the earlier lectures we talked about how 48 00:04:11,370 --> 00:04:13,650 you can make a switch act like a hub. 49 00:04:14,040 --> 00:04:19,170 We said that this can be done by sending a large number of IP addresses associated with a random mac 50 00:04:19,170 --> 00:04:21,320 address. 51 00:04:21,340 --> 00:04:25,630 This is the situation you see on the screen. 52 00:04:25,650 --> 00:04:32,670 Please note how quickly the packets were sent and how many hosts were apparently involved in the communication. 53 00:04:32,680 --> 00:04:37,320 Here we see only the x y and packets of the TZP protocol. 54 00:04:37,840 --> 00:04:43,810 There are no data in these packets so it's not an unusual thing. 55 00:04:43,840 --> 00:04:47,950 Please note that the windows size field value is set at 512. 56 00:04:48,490 --> 00:04:56,540 No operating system uses such a small TCAP initial window size the packet gives no reason to set the 57 00:04:56,540 --> 00:05:01,410 window size smaller than the default one because we haven't received any data yet. 58 00:05:02,580 --> 00:05:08,940 A situation where there is only Syn packets and the window size 5:12 seems readily suspicious. 59 00:05:09,810 --> 00:05:19,080 So really this is a signature of Mac off a program used for switch flooding. 60 00:05:19,140 --> 00:05:22,920 If you make recoloring rule for the window size value 512. 61 00:05:22,920 --> 00:05:25,520 This is the first part you should have in your filter. 62 00:05:27,870 --> 00:05:32,410 At this point we can get some false positives from time to time. 63 00:05:32,410 --> 00:05:35,290 Computers can inform you about such window sizes. 64 00:05:39,760 --> 00:05:41,800 We're halfway to solution. 65 00:05:42,070 --> 00:05:44,220 We should now move the coloring rule to the top 66 00:05:47,230 --> 00:05:47,790 so far. 67 00:05:47,800 --> 00:05:49,470 The rule works as it should. 68 00:05:50,750 --> 00:05:53,090 We'll add just one more detail to it. 69 00:05:53,090 --> 00:05:56,430 That should be a sin packet. 70 00:05:56,450 --> 00:06:00,860 This is the final rule which we would like to add to our existing coloring rules. 71 00:06:00,860 --> 00:06:06,110 Thus we have worked out the signature of backoff. 72 00:06:06,360 --> 00:06:11,910 If we manage to do this with one program used for automated attacks on operating systems and computer 73 00:06:11,910 --> 00:06:15,270 networks will probably manage with others as well. 74 00:06:18,650 --> 00:06:27,360 Let's try it out on another demonstration file will open the file named Nessus the file name suggests 75 00:06:27,360 --> 00:06:29,430 what we'll be looking for. 76 00:06:29,600 --> 00:06:36,790 Here we mostly want to get to know another wireshark functionality press control plus help to open the 77 00:06:36,790 --> 00:06:39,030 Find window. 78 00:06:39,270 --> 00:06:44,970 We can now search for something by display filters that is all rules that could be entered into the 79 00:06:44,970 --> 00:06:53,710 program by hexadecimal values are displayed in the lowest window of the program or by strings typing 80 00:06:53,710 --> 00:07:00,500 any string of characters these criteria will be used to search the packet's list. 81 00:07:00,520 --> 00:07:10,010 The details pain or the bytes pain. 82 00:07:10,070 --> 00:07:17,800 Let's see what happens if you type the expression Nessus. 83 00:07:17,980 --> 00:07:23,650 We found the program which as we mentioned in the previous lectures tries to be neither discrete nor 84 00:07:23,650 --> 00:07:29,950 stealthy Messis is a program that detects certain errors and vulnerabilities in the configuration of 85 00:07:29,950 --> 00:07:31,600 network services. 86 00:07:31,600 --> 00:07:33,790 The program probes remote services 87 00:07:36,430 --> 00:07:40,710 in packets simply Nessus we find program names. 88 00:07:40,860 --> 00:07:46,260 We could create another color and rule or another filter that will show whether someone in the company 89 00:07:46,260 --> 00:07:47,250 uses Ness's.