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