Instructor: Dynamic analysis. 2 2
So up to this point, 3 3
we've talked about static analysis 4 4
and going through the code line by line 5 5
using our decompiler. 6 6
In this lesson, we are going to talk 7 7
about why you might want to do dynamic analysis instead. 8 8
Now when you do static analysis, 9 9
we're going to be looking through the disassembled code, 10 10
but that's far from perfect 11 11
because a lot of times, it's been changed and modified 12 12
so we can't see what's going on. 13 13
So when a malware writer takes their code 14 14
and tries to hide their intent, 15 15
stack analysis can be really difficult. 16 16
So what we might want to do instead is do a dynamic analysis. 17 17
Now, with a dynamic analysis, 18 18
this involves the execution of a compiled program 19 19
and then we're going to analyze the way it executes 20 20
and interacts with the host, the system, or the network. 21 21
By doing that, we can figure out how this thing works. 22 22
So if you think back to our different types of testing 23 23
with known environment test and unknown environment test, 24 24
dynamic analysis is more like 25 25
unknown environment test, right? 26 26
We're going to run it and see what comes out the other side, 27 27
what changes it makes. 28 28
With static analysis, we're trying to essentially 29 29
do a known environment test, right? 30 30
We're trying to get to something that looks like code 31 31
so we can analyze all the moving pieces inside of it. 32 32
Now, when you're doing dynamic analysis, 33 33
there are a couple of different tools you're going to use. 34 34
You might use a debugger, a stress test application, 35 35
a fuzzing application, and we're going to talk about 36 36
each of these three in this lesson. 37 37
Now, when we talk about a debugger, 38 38
this is a dynamic testing tool 39 39
that's used to analyze software as it's being executed. 40 40
Now essentially what the debugger allows you to do 41 41
is step through the program instruction by instruction. 42 42
If you looked in IDA, we had that pseudo code. 43 43
There was 50 lines of code there. 44 44
Now in a real program 45 45
there might be 50, 500, or even 5,000 lines. 46 46
With the debugger, I can go and run one line at a time 47 47
through that code or one instruction at a time 48 48
based on the assembly code that that binary has. 49 49
Now, I can stop it at any point and then start looking at it 50 50
and that's what a debugger allows us to do. 51 51
The debugger is going to allow us to pause the execution 52 52
and monitor or adjust the value of variables 53 53
at different stages through its execution. 54 54
Again, this allows us to control a little bit 55 55
what's inside that black box 56 56
so we can see what comes out the other side 57 57
and then we might be able to figure out 58 58
how it actually works. 59 59
Now when you use a debugger, it looks something like this. 60 60
In this example, you can see a breakpoint 61 61
that little stop sign was set at line 209. 62 62
This means the program will start running 63 63
and when it gets to line 209, it's going to stop. 64 64
Now once it stops there and pauses, 65 65
at this point I can highlight that line 66 66
and I can look at the different values of the command 67 67
or the value of a particular variable. 68 68
In this case, it's letting me see what the value 69 69
of wcoef[1] is going to be in this case minus 0.72. 70 70
Now, does that mean anything to us right now? 71 71
Not really, but if we were going through 72 72
and analyzing this program, it might be helpful 73 73
to know what all those things are. 74 74
Now debuggers are legitimately used by programmers 75 75
to find errors in their code 76 76
and then identify how to fix them, 77 77
but as a malware analyst, we can use them too. 78 78
Now, we're not the only ones who use 'em, though. 79 79
Some attackers and reverse engineers 80 80
can use debuggers as well to step through a binary 81 81
and determine how to best exploit any weakness 82 82
or vulnerability in it. 83 83
This is used by both sides, defense and attack 84 84
and so it's really something that's useful 85 85
for you to understand if you happen to be a programmer 86 86
and you're working as a reverse malware engineer. 87 87
Now the next time we're going to talk about 88 88
is known as a stress test. 89 89
Now a stress test is a software testing method 90 90
that evaluates how software performs under extreme load. 91 91
Now that extreme load can come as lots of different things. 92 92
It might be extreme processor load, 93 93
extreme memory load, extreme network load. 94 94
That's up to you 95 95
and what you're trying to stress inside your test. 96 96
Now a stress test can be used to determine 97 97
what could trigger a denial of service. 98 98
So a lot of times we'll stress test our own applications 99 99
and our own networks because for instance 100 100
when I'm setting up my new website 101 101
and I'm going to have all my students come onto it, 102 102
I want to know how many students can I take 103 103
before the site crashes. 104 104
Well, I can run a stress test against it 105 105
and when we've done this, 106 106
we figured out that we can support 107 107
10,000 students simultaneously 108 108
or a hundred thousand students simultaneously 109 109
or 10 students simultaneously. 110 110
We have to know what that number is 111 111
so we can actually sell the right number of students 112 112
without giving you bad quality of service 113 113
and that's what a stress test allows you to do. 114 114
Now as a cybersecurity analyst, you might do a stress test 115 115
of your systems to see what would make them fall down, 116 116
what would make them have a denial of service 117 117
and so you can use a program 118 118
like this web application stress. 119 119
You can run this program against your server 120 120
and it will run a bunch of different scripts against it 121 121
and that way it'll be able to figure out 122 122
what would cause that denial of service for you. 123 123
Again, this might be resource exhaustion. 124 124
It could be something like you're using up 125 125
all the processor, all the memory, all the disk space, 126 126
all the network bandwidth, whatever the limitation is, 127 127
you can find it by doing a stress test 128 128
and so often when you're deploying a new network 129 129
or a new web application, 130 130
you would be asked as a cybersecurity analyst 131 131
to test that system 132 132
by putting it through some stress testing. 133 133
The next area we're going to talk about is fuzzing. 134 134
Now, fuzzing is a dynamic code analysis technique 135 135
that involves sending a running application, 136 136
random and unusual input 137 137
to evaluate how the application responds. 138 138
Now let me give you a simple example 139 139
of how fuzzing is used to see if it can crash something. 140 140
For example, on my website we have a checkout page 141 141
and you're going to enter your credit card. 142 142
Now we expect what to be entered there? 143 143
Your credit card, right? 144 144
It should be 16 digits. 145 145
What if you start adding in things 146 146
like special characters or letters? 147 147
Will that crash our system? 148 148
Well, if we do a fuzz test, 149 149
we're going to send some of those random things in there 150 150
to see if we can crash it 151 151
and then we can find out 152 152
have we done proper input validation 153 153
to prevent this from crashing? 154 154
That's what fuzzing does, it test your input validation 155 155
and your other systems to make sure 156 156
you have the right protections in place. 157 157
Now, fuzzing is a technique 158 158
that's designed to test your software for various bugs 159 159
and vulnerabilities. 160 160
Like I said, I can test your application 161 161
and see if it's going to crash 162 162
when you send it some kind of wacky input. 163 163
That's what fuzzing is all about. 164 164
Now, when you use a fuzzer, 165 165
there are three different ways to inject 166 166
that manipulate input into your application. 167 167
You can use the application user interface 168 168
which identifies input streams 169 169
that are accepted by the application, 170 170
such as an input box or a form or a command line switch 171 171
and then send information that way. 172 172
Another way you can do it is by using the protocol 173 173
and you can transmit the manipulated packets 174 174
into the application. 175 175
For instance, maybe you're used to accepting things 176 176
over the web so I can go ahead and modify the headers 177 177
or the payloads and see if that'll crash you. 178 178
And then the third way is to use a different file format. 179 179
Now when you're doing a file format, 180 180
we're going to try to open some kind of file 181 181
but we're going to manipulate that file. 182 182
So you might think that you're uploading a PNG file 183 183
and when I actually send it to you, it's labeled as a PNG 184 184
but it might be an executable 185 185
and we'll see if it causes issues with your system. 186 186
Now, fuzzers may craft the input using semi-random input 187 187
or specific inputs. 188 188
If we use semi random input, 189 189
we call this a dumb fuzzer. 190 190
If we use specific inputs on the other hand, 191 191
we're using things based on what we know works 192 192
based on other exploit vectors 193 193
or certain vulnerabilities 194 194
that we're trying to target specifically. 195 195
We're not just using anything that's random in that case. 196 196
Now, one of the examples of a fuzzer 197 197
is what's known as Peach Fuzzer. 198 198
The Peach Fuzzer platform is one 199 199
of the most advanced commercial fuzzers out there. 200 200
It is used by a lot of people in the industry. 201 201
Now if you want to play with it, 202 202
there's also a free community version, 203 203
like a lot of the tools we've talked about. 204 204
There's the commercial side that makes the money 205 205
and then they have these free tools 206 206
for us to use as we're learning 207 207
and protecting our own home-based networks. 208 208
Now as you go and use something like this, 209 209
you can use it against your own systems. 210 210
Don't take this 211 211
and target other people's websites without their permission. 212 212
That's hacking. 213 213
That can land you in jail. 214 214
Instead, you can target your own websites 215 215
or sites you've placed in your lab. 216 216
Now this platform has a lot of built-in test cases. 217 217
Now test cases are these different preconfigured things 218 218
that we're going to work against 219 219
different types of products and systems. 220 220
So we have some test cases that will go 221 221
against network appliances. 222 222
We have test cases that go against web applications. 223 223
We have test cases that go against financial data, 224 224
test cases that go against healthcare 225 225
and we can use these to test these different applications 226 226
and they have different data sets 227 227
that we would expect to use 228 228
and different things that we would expect to cause issues.