Instructor: Consumption. 2 2
In the last lesson, 3 3
we looked at how you can do a basic memory analysis 4 4
to look at different processes and the memory usage. 5 5
Now, this is actually a big task, 6 6
especially if you're trying to do it in real time 7 7
looking for signs of malicious code or malicious behavior, 8 8
so you need to be able to find different ways to identify 9 9
where you should focus your efforts. 10 10
And one of those is by looking at consumption. 11 11
Resource consumption is a key indicator 12 12
of malicious activity, 13 13
but you have to be careful here 14 14
because just because something is using a lot of resources 15 15
doesn't make it malicious. 16 16
A lot of times, 17 17
this will occur with legitimate software too. 18 18
As I'm recording this video right now, 19 19
my video recording software is using up a lot of resources. 20 20
It's being very heavy on the processor and the memory. 21 21
But it's not malicious. 22 22
It's doing what I told it to do. 23 23
So you have to keep that in mind 24 24
as you're looking for legitimate activity 25 25
versus malicious activity. 26 26
Now, some of the things you can look at 27 27
when you're measuring resources 28 28
are things like your processor usage. 29 29
Now, your process usage is the percentage of CPU time 30 30
utilized on a per-process level. 31 31
Now, in addition to this, 32 32
you might look at your memory consumption. 33 33
This is the amount of memory that's utilized 34 34
on a per-process level. 35 35
Again, we don't want to look at just an application, 36 36
but on a single process 37 37
because this allows us to identify 38 38
if a single process has become victim 39 39
of some kind of malicious activity. 40 40
Now, to understand this, 41 41
you have to first look at your baseline 42 42
or your normal usage, 43 43
just like we talked about before. 44 44
If you understand what normal looks like for a process, 45 45
then you can compare it against what you're observing now. 46 46
And based on that, 47 47
that would help you determine if it's suspicious. 48 48
For example, right now my process that's recording this 49 49
is using about 50% of a processor. 50 50
Now, is that normal or is that suspicious? 51 51
Well, I know that normally when I record a video 52 52
it uses about 50%. 53 53
If that jumped up to 75, that would be suspicious. 54 54
So an understanding what normal is 55 55
and what deviates from baseline 56 56
really does help you identify what's suspicious 57 57
and should be looked at further. 58 58
Now, on a Windows system, you can look at this information 59 59
by going into your Task Manager. 60 60
Here on the screen, 61 61
you can see all the different apps that are running, 62 62
the amount of CPU being used, 63 63
and the memory being used, 64 64
and that way you can identify what is normal and what isn't. 65 65
If you click on one of those columns, 66 66
right now we are sorting it by name, 67 67
but we could click on CPU or memory 68 68
and see which ones are the biggest offenders. 69 69
As I look down the column for memory right now, 70 70
I see one of the biggest offenders is actually Vivaldi, 71 71
which is a 32 bit program, 72 72
and it has six processes running underneath it. 73 73
Now, as I look at it as a per-process level, 74 74
I see the first one is 1.3 megabytes, 75 75
the second one is 15.2 megabytes, 76 76
and the third one is 155.6 megabytes. 77 77
So if I was looking at one that might be suspicious, 78 78
the first one I would look at is that third one, 79 79
that 155.6 megabytes, 80 80
because it is so much larger than the other two processes. 81 81
Now, does that mean automatically it's malicious? 82 82
No, of course not, 83 83
but it is the one that I would look at first. 84 84
So while it's really easy to use Task Manager 85 85
inside of Windows, 86 86
we have to have tools that we can use for Linux servers too 87 87
because you will do some instant responses there. 88 88
Now, there are two main tools that we're going to use for that. 89 89
The first one is known as free. 90 90
Free is a command that outputs a summary 91 91
of the available used and freely available memory 92 92
on a computer. 93 93
Essentially, how much memory do you have 94 94
and how much is available? 95 95
To run the command free, 96 96
just type in free and hit Enter, 97 97
and you'll get a screen that looks like this. 98 98
Here, you can see the amount of total memory 99 99
and the amount that's used 100 100
both for the physical memory and the swap file. 101 101
Now, in addition to this, you can use the top command. 102 102
The top command works a lot like Task Manager. 103 103
Top is a command that creates a scrollable table 104 104
of every running process 105 105
and is constantly refreshed 106 106
so that you could see the most up-to-date statistics. 107 107
I really like the top command 108 108
because it's a really easy way to look at everything. 109 109
So as I look at the top command, 110 110
up at the top I get a lot of the same information 111 111
that I had from free. 112 112
I have the amount of memory, the total and the free memory. 113 113
I see how much was used and how much is in buffer. 114 114
If I go down to the bottom, 115 115
I can see this list of processes listed by PID. 116 116
Now, as I'm looking at it from PID, 117 117
I get that for the first column, 118 118
I then see the user that launched it. 119 119
For PID 1, which is our system daemon, 120 120
we have the root, which is the one who launched that. 121 121
As you go across to the right, 122 122
you'll see columns for the CPU percentage 123 123
and the memory percentage 124 124
and the time it's been online, 125 125
and then what command was being used. 126 126
All of these are commands that are used, 127 127
and a lot of them look just like we had 128 128
inside the Task Manager inside of Windows. 129 129
Now, in addition to top, 130 130
there's actually a newer version known as htop. 131 131
Now, the htop utility is going to provide 132 132
similar functionality plus mouse support, 133 133
and it contains a more easy to read output 134 134
when it's run in the default configuration. 135 135
So if I look at this, 136 136
you get something that looks like this. 137 137
First of all, you'll notice 138 138
there is more of a graphical display to this 139 139
with some coloring instead of just being black and white. 140 140
Additionally, I have this little graph 141 141
in the top left corner showing memory and CPU usage. 142 142
Also, on the right side, 143 143
I could see the average load and the amount of uptime 144 144
and how many tasks we have total and how many are running. 145 145
Here, we can also see our PID on the left, we get our user, 146 146
and as we move to the right, we see our CPU and our memory. 147 147
This one has actually been sorted 148 148
with the highest memory on top, 149 149
which in this case is actually htop. 150 150
Now, the nice thing about htop 151 151
is it's very easy to sort by different columns. 152 152
You'll notice here we have F6 which is the sort by function. 153 153
As we hit F6, 154 154
we can choose whether we want to sort by PID, CPU, or memory. 155 155
For instance, if I wanted to see which process 156 156
is using the most memory, 157 157
I can do that by sorting by memory. 158 158
And if I did that, 159 159
right now I'm just looking down the column, 160 160
I can see that bash, 161 161
the last process there on the list at 3645, 162 162
would be the highest 163 163
because it's using 2.3% of the total memory. 164 164
Now, why is looking at memory important? 165 165
Well, because it could indicate that you have memory issues, 166 166
whether these are memory leaks or memory overflows. 167 167
When we deal with a memory overflow, 168 168
this is a means of exploiting a vulnerability 169 169
inside an application to execute arbitrary code 170 170
or to crash the process, 171 171
or an ongoing memory leak 172 172
will be used to crash the entire system. 173 173
Now, if you suspect you may have a memory overflow issue, 174 174
what can you do to test that? 175 175
Well, you can take the code for that program 176 176
and run it inside a sandbox debugging environment. 177 177
This will allow you to find the process 178 178
that might be exploiting a buffer overflow condition. 179 179
By doing this, you can end up figuring is that code good 180 180
or is that code malicious? 181 181
Now, by putting it in the sandbox, 182 182
you can start observing its behavior 183 183
and trying to identify a signature. 184 184
Once you find a signature, 185 185
you as an analyst can now identify 186 186
any of these buffer overflow attacks 187 187
by the signature created by that particular exploit code. 188 188
Now, what do I mean by a signature? 189 189
Well, this is a way of doing business for that exploit code. 190 190
One of the most common things 191 191
that we see with buffer overflows 192 192
is they use what's called a NOP sled. 193 193
Now, a NOP sled works like this. 194 194
Here is a graphical depiction of my memory. 195 195
Up to the top, I have the shell code, 196 196
and as I go down the stack, 197 197
you'll see things called NOP or NOP. 198 198
NOP is essentially a command 199 199
that tells the computer to do nothing, 200 200
just move to the next memory location 201 201
and keep executing the program. 202 202
Essentially, it's like blank space. 203 203
So for example, if I started out on the first green NOP, 204 204
I'm going to execute NOP, 205 205
which says do nothing, move to the next spot. 206 206
That moves me to the next NOP, 207 207
do nothing, move to the next spot. 208 208
That says relative jump, 209 209
which means I'm going to take that 210 210
and jump down to the next link that I was supposed to go to, 211 211
which in this case is another NOP. 212 212
Once I reach that NOP, 213 213
I'm going to go through all four of those NOPs. 214 214
This would be called a NOP sled 215 215
because I'm essentially skiing across, 216 216
going down the hill of those four NOPs. 217 217
As I keep doing that, I go through all of them, 218 218
and I get down to the final line, 219 219
which is NOP, NOP, and then relative jump. 220 220
Once I get to that relative jump, 221 221
I'm going to jump up to where I'm told, 222 222
which in this case is the shell code. 223 223
That shell code has my exploit, 224 224
which means I now can run the exploit. 225 225
This is essentially how a buffer overflow attack works. 226 226
We try to overflow the buffer, 227 227
write in a bunch of these NOPs, 228 228
and then a relative jump into a location 229 229
that we know our shell code is. 230 230
And by doing this, 231 231
we can randomly guess whenever a program 232 232
tries to execute something, 233 233
it might land on one of these NOPs, 234 234
slide down into a relative jump, 235 235
and then push us up to the shell code. 236 236
So why would an attacker try to do a memory overflow 237 237
or a memory consumption 238 238
or a memory leak or a processor consumption? 239 239
Well, they do this to create a denial of service condition. 240 240
Now, I know we've mentioned denial of services before, 241 241
but again, as a review, 242 242
I want you to remember that a denial of service 243 243
is an attack meant to shut down a machine or a network 244 244
that makes it inaccessible for its intended purpose. 245 245
So if I start using a computer 246 246
and I start taking up a lot of its resources, 247 247
that can make it so it doesn't have resources 248 248
for other things it needs to do. 249 249
This is a denial of service condition. 250 250
So one type of denial of service attack method 251 251
is to cause an application to overrun its memory buffer 252 252
to trigger an execution failure. 253 253
This can lead to a program crash or even a system crash. 254 254
And if that happens, 255 255
you have now conducted a denial of service against it.