WEBVTT

1
00:00:00.080 --> 00:00:04.480
<v Speaker 1>You know, usually in cloud architecture, you're building a fortress.

2
00:00:04.639 --> 00:00:06.559
<v Speaker 1>You can figure your keys, you lock down all the

3
00:00:06.719 --> 00:00:09.560
<v Speaker 1>ingress rules, and the security engineer just kind of points

4
00:00:09.599 --> 00:00:12.480
<v Speaker 1>at the architecture and says, there it is impenetrable.

5
00:00:12.640 --> 00:00:14.880
<v Speaker 2>Right, that's the standard goal. You want to keep everyone

6
00:00:14.919 --> 00:00:15.839
<v Speaker 2>out exactly.

7
00:00:16.239 --> 00:00:19.719
<v Speaker 1>But today we are taking the exact opposite approach. We're

8
00:00:19.760 --> 00:00:22.480
<v Speaker 1>deliberately building a house of cards. We are looking at

9
00:00:22.519 --> 00:00:26.879
<v Speaker 1>excerpts from the book hands on AWS Penetration Testing with

10
00:00:27.000 --> 00:00:29.960
<v Speaker 1>Caulli Linux by Carl Gilbert Benjamin Caddle.

11
00:00:30.120 --> 00:00:32.799
<v Speaker 2>Yeah, and it's a really fascinating text because it flips

12
00:00:32.840 --> 00:00:33.320
<v Speaker 2>the script.

13
00:00:33.560 --> 00:00:36.719
<v Speaker 1>It really does. The mission for this deep dive is

14
00:00:36.759 --> 00:00:41.799
<v Speaker 1>to demystify how cybersecurity professionals practice their craft. We are

15
00:00:41.799 --> 00:00:44.479
<v Speaker 1>going to guide you through the exact blueprint for building

16
00:00:44.560 --> 00:00:49.119
<v Speaker 1>a personal quarantine hacking laboratory entirely in the Amazon Web

17
00:00:49.200 --> 00:00:50.000
<v Speaker 1>Services cloud.

18
00:00:50.159 --> 00:00:53.320
<v Speaker 2>Because you know, abstract theory only gets you so far, right, So.

19
00:00:53.280 --> 00:00:55.560
<v Speaker 1>Instead of learning how to build secure servers today, we

20
00:00:55.600 --> 00:01:00.000
<v Speaker 1>are intentionally building incredibly vulnerable ones. Okay, let's impact it.

21
00:01:00.640 --> 00:01:04.680
<v Speaker 1>Why why would anyone pay Amazon to host a server

22
00:01:05.159 --> 00:01:06.959
<v Speaker 1>that is basically begging to be hacked?

23
00:01:07.280 --> 00:01:11.239
<v Speaker 2>Well, because you can't meaningfully patch a vulnerability if you

24
00:01:11.239 --> 00:01:13.640
<v Speaker 2>have never watched it being exploited in real time.

25
00:01:13.799 --> 00:01:15.200
<v Speaker 1>Oh sure that makes sense.

26
00:01:15.439 --> 00:01:17.959
<v Speaker 2>Yeah, I mean to really understand the mechanics of an attack,

27
00:01:18.040 --> 00:01:22.079
<v Speaker 2>you need a controlled, completely isolated environment, somewhere you can

28
00:01:22.159 --> 00:01:26.079
<v Speaker 2>launch live exploits without the risk of bringing down your

29
00:01:26.079 --> 00:01:30.400
<v Speaker 2>company's actual production database. You need infrastructure that is meant

30
00:01:30.439 --> 00:01:31.680
<v Speaker 2>to be compromised, which.

31
00:01:31.599 --> 00:01:34.599
<v Speaker 1>Means before you can practice those exploits, you need something

32
00:01:34.640 --> 00:01:38.680
<v Speaker 1>to actually hack. You have to meticulously construct the crash

33
00:01:38.719 --> 00:01:40.680
<v Speaker 1>test dummies basically exactly.

34
00:01:41.159 --> 00:01:44.439
<v Speaker 2>And the blueprint we're following starts with provisioning two highly

35
00:01:44.519 --> 00:01:48.239
<v Speaker 2>vulnerable target machines. Right in AWS, we start with a

36
00:01:48.239 --> 00:01:52.599
<v Speaker 2>Linux machine specifically and one to sixteen point zero four.

37
00:01:52.719 --> 00:01:54.799
<v Speaker 1>Instance, which is pretty outdated, right.

38
00:01:54.760 --> 00:01:57.359
<v Speaker 2>Very outdated, and that gives us a fragile foundation. But

39
00:01:57.400 --> 00:02:00.599
<v Speaker 2>the real focal point is the application layer design calls

40
00:02:00.599 --> 00:02:04.040
<v Speaker 2>for downloading a specific heavily backdoored FTP server directly from

41
00:02:04.079 --> 00:02:09.159
<v Speaker 2>a gehabripo. It's called VSFTPD. Doatch two point three point

42
00:02:09.159 --> 00:02:10.919
<v Speaker 2>four infected dot get.

43
00:02:10.879 --> 00:02:13.879
<v Speaker 1>Man the two point three point four version of VSFTPD

44
00:02:14.080 --> 00:02:17.719
<v Speaker 1>that is like legendary and offensive security sort of absolutely

45
00:02:17.800 --> 00:02:20.280
<v Speaker 1>for anyone who hasn't encountered it. This is the infamous

46
00:02:20.360 --> 00:02:24.319
<v Speaker 1>smiley face backdoor from way back in twenty eleven. Basically,

47
00:02:24.680 --> 00:02:27.719
<v Speaker 1>if an attacker tries to log into the FTP server

48
00:02:27.879 --> 00:02:31.120
<v Speaker 1>and just adds a smiley face like a colon and

49
00:02:31.159 --> 00:02:34.360
<v Speaker 1>a parenthesis to the end of their username, the malicious

50
00:02:34.400 --> 00:02:36.039
<v Speaker 1>code intercepts that strength.

51
00:02:35.879 --> 00:02:38.919
<v Speaker 2>And it silently forks a root shell on port sixty

52
00:02:38.960 --> 00:02:39.479
<v Speaker 2>two hundred.

53
00:02:39.599 --> 00:02:42.960
<v Speaker 1>Yes, it is a literal wink to the attacker. It's crazy.

54
00:02:43.000 --> 00:02:45.960
<v Speaker 2>It is brilliantly simple. But getting that infected code to

55
00:02:45.960 --> 00:02:49.360
<v Speaker 2>actually run on our modern lab instance, that requires some

56
00:02:49.560 --> 00:02:51.520
<v Speaker 2>bizarre reverse engineering.

57
00:02:51.080 --> 00:02:53.360
<v Speaker 1>Because you aren't just downloading a package, right, You're building

58
00:02:53.400 --> 00:02:55.360
<v Speaker 1>this malware from the raw.

59
00:02:55.240 --> 00:02:58.039
<v Speaker 2>Source code, right, And the raw code for this specific

60
00:02:58.120 --> 00:03:00.800
<v Speaker 2>back door is actually, well, it's a bit. If you

61
00:03:00.879 --> 00:03:03.400
<v Speaker 2>just run the standard make command to compile it, the

62
00:03:03.439 --> 00:03:04.800
<v Speaker 2>compilation completely fails.

63
00:03:04.840 --> 00:03:06.759
<v Speaker 1>Yeah, you have to open the make file and manually

64
00:03:06.800 --> 00:03:10.199
<v Speaker 1>append a dollar crypt linker flag before compiling it.

65
00:03:10.319 --> 00:03:14.319
<v Speaker 2>What's fascinating here is the deliberate precision required to be insecure.

66
00:03:14.560 --> 00:03:18.039
<v Speaker 2>I love that phrase, right, because that doacwork flag. It

67
00:03:18.039 --> 00:03:21.719
<v Speaker 2>tells the compiler to link the operating system's cryptography libraries

68
00:03:22.120 --> 00:03:26.240
<v Speaker 2>into the FTP executable. The back door needs to intersect

69
00:03:26.280 --> 00:03:29.080
<v Speaker 2>the authentication process, which means it has to interface with

70
00:03:29.120 --> 00:03:31.360
<v Speaker 2>the system's password hashing mechanisms.

71
00:03:31.439 --> 00:03:33.479
<v Speaker 1>And without that flag, it just breaks.

72
00:03:33.360 --> 00:03:38.000
<v Speaker 2>Exactly Without it, the malware throws a segmentation FAULL and crashes.

73
00:03:38.439 --> 00:03:42.080
<v Speaker 2>So you're basically debugging the attacker's malware to ensure it

74
00:03:42.120 --> 00:03:44.159
<v Speaker 2>successfully compromises your own system.

75
00:03:44.639 --> 00:03:47.120
<v Speaker 1>That is so wild. It's like building a custom escape room,

76
00:03:47.159 --> 00:03:49.759
<v Speaker 1>but instead of trying to break out, you are intentionally

77
00:03:49.800 --> 00:03:51.960
<v Speaker 1>planting flaws so you can practice breaking in.

78
00:03:52.240 --> 00:03:53.520
<v Speaker 2>That's a perfect analogy.

79
00:03:53.599 --> 00:03:55.159
<v Speaker 1>And we don't stop there. The text says we have

80
00:03:55.199 --> 00:03:59.319
<v Speaker 1>to create a system user named nobody and a directory

81
00:03:59.400 --> 00:04:00.000
<v Speaker 1>named empty.

82
00:04:00.199 --> 00:04:04.199
<v Speaker 2>Right, you're carefully satisfying all the environmental prerequisites the damon expects,

83
00:04:04.639 --> 00:04:06.840
<v Speaker 2>just so the back door can run silently in the background.

84
00:04:06.919 --> 00:04:10.360
<v Speaker 1>Yeah. And then finally we edit the vsftpd dot com

85
00:04:10.520 --> 00:04:14.400
<v Speaker 1>file to explicitly enable local user logins.

86
00:04:14.120 --> 00:04:17.480
<v Speaker 2>Which ensures the authentication mechanism is fully active and ready

87
00:04:17.480 --> 00:04:21.360
<v Speaker 2>to process that smiley faced trigger. It really moves vulnerability

88
00:04:21.399 --> 00:04:25.959
<v Speaker 2>from a theoretical concept into very specific lines of compiled

89
00:04:25.959 --> 00:04:27.040
<v Speaker 2>code running in memory.

90
00:04:27.199 --> 00:04:29.839
<v Speaker 1>Right, So, okay, we have our network level backdoor in

91
00:04:29.879 --> 00:04:32.759
<v Speaker 1>the Linux dummy, but we also need to observe application

92
00:04:32.839 --> 00:04:35.319
<v Speaker 1>layer flaws, which brings us to the Windows target.

93
00:04:35.399 --> 00:04:37.240
<v Speaker 2>Ah, yes, the Windows target.

94
00:04:37.360 --> 00:04:39.879
<v Speaker 1>Yeah. If the Linux machine is an old workhorse, this

95
00:04:39.959 --> 00:04:42.720
<v Speaker 1>Windows target is a total relic. We are provisioning a

96
00:04:42.759 --> 00:04:45.439
<v Speaker 1>Windows Server two thousand and three instance straight from the

97
00:04:45.439 --> 00:04:47.040
<v Speaker 1>AWS marketplace.

98
00:04:46.680 --> 00:04:49.279
<v Speaker 2>Which is wild because Server two thousand and three lacks

99
00:04:49.319 --> 00:04:53.639
<v Speaker 2>address base layout randomization and like most modern execution protections.

100
00:04:53.879 --> 00:04:57.120
<v Speaker 1>But getting into this instance in the cloud introduces a

101
00:04:57.160 --> 00:04:59.319
<v Speaker 1>really unique AWS workflow.

102
00:04:59.000 --> 00:05:02.879
<v Speaker 2>Right it does. AWS strongly discourages password authentication, but since

103
00:05:02.879 --> 00:05:05.600
<v Speaker 2>we're using Remote Desktop Protocol to access the Windows GUI,

104
00:05:05.759 --> 00:05:07.759
<v Speaker 2>we actually need a password.

105
00:05:07.519 --> 00:05:11.360
<v Speaker 1>And AWS doesn't just email you the administrator credentials that

106
00:05:11.360 --> 00:05:14.600
<v Speaker 1>would be too easy. When the EC two instance books up,

107
00:05:15.000 --> 00:05:17.560
<v Speaker 1>it generates a random password, encrypts that password using the

108
00:05:17.560 --> 00:05:20.839
<v Speaker 1>public rsakey you assigned at launch, and then dumps that

109
00:05:20.879 --> 00:05:24.800
<v Speaker 1>ciphertext into the system log via the EC two metadata service.

110
00:05:25.000 --> 00:05:28.319
<v Speaker 2>It's actually a very elegant way to handle credentials without

111
00:05:28.360 --> 00:05:32.160
<v Speaker 2>the hypervisor or AWS itself ever knowing your actual plain

112
00:05:32.240 --> 00:05:33.000
<v Speaker 2>text password.

113
00:05:33.079 --> 00:05:35.720
<v Speaker 1>So to get in you have to download that encrypted

114
00:05:35.720 --> 00:05:38.680
<v Speaker 1>payload from the console and process it locally with your

115
00:05:38.720 --> 00:05:39.879
<v Speaker 1>private RSA key.

116
00:05:40.079 --> 00:05:45.480
<v Speaker 2>Exactly, your local machine decrypts the log, revealing the plaintext passwords.

117
00:05:45.160 --> 00:05:48.399
<v Speaker 1>Piece of cryptography. But once we use that password to

118
00:05:48.480 --> 00:05:51.000
<v Speaker 1>RDP into the box, we just completely ruin the neighborhood.

119
00:05:51.000 --> 00:05:51.600
<v Speaker 2>Oh totally.

120
00:05:51.639 --> 00:05:55.079
<v Speaker 1>We install an old bundled version of xampp so that's

121
00:05:55.079 --> 00:05:58.800
<v Speaker 1>a patchy myseqel and PHP, and drop a vulnerable web app,

122
00:05:58.879 --> 00:06:03.199
<v Speaker 1>specifically a SQL injection demo called Shindarth Sickle injection demo

123
00:06:03.639 --> 00:06:05.360
<v Speaker 1>directly into the c stocks folder.

124
00:06:05.439 --> 00:06:08.240
<v Speaker 2>We even log into FEASTPMI admin to manually import the

125
00:06:08.279 --> 00:06:09.839
<v Speaker 2>database dot spl file.

126
00:06:09.800 --> 00:06:13.399
<v Speaker 1>Just bypassing every modern web application firewall and serving up

127
00:06:13.439 --> 00:06:16.920
<v Speaker 1>a brittle database architecture on a silver platter YEP, handing

128
00:06:17.000 --> 00:06:17.759
<v Speaker 1>it right to them.

129
00:06:17.800 --> 00:06:21.720
<v Speaker 2>Okay, here's where it gets really interesting. You've just created

130
00:06:21.800 --> 00:06:25.720
<v Speaker 2>digital biohazards on the public Internet. If we don't immediately

131
00:06:25.759 --> 00:06:29.160
<v Speaker 2>lock them down, real malicious actors will find and compromise

132
00:06:29.199 --> 00:06:30.800
<v Speaker 2>them before we even start.

133
00:06:30.720 --> 00:06:34.519
<v Speaker 1>Exactly, So we have to talk about quarantining these biohazards

134
00:06:34.600 --> 00:06:38.600
<v Speaker 1>using AWS, virtual Private clouds or vpcs.

135
00:06:38.800 --> 00:06:41.240
<v Speaker 2>Right, and a VPC can hold up to what four

136
00:06:41.720 --> 00:06:46.639
<v Speaker 2>ninety six internal IP addresses, but by default AWS blocks

137
00:06:46.639 --> 00:06:47.879
<v Speaker 2>them from talking to each other.

138
00:06:48.040 --> 00:06:50.560
<v Speaker 1>Yeah, it's zero trust out of the box. To allow

139
00:06:50.600 --> 00:06:53.279
<v Speaker 1>the lab machines to communicate. The text tells us to

140
00:06:53.360 --> 00:06:56.480
<v Speaker 1>manually capture the private IP of your attack machine and

141
00:06:56.680 --> 00:06:59.399
<v Speaker 1>edit the inbound rules in the AWS security.

142
00:06:59.040 --> 00:07:01.720
<v Speaker 2>Groups, and you change those rules to allow all traffic

143
00:07:01.839 --> 00:07:05.480
<v Speaker 2>exclusively from that one specific IP, right, effectively cutting off

144
00:07:05.480 --> 00:07:05.879
<v Speaker 2>the rest.

145
00:07:05.759 --> 00:07:06.759
<v Speaker 1>Of the world precisely.

146
00:07:06.800 --> 00:07:09.560
<v Speaker 2>But wait, we are putting incredibly vulnerable machines on the

147
00:07:09.639 --> 00:07:12.240
<v Speaker 2>largest public cloud in the world and relying entirely on

148
00:07:12.319 --> 00:07:14.920
<v Speaker 2>a virtual firewall rule to keep the bad guys out?

149
00:07:15.240 --> 00:07:18.399
<v Speaker 2>Isn't that inherently risky? I mean, it sounds reckless, it

150
00:07:18.439 --> 00:07:21.720
<v Speaker 2>really does. But this is the ultimate lesson in cloud

151
00:07:21.759 --> 00:07:25.040
<v Speaker 2>access control. You have to understand that security groups are

152
00:07:25.079 --> 00:07:27.560
<v Speaker 2>the fundamental perimeter defense in AWS.

153
00:07:27.680 --> 00:07:29.879
<v Speaker 1>Okay, so it's not like a normal firewall, right.

154
00:07:29.800 --> 00:07:33.160
<v Speaker 2>It's not a traditional operating system firewall like IPTA BOWLS

155
00:07:33.240 --> 00:07:37.279
<v Speaker 2>or Windows firewall. It operates independently at the hypervisor layer.

156
00:07:37.800 --> 00:07:42.240
<v Speaker 2>Understanding how to strictly define a loud praffic Essentially, whitelisting

157
00:07:42.680 --> 00:07:45.399
<v Speaker 2>is a non negotiable skill for any cloud engineer.

158
00:07:45.800 --> 00:07:48.319
<v Speaker 1>I see, so the hypervisor acts as the bouncer before

159
00:07:48.360 --> 00:07:50.360
<v Speaker 1>traffic even gets near the operating system.

160
00:07:50.519 --> 00:07:51.000
<v Speaker 2>Exactly.

161
00:07:51.079 --> 00:07:54.240
<v Speaker 1>Okay, so the biohzards are quarantined safely inside the sandbox.

162
00:07:54.600 --> 00:07:57.399
<v Speaker 1>But now you need to sneak your own attack machine

163
00:07:57.399 --> 00:07:58.519
<v Speaker 1>inside that sandbox.

164
00:07:58.600 --> 00:08:01.000
<v Speaker 2>Right, you need to build the attacker's cock pit. The

165
00:08:01.040 --> 00:08:05.839
<v Speaker 2>blueprint specifies deploying the Calli Linux Amazon Machine image, specifically

166
00:08:05.879 --> 00:08:09.000
<v Speaker 2>an older twenty eighteen point one build running on a

167
00:08:09.040 --> 00:08:11.000
<v Speaker 2>T two dot medium instance.

168
00:08:10.920 --> 00:08:13.079
<v Speaker 1>And that T two dot medium gives you two virtual

169
00:08:13.120 --> 00:08:16.079
<v Speaker 1>cores and four gigabytes of RAM, which is super important

170
00:08:16.120 --> 00:08:18.639
<v Speaker 1>because penetration testing tools will just chew through memory.

171
00:08:18.680 --> 00:08:19.800
<v Speaker 2>Oh they absolutely will.

172
00:08:19.920 --> 00:08:20.160
<v Speaker 1>Yeah.

173
00:08:20.199 --> 00:08:24.199
<v Speaker 2>But deploying Collie in the cloud introduces a major access dilemma.

174
00:08:24.120 --> 00:08:28.759
<v Speaker 1>Because AWS requires secure key based authentication by default. But

175
00:08:29.000 --> 00:08:32.240
<v Speaker 1>the book shows how to configure the machine for easy

176
00:08:32.320 --> 00:08:33.759
<v Speaker 1>mobile or browser access.

177
00:08:33.840 --> 00:08:36.240
<v Speaker 2>Right, yes, And to do that you have to alter

178
00:08:36.399 --> 00:08:40.799
<v Speaker 2>the aescetrous config file to change permit root log in

179
00:08:40.840 --> 00:08:42.519
<v Speaker 2>and password authentication to yes.

180
00:08:43.120 --> 00:08:43.440
<v Speaker 1>Wow.

181
00:08:43.600 --> 00:08:48.000
<v Speaker 2>Yeah, this raises an important question. You are actively reducing

182
00:08:48.039 --> 00:08:52.240
<v Speaker 2>your security stance to enable root password logins. It highlights

183
00:08:52.279 --> 00:08:55.799
<v Speaker 2>this eternal tug of war and tech between ultimate security,

184
00:08:55.840 --> 00:08:59.200
<v Speaker 2>so key based limited users and ultimate convenience, which is

185
00:08:59.240 --> 00:09:01.360
<v Speaker 2>browser based root access.

186
00:09:01.159 --> 00:09:04.000
<v Speaker 1>Right, and we get that convenience by installing a patch Guacamole.

187
00:09:04.279 --> 00:09:06.000
<v Speaker 1>I like to think of Guacamole as having a high

188
00:09:06.039 --> 00:09:08.759
<v Speaker 1>tech remote control that lets you pilot your attack ship

189
00:09:08.799 --> 00:09:10.679
<v Speaker 1>from a coffee shop using just a web browser.

190
00:09:10.799 --> 00:09:12.679
<v Speaker 2>That's exactly what it is. But to set it up

191
00:09:12.679 --> 00:09:15.519
<v Speaker 2>you need specific hardening steps because you just open up

192
00:09:15.559 --> 00:09:16.919
<v Speaker 2>your SSH canfig right.

193
00:09:17.039 --> 00:09:19.000
<v Speaker 1>You don't want someone else stealing your attack.

194
00:09:18.759 --> 00:09:22.200
<v Speaker 2>Ship exactly, So you install it too the uncomplicated firewall

195
00:09:22.279 --> 00:09:24.919
<v Speaker 2>and fail to banning to stop root force attacks. Then

196
00:09:24.960 --> 00:09:27.440
<v Speaker 2>you open port twenty two for SSH and port five

197
00:09:27.480 --> 00:09:29.159
<v Speaker 2>five five five five for Guacamole.

198
00:09:29.480 --> 00:09:31.960
<v Speaker 1>Yeah, and the book details changing the Tomcat eight server

199
00:09:32.039 --> 00:09:35.440
<v Speaker 1>port to five five five five five, installing XRDP for

200
00:09:35.480 --> 00:09:39.279
<v Speaker 1>the remote desktop, and setting up the userbambing dot xml file.

201
00:09:39.600 --> 00:09:43.080
<v Speaker 2>That user dash mapping dot xml file is critical because

202
00:09:43.080 --> 00:09:45.919
<v Speaker 2>it tells Guacamole how to connect the browser session to

203
00:09:46.039 --> 00:09:47.759
<v Speaker 2>the local XRDT service.

204
00:09:47.879 --> 00:09:50.320
<v Speaker 1>It's an amazing setup. So, Okay, you are sitting in

205
00:09:50.399 --> 00:09:53.039
<v Speaker 1>the cockpit, you have the controls, but right now you

206
00:09:53.080 --> 00:09:56.039
<v Speaker 1>are flying blind. Before you attack you need to map

207
00:09:56.039 --> 00:09:57.639
<v Speaker 1>out the vulnerabilities of your.

208
00:09:57.480 --> 00:09:59.919
<v Speaker 2>Targets because you need to know exactly what you're dealing with,

209
00:10:00.000 --> 00:10:04.200
<v Speaker 2>which means installing nessa's a really popular automated vulnerability scanner.

210
00:10:03.960 --> 00:10:07.080
<v Speaker 1>Right, But there are logistics involved. The text mentions you

211
00:10:07.080 --> 00:10:09.519
<v Speaker 1>have to download the dot deb package from tenable and

212
00:10:09.600 --> 00:10:12.320
<v Speaker 1>use a tool like win SCP to securely transfer it

213
00:10:12.360 --> 00:10:13.600
<v Speaker 1>to the KALIEC two INSI.

214
00:10:13.679 --> 00:10:16.120
<v Speaker 2>Yeah, and then you install it via the dpkg command.

215
00:10:16.480 --> 00:10:19.799
<v Speaker 2>But here is the final trick. NESSUS runs its own

216
00:10:19.840 --> 00:10:21.440
<v Speaker 2>local web interface.

217
00:10:21.080 --> 00:10:23.320
<v Speaker 1>And you can't just open a browser on a headless server.

218
00:10:23.240 --> 00:10:25.960
<v Speaker 2>Exactly To securely view it on your local computer, you

219
00:10:26.080 --> 00:10:29.519
<v Speaker 2>must create an SSH tunnel. You forward Colley's port eight

220
00:10:29.559 --> 00:10:31.840
<v Speaker 2>eight three four back to your local one two seven

221
00:10:31.919 --> 00:10:34.320
<v Speaker 2>by zero point one point eight eight three four.

222
00:10:34.639 --> 00:10:37.120
<v Speaker 1>Oh that is so clever. So once you do that,

223
00:10:37.279 --> 00:10:40.000
<v Speaker 1>you just open your local browser, register a home license,

224
00:10:40.320 --> 00:10:41.799
<v Speaker 1>and initialize the scanner data.

225
00:10:41.960 --> 00:10:45.360
<v Speaker 2>Yep, it pipes the interface securely over SSH right to

226
00:10:45.399 --> 00:10:45.879
<v Speaker 2>your screen.

227
00:10:46.240 --> 00:10:48.600
<v Speaker 1>So what does this all mean for our toolkit? It's

228
00:10:48.639 --> 00:10:52.039
<v Speaker 1>basically like turning on the targeting radar in a fighter jet.

229
00:10:52.559 --> 00:10:55.360
<v Speaker 1>It automates all the heavy lifting of finding exactly where

230
00:10:55.360 --> 00:10:56.240
<v Speaker 1>the armor is weak.

231
00:10:56.399 --> 00:10:59.440
<v Speaker 2>It really is, and running these NESSA scans mimics the

232
00:10:59.519 --> 00:11:03.919
<v Speaker 2>exact to automated reconnaissance that malicious spots perform constantly across

233
00:11:04.000 --> 00:11:07.200
<v Speaker 2>the entire Internet. By seeing the output of the scan

234
00:11:07.360 --> 00:11:10.600
<v Speaker 2>on your intentional vulnerabilities, you learn exactly what the enemy

235
00:11:10.600 --> 00:11:13.120
<v Speaker 2>sees when they look at a poorly configured network.

236
00:11:13.200 --> 00:11:15.919
<v Speaker 1>Wow. Okay, so let's summarize where we are. We've taken

237
00:11:15.919 --> 00:11:19.360
<v Speaker 1>you from a completely empty AWS account to a fully functioning,

238
00:11:19.720 --> 00:11:22.000
<v Speaker 1>quarantined cyber warfare.

239
00:11:21.679 --> 00:11:23.440
<v Speaker 2>Lab a pretty dangerous one too.

240
00:11:23.519 --> 00:11:26.159
<v Speaker 1>Yeah, no kidding. You've got an infected Linux server and

241
00:11:26.320 --> 00:11:30.080
<v Speaker 1>Arcaic Windows SQL injection target, and a browser controlled Kali

242
00:11:30.159 --> 00:11:31.720
<v Speaker 1>Linux attack box armed with.

243
00:11:31.639 --> 00:11:33.799
<v Speaker 2>A nessa's radar, all running in the cloud.

244
00:11:33.919 --> 00:11:37.360
<v Speaker 1>Right. And this matters because the cloud isn't just for

245
00:11:37.440 --> 00:11:42.159
<v Speaker 1>hosting websites. It is a highly dynamic, disposable learning environment

246
00:11:42.360 --> 00:11:45.639
<v Speaker 1>where you can build and destroy complex networks for pennies

247
00:11:45.639 --> 00:11:45.960
<v Speaker 1>an hour.

248
00:11:46.279 --> 00:11:49.679
<v Speaker 2>It's an incredible resource for cybersecurity professionals, it really is.

249
00:11:50.039 --> 00:11:51.759
<v Speaker 1>But I want to leave you with a final kind

250
00:11:51.759 --> 00:11:55.399
<v Speaker 1>of lingering question to ponder. We just saw how fast

251
00:11:55.399 --> 00:11:58.879
<v Speaker 1>and easy it is to spin up intentionally vulnerable infrastructure

252
00:11:59.200 --> 00:12:02.120
<v Speaker 1>using pre configure AMIS and code.

253
00:12:01.879 --> 00:12:04.399
<v Speaker 2>From GitHub literally just a few minutes, right.

254
00:12:04.480 --> 00:12:07.000
<v Speaker 1>So, if it's this easy to automate the deployment of

255
00:12:07.080 --> 00:12:10.759
<v Speaker 1>vulnerabilities on purpose, what does that mean for real companies?

256
00:12:11.240 --> 00:12:16.200
<v Speaker 1>Companies whose automated deployment scripts, infrastructure is code might contain

257
00:12:16.240 --> 00:12:18.120
<v Speaker 1>a single, tiny misconfiguration.

258
00:12:18.440 --> 00:12:20.039
<v Speaker 2>Oh that is a terrifying thought.

259
00:12:20.120 --> 00:12:22.600
<v Speaker 1>How many accidental crash test dunies are out there on

260
00:12:22.679 --> 00:12:25.360
<v Speaker 1>the real Internet right now, just waiting for someone's radar

261
00:12:25.440 --> 00:12:25.960
<v Speaker 1>to ping them