Instructor: Conduct packet analysis. 2 2
In this lesson I'm going to show you how to do 3 3
some basic packet analysis using Wireshark. 4 4
To do this, I'm going to launch a piece of malware on my system 5 5
and we're going to see how it beacons out over time. 6 6
Now to do this, I'm going to use two pieces of software. 7 7
I'm going to use Proc Man to look at the processes 8 8
and make sure the malware's actually launching. 9 9
And then I'm really going to dig into the packet analysis 10 10
using Wireshark so we can look at how those packets 11 11
are going out, to what IPS they are, 12 12
so we could develop indicators of compromise. 13 13
Let's go ahead and jump into the environment. 14 14
And next I want to open up Wireshark. 15 15
So I'm going to click on the Windows icon 16 16
and type in the word Wireshark and open that program. 17 17
Now Wireshark is a great program. 18 18
It's one that is used heavily in network analysis 19 19
and what we're going to use it for 20 20
is to capture our network traffic 21 21
when the malware launches. 22 22
And that way we can see those beacons 23 23
that happen every three minutes 24 24
and see what data is being sent 25 25
or see who it's calling out to. 26 26
And so I'm going to go ahead and hit the start button 27 27
which is this little shark fin 28 28
and it's going to start capturing data 29 29
going into or out of our network. 30 30
So now I'm going to go ahead and right click on Trickster 31 31
and run it as administrator and go ahead and hit yes. 32 32
So now Trickster is running. 33 33
This should be copying u.exe 34 34
into that directory and running it. 35 35
And I did and you can see 36 36
that it's now showing up as a process. 37 37
So I'm going to go ahead and move this over 38 38
just a tad so we can see it. 39 39
And we're going to go ahead and open up Wireshark 40 40
a little bit better so we can see it a little more. 41 41
Now notice the time is different. 42 42
On Wireshark, they do it as 43 43
a T plus whatever time is being used 44 44
whereas Process Mon is doing it as the time of day. 45 45
Now if I want to correlate these two 46 46
I need to make them look the same. 47 47
And so to do that I'm going to go over here to Wireshark 48 48
and I'm going to change the way the time is displayed 49 49
by going to view time, display format 50 50
and then choosing time of day. 51 51
This will allow us to correlate between the two. 52 52
So in the example here 53 53
we have the process starting at 1:43 and 29 seconds. 54 54
So I'm going to go ahead and let this run 55 55
just for a couple of minutes 56 56
and we're going to come back at 1:47. 57 57
When I come back, we are going to see what traffic 58 58
and if we can capture and see those three beacons 59 59
and see if we can figure out what IP addresses 60 60
they're calling out to from these processes. 61 61
Okay, we're going to go ahead and stop the capture here. 62 62
So now that we've stopped the capture, 63 63
let's go ahead and clear up this mess a little bit 64 64
so we can see a little bit clearer what we're dealing with. 65 65
Let's go ahead and first turn off 66 66
our registry activity changes 67 67
and our file system activity changes. 68 68
This is going to leave us 69 69
with just the network activity and just the processes. 70 70
Now the first process you can see here, 71 71
it started up at 1:43:29 72 72
and it finished right here at 1:43:29 73 73
and the next one starts at 1:44:28. 74 74
So let's see if we can find these events. 75 75
So as we start looking through this, 76 76
we see at 1:43 there was a Windows update call out 77 77
and then we saw this source going back to our machine 78 78
over port 443 that is most likely connected to that. 79 79
So we can skip that one. 80 80
We'll go ahead and keep going a little bit further. 81 81
And if we scroll down 82 82
we see 1:44:28 was the next process start. 83 83
So 1:44:28, 29, somewhere around there 84 84
would be what we're looking for. 85 85
And right here we see 1:44:29 86 86
and we had a standard query over DNS 87 87
for an API dot iPifive.org. 88 88
This callout is going from our machine 89 89
to the Google DNS server. 90 90
Once it finds out what that IP address is 91 91
it starts making that call out from our computer 92 92
over TCP over port 80 to this remote IP address. 93 93
So we're going to note that in our notes 94 94
that this is a possible issue for us. 95 95
This may be one of those IP addresses 96 96
and this IP (indistinct) might be part of our malware. 97 97
And so we'll keep looking as we go down. 98 98
So the next one we have 99 99
if we go down here on the right is 1:45. 100 100
It tries it again about a minute later. 101 101
Now this 1:45 timeframe, we're going to scroll down here 102 102
and see what we can see. 103 103
At 1:45:28, which will be right around here, 104 104
it again tries to make a connection 105 105
this time from 54.254.136.64 to our machine. 106 106
And from there we see 107 107
that it now makes this two-way connection 108 108
with an acknowledgement and finishing up that handshake. 109 109
So that is a communication between our machine 110 110
and our remote server that we're going to want to look into. 111 111
Now if we do this, we can go follow TCP stream 112 112
and see what was sent. 113 113
In this case, there's not much to it. 114 114
It's just a keep a live connection. 115 115
There was a standard request for basically a webpage 116 116
and to get an IP address back. 117 117
Now the reason why is this particular piece of malware 118 118
is a piece of training malware. 119 119
And so what we're seeing here is that 120 120
it's going to this website and saying, 121 121
"Hey, what's my IP address?" 122 122
This local IP address. 123 123
And that's the local IP address that you're finding here 124 124
from this machine during this session. 125 125
So as you can see, we can see those call outs 126 126
and we can start making a list of IP addresses it calls to. 127 127
If I left this running for a long period of time, 128 128
like 10 or 15 or 20 minutes, 129 129
you would see that it actually calls out 130 130
over several different IP addresses 131 131
as it tries to make its way to some command 132 132
and control server because maybe we are blocking this one 133 133
because we already knew it was bad 134 134
but it can then move to the next one. 135 135
That's the idea here, and what we're trying to figure out 136 136
is where these TCP connections are going to 137 137
so we can develop these indicators of compromise 138 138
and block them in our firewall. 139 139
So even if we are infected with this stage one dropper, 140 140
it can't go and get the stage two malware 141 141
and start installing it.