1 1 00:00:00,810 --> 00:00:04,290 Irregular peer-to-peer communications. 2 2 00:00:04,290 --> 00:00:06,630 Now, on most networks, the predominant type 3 3 00:00:06,630 --> 00:00:08,970 of user traffic goes from a client 4 4 00:00:08,970 --> 00:00:11,670 to a server within most of our networks. 5 5 00:00:11,670 --> 00:00:14,400 So if you start seeing a lot of peer-to-peer communications, 6 6 00:00:14,400 --> 00:00:16,170 this could be an indicator of compromise 7 7 00:00:16,170 --> 00:00:18,030 that you should look into further. 8 8 00:00:18,030 --> 00:00:18,863 Now, when we talk 9 9 00:00:18,863 --> 00:00:22,080 about irregular peer-to-peer or P2P communication, 10 10 00:00:22,080 --> 00:00:24,450 we're really talking about an attack indicator where hosts 11 11 00:00:24,450 --> 00:00:26,370 within a network establish connections 12 12 00:00:26,370 --> 00:00:29,520 over unauthorized ports or data transfers. 13 13 00:00:29,520 --> 00:00:30,600 One of the most common ways 14 14 00:00:30,600 --> 00:00:33,000 that this is done is by using SMB. 15 15 00:00:33,000 --> 00:00:35,940 This is the server message block, and this is typically used 16 16 00:00:35,940 --> 00:00:38,430 within Windows networks to provide Windows file 17 17 00:00:38,430 --> 00:00:39,510 and printer sharing. 18 18 00:00:39,510 --> 00:00:40,560 As we go through this lesson, 19 19 00:00:40,560 --> 00:00:42,870 I'm going to show you two examples of SMB, 20 20 00:00:42,870 --> 00:00:44,760 one of which is normal and authorized, 21 21 00:00:44,760 --> 00:00:46,260 and one of which, which is irregular 22 22 00:00:46,260 --> 00:00:48,240 and an indicator of compromise. 23 23 00:00:48,240 --> 00:00:49,110 Now, as we do that, 24 24 00:00:49,110 --> 00:00:51,330 we are going to consider this network. 25 25 00:00:51,330 --> 00:00:55,440 Notice, we have the server, which is 10.1.0.1 26 26 00:00:55,440 --> 00:01:00,360 and we have a client nominally written as 10.1.0.133. 27 27 00:01:00,360 --> 00:01:03,120 Now, here inside the Wireshark packet capture, 28 28 00:01:03,120 --> 00:01:05,520 we can see that there is communication going 29 29 00:01:05,520 --> 00:01:08,700 from the source of 10.1.0.1 30 30 00:01:08,700 --> 00:01:12,360 to the destination of 10.1.0.133. 31 31 00:01:12,360 --> 00:01:14,850 This is going from the server to the client. 32 32 00:01:14,850 --> 00:01:17,580 Now, you should notice that the protocol is SPOOLSS, 33 33 00:01:17,580 --> 00:01:19,500 which is a printer spool protocol. 34 34 00:01:19,500 --> 00:01:22,830 You'll also notice that it's using GetPrinter response. 35 35 00:01:22,830 --> 00:01:23,663 As it goes through 36 36 00:01:23,663 --> 00:01:25,290 and you look through these different lines, 37 37 00:01:25,290 --> 00:01:28,080 you can see this is normal traffic. 38 38 00:01:28,080 --> 00:01:29,880 This traffic is what would be generated 39 39 00:01:29,880 --> 00:01:34,440 when the client, .133, is connecting to the server, .1, 40 40 00:01:34,440 --> 00:01:37,290 to be able to access a known file or print server. 41 41 00:01:37,290 --> 00:01:39,120 As we continue looking through these logs, 42 42 00:01:39,120 --> 00:01:43,468 you'll then see that from the source, the server 10.1.0.1, 43 43 00:01:43,468 --> 00:01:48,468 we are sending information to the client, 10.1.0.133. 44 44 00:01:48,600 --> 00:01:50,520 This is a TCP segment 45 45 00:01:50,520 --> 00:01:53,940 and it begins sending some kind of file. 46 46 00:01:53,940 --> 00:01:56,310 Now, this file contains MZ, which is one 47 47 00:01:56,310 --> 00:01:57,450 of our magic signatures 48 48 00:01:57,450 --> 00:01:59,520 that we talked about back in forensics. 49 49 00:01:59,520 --> 00:02:01,320 What does MZ tell us? 50 50 00:02:01,320 --> 00:02:03,870 Well, this tells us it's a Windows executable, 51 51 00:02:03,870 --> 00:02:06,750 and in this particular case, it's actually a Windows driver 52 52 00:02:06,750 --> 00:02:10,140 that's being downloaded from the server to the client. 53 53 00:02:10,140 --> 00:02:12,270 Again, this is normal behavior. 54 54 00:02:12,270 --> 00:02:14,070 When you connect to a new print server, 55 55 00:02:14,070 --> 00:02:16,470 if you don't have the drivers, Windows will send it to you 56 56 00:02:16,470 --> 00:02:19,890 as a client and that way you can access that printer. 57 57 00:02:19,890 --> 00:02:21,480 As you can see going back and forth, 58 58 00:02:21,480 --> 00:02:24,270 all those purple highlights are part of this one stream, 59 59 00:02:24,270 --> 00:02:27,000 which is that particular driver download. 60 60 00:02:27,000 --> 00:02:30,180 As I said, this is normal network traffic. 61 61 00:02:30,180 --> 00:02:31,380 Now, let's take a look at something 62 62 00:02:31,380 --> 00:02:33,270 that might be a little more suspicious. 63 63 00:02:33,270 --> 00:02:34,860 Going back to our network diagram, 64 64 00:02:34,860 --> 00:02:38,010 notice I still have my server, 10.1.0.1. 65 65 00:02:38,010 --> 00:02:41,040 I have my client, 10.1.0.133, 66 66 00:02:41,040 --> 00:02:44,790 and I have another client, 10.1.0.248. 67 67 00:02:44,790 --> 00:02:46,950 And what's going to make this suspicious is instead 68 68 00:02:46,950 --> 00:02:49,530 of having communication going from the server to the client, 69 69 00:02:49,530 --> 00:02:52,620 we are going to have communication between the two clients. 70 70 00:02:52,620 --> 00:02:55,830 On an organizational network, there's almost never a case 71 71 00:02:55,830 --> 00:02:58,020 where two clients need to talk to each other directly. 72 72 00:02:58,020 --> 00:02:59,340 Almost everything is going to go through 73 73 00:02:59,340 --> 00:03:00,450 a centralized server 74 74 00:03:00,450 --> 00:03:02,820 in a centralized organizational network. 75 75 00:03:02,820 --> 00:03:05,430 So let's jump back into Wireshark and take a look 76 76 00:03:05,430 --> 00:03:07,110 at what the suspicious communication 77 77 00:03:07,110 --> 00:03:09,270 between these two devices looks like. 78 78 00:03:09,270 --> 00:03:13,170 Now, again, here is communication happening between two PCs. 79 79 00:03:13,170 --> 00:03:15,360 Notice, all of our IP addresses here are going 80 80 00:03:15,360 --> 00:03:20,360 between two clients, 10.1.0.249, and 10.1.0.133. 81 81 00:03:21,870 --> 00:03:23,610 This communication between two clients 82 82 00:03:23,610 --> 00:03:26,400 is something that is suspicious and we want to look into. 83 83 00:03:26,400 --> 00:03:28,320 So as I go through this packet capture, 84 84 00:03:28,320 --> 00:03:30,780 the first thing I notice here is this line 85 85 00:03:30,780 --> 00:03:32,400 that is the fifth line down. 86 86 00:03:32,400 --> 00:03:37,080 It says, going from the source of 10.1.0.249, 87 87 00:03:37,080 --> 00:03:42,080 the new client we just added, to destination 10.1.0.133, 88 88 00:03:42,300 --> 00:03:44,550 the old client from the previous example. 89 89 00:03:44,550 --> 00:03:46,290 We have a message being sent 90 90 00:03:46,290 --> 00:03:49,380 that has NetPathCanonicalization request. 91 91 00:03:49,380 --> 00:03:50,910 Now, what is this? 92 92 00:03:50,910 --> 00:03:52,980 This is essentially a packet that goes out 93 93 00:03:52,980 --> 00:03:57,030 as part of SMB and it tries to take the network path 94 94 00:03:57,030 --> 00:03:59,730 using the name and figure out what IP address 95 95 00:03:59,730 --> 00:04:02,160 or what client it is on the local network. 96 96 00:04:02,160 --> 00:04:03,390 So essentially, this is the beginning 97 97 00:04:03,390 --> 00:04:05,940 of some sort of file sharing that's going on. 98 98 00:04:05,940 --> 00:04:07,440 Now, you won't know this 99 99 00:04:07,440 --> 00:04:11,700 but this particular packet is actually indicative of a worm. 100 100 00:04:11,700 --> 00:04:16,110 In fact, the Conficker worm back in 2008 used this heavily. 101 101 00:04:16,110 --> 00:04:18,600 If you go back and actually learn about the Conficker worm, 102 102 00:04:18,600 --> 00:04:21,540 you'll learn that the NetPathCanonicalization function 103 103 00:04:21,540 --> 00:04:24,510 was one of the things that was used as an attack vector. 104 104 00:04:24,510 --> 00:04:28,470 And this actually was covered by Microsoft 08-067. 105 105 00:04:28,470 --> 00:04:30,840 So our newer systems aren't vulnerable to this attack 106 106 00:04:30,840 --> 00:04:32,700 but our older systems were. 107 107 00:04:32,700 --> 00:04:34,800 Now, for the CYSA+ exam, 108 108 00:04:34,800 --> 00:04:36,570 you don't need to know Conficker in detail 109 109 00:04:36,570 --> 00:04:39,180 and you wouldn't be asked this particular packat capture 110 110 00:04:39,180 --> 00:04:40,950 to identify what was wrong. 111 111 00:04:40,950 --> 00:04:42,120 But I'm just trying to show you the point 112 112 00:04:42,120 --> 00:04:44,010 of how this works in the real world. 113 113 00:04:44,010 --> 00:04:45,720 As you go through that packet capturing, 114 114 00:04:45,720 --> 00:04:47,490 you notice something that looks a little odd, 115 115 00:04:47,490 --> 00:04:49,830 like NetPathCanonicalization request. 116 116 00:04:49,830 --> 00:04:51,750 You can look that up and then see if other people 117 117 00:04:51,750 --> 00:04:52,890 have noticed that too. 118 118 00:04:52,890 --> 00:04:55,260 And if you Google that, you would find pretty quickly 119 119 00:04:55,260 --> 00:04:57,930 that Conficker ties to that as a signature. 120 120 00:04:57,930 --> 00:05:00,030 So let's go back to our packet capture. 121 121 00:05:00,030 --> 00:05:03,330 Again, there's our NetPathCanonicalization request. 122 122 00:05:03,330 --> 00:05:05,010 After we have that initial request, 123 123 00:05:05,010 --> 00:05:07,350 we're going to see a three-way handshake occur. 124 124 00:05:07,350 --> 00:05:12,210 So .249 sends out a SYN packet to .133. 125 125 00:05:12,210 --> 00:05:15,480 That client, .133, responds back with a SYN/ACK, 126 126 00:05:15,480 --> 00:05:18,690 and then .249 is going to send back the acknowledgement. 127 127 00:05:18,690 --> 00:05:20,610 So we now have that three-way handshake. 128 128 00:05:20,610 --> 00:05:23,730 We now have a TCP connection between these two clients. 129 129 00:05:23,730 --> 00:05:25,729 Again, something that would be a little suspicious 130 130 00:05:25,729 --> 00:05:27,690 in most corporate networks. 131 131 00:05:27,690 --> 00:05:31,440 After that, we see the client at .249 sending data over 132 132 00:05:31,440 --> 00:05:33,600 to the client at .133. 133 133 00:05:33,600 --> 00:05:35,640 And in this case, it's pushing a lot of data 134 134 00:05:35,640 --> 00:05:37,110 and we put that all together, 135 135 00:05:37,110 --> 00:05:40,410 that actually comes together as a binary file. 136 136 00:05:40,410 --> 00:05:41,940 How do I know it's a binary file? 137 137 00:05:41,940 --> 00:05:44,100 Again, I've highlighted the one line there. 138 138 00:05:44,100 --> 00:05:45,240 And when you look inside, 139 139 00:05:45,240 --> 00:05:48,810 you see those two special characters, MZ. 140 140 00:05:48,810 --> 00:05:50,910 MZ again is that magic signature saying 141 141 00:05:50,910 --> 00:05:53,010 this is a Windows binary. 142 142 00:05:53,010 --> 00:05:55,170 So what made this all unusual? 143 143 00:05:55,170 --> 00:05:57,240 Well, it was two clients talking to each each other, 144 144 00:05:57,240 --> 00:05:58,530 and then one client sending 145 145 00:05:58,530 --> 00:06:00,360 the other one direct information. 146 146 00:06:00,360 --> 00:06:02,940 And that information was a binary. 147 147 00:06:02,940 --> 00:06:04,830 So do I know this was malware? 148 148 00:06:04,830 --> 00:06:08,910 Not necessarily, but if I have a packet capture like this, 149 149 00:06:08,910 --> 00:06:11,610 I can actually extract that packet capture 150 150 00:06:11,610 --> 00:06:13,170 and get that binary file. 151 151 00:06:13,170 --> 00:06:15,300 Then I could go do some reverse analysis on it 152 152 00:06:15,300 --> 00:06:18,000 and determine if it was malicious, if it was malware 153 153 00:06:18,000 --> 00:06:20,280 and what that thing was particularly doing. 154 154 00:06:20,280 --> 00:06:21,990 That's the idea of how you would attack this 155 155 00:06:21,990 --> 00:06:24,810 in the real world as a cyber security analyst. 156 156 00:06:24,810 --> 00:06:25,650 Now, the last type 157 157 00:06:25,650 --> 00:06:27,570 of irregular peer-to-peer communications we need 158 158 00:06:27,570 --> 00:06:30,780 to talk about is what happens on the local area network. 159 159 00:06:30,780 --> 00:06:32,490 Now, when you're dealing with IP addresses, 160 160 00:06:32,490 --> 00:06:34,710 that happens on the local network, but it also happens 161 161 00:06:34,710 --> 00:06:37,050 across the internet because that's layer three. 162 162 00:06:37,050 --> 00:06:38,850 If we start talking at layer two though, 163 163 00:06:38,850 --> 00:06:40,470 we're going to be dealing with MAC addresses. 164 164 00:06:40,470 --> 00:06:44,010 And so how can you spoof or poison MAC addresses? 165 165 00:06:44,010 --> 00:06:46,620 Well, if you're dealing with ARP spoofing or ARP poisoning, 166 166 00:06:46,620 --> 00:06:49,620 this can occur when an attacker redirects an IP address 167 167 00:06:49,620 --> 00:06:53,340 to a MAC address that was not intended as its destination. 168 168 00:06:53,340 --> 00:06:54,570 This can cause irregular 169 169 00:06:54,570 --> 00:06:57,000 peer-to-peer communications as well. 170 170 00:06:57,000 --> 00:06:58,890 Now, to catch this type of thing, 171 171 00:06:58,890 --> 00:07:01,260 you are going to use an IDS. 172 172 00:07:01,260 --> 00:07:03,030 By using an intrusion detection system, 173 173 00:07:03,030 --> 00:07:05,580 you can identify suspicious traffic patterns caused 174 174 00:07:05,580 --> 00:07:07,890 by ARP poisoning and this ARP poisoning 175 175 00:07:07,890 --> 00:07:10,020 is going to generate far more ARP traffic 176 176 00:07:10,020 --> 00:07:11,490 than you normally would see. 177 177 00:07:11,490 --> 00:07:12,323 Now, if you wanted to look 178 178 00:07:12,323 --> 00:07:13,800 at this individually on a machine, 179 179 00:07:13,800 --> 00:07:16,560 you can inspect that local machine's ARP cache as well 180 180 00:07:16,560 --> 00:07:18,630 and compare the MAC addresses to known values 181 181 00:07:18,630 --> 00:07:19,860 for server machines. 182 182 00:07:19,860 --> 00:07:22,440 To do this, you would use arp -a 183 183 00:07:22,440 --> 00:07:24,030 as you can see here on the screen. 184 184 00:07:24,030 --> 00:07:25,320 From your Windows command prompt, 185 185 00:07:25,320 --> 00:07:27,180 simply type in arp -a 186 186 00:07:27,180 --> 00:07:28,710 and you'll be able to see your interfaces. 187 187 00:07:28,710 --> 00:07:29,940 In this case, it's a server 188 188 00:07:29,940 --> 00:07:31,890 with three different interface cards, 189 189 00:07:31,890 --> 00:07:33,870 and all of the different physical addresses, 190 190 00:07:33,870 --> 00:07:35,542 those MAC addresses that are tied 191 191 00:07:35,542 --> 00:07:37,530 to the particular internet addresses 192 192 00:07:37,530 --> 00:07:39,720 these machines have talked to. 193 193 00:07:39,720 --> 00:07:41,730 Now, if I compare these physical addresses, 194 194 00:07:41,730 --> 00:07:44,610 these MAC addresses to the ones that I know are valid ones 195 195 00:07:44,610 --> 00:07:47,430 from my server environment, I can then know 196 196 00:07:47,430 --> 00:07:50,130 if there's ARP poisoning going on, or if I just 197 197 00:07:50,130 --> 00:07:53,130 have communications going across my network using layer two.