WEBVTT

1
00:00:00.160 --> 00:00:02.839
<v Speaker 1>Welcome to the Deep Dive, the show where we cut

2
00:00:02.879 --> 00:00:05.599
<v Speaker 1>through the noise to get you truly well informed on

3
00:00:05.759 --> 00:00:06.759
<v Speaker 1>fascinating topics.

4
00:00:06.879 --> 00:00:08.720
<v Speaker 2>Great to be digging into another one.

5
00:00:08.960 --> 00:00:13.839
<v Speaker 1>So, you know, in our increasingly digital world, there's this constant,

6
00:00:14.039 --> 00:00:19.719
<v Speaker 1>often hidden battle being waged. It's not just against external threats,

7
00:00:20.199 --> 00:00:23.280
<v Speaker 1>but right within the very systems we rely on every

8
00:00:23.399 --> 00:00:26.399
<v Speaker 1>single day. Right, Think of it like well, a digital

9
00:00:26.440 --> 00:00:30.519
<v Speaker 1>fortress and understanding its weaknesses, you know, the chinks in

10
00:00:30.559 --> 00:00:33.359
<v Speaker 1>the armor is just as crucial as actually building the

11
00:00:33.359 --> 00:00:34.280
<v Speaker 1>walls themselves.

12
00:00:34.479 --> 00:00:37.600
<v Speaker 2>Absolutely, for a long long time, the security mindset was

13
00:00:37.640 --> 00:00:41.200
<v Speaker 2>almost entirely focused just on network perimeters, right, the outer

14
00:00:41.280 --> 00:00:46.439
<v Speaker 2>walls exactly. Companies poured money into firewalls, network defenses, which,

15
00:00:46.520 --> 00:00:48.880
<v Speaker 2>honestly it kind of fostered a full sense of security

16
00:00:48.920 --> 00:00:51.799
<v Speaker 2>in some ways. How so well, because then our reliance

17
00:00:51.799 --> 00:00:56.000
<v Speaker 2>on web technologies just exploded, you know, public websites, internal apps,

18
00:00:56.039 --> 00:00:57.039
<v Speaker 2>everything moved online.

19
00:00:57.119 --> 00:00:59.679
<v Speaker 1>Ah okay, And that's where the whole game changed, isn't it.

20
00:01:00.200 --> 00:01:05.560
<v Speaker 2>Precisely because suddenly web applications became just as vulnerable to attack,

21
00:01:05.719 --> 00:01:09.359
<v Speaker 2>maybe even more so than those traditional networks and operating systems.

22
00:01:09.480 --> 00:01:10.920
<v Speaker 1>Yeah, we've all seen the headlines.

23
00:01:11.040 --> 00:01:15.719
<v Speaker 2>Unfortunately, absolutely recent years, I mean, we've seen just spectacular

24
00:01:15.799 --> 00:01:18.480
<v Speaker 2>data leaks, breaches affecting millions of records.

25
00:01:18.680 --> 00:01:21.680
<v Speaker 1>Yeah, everything from credit cards, health histories.

26
00:01:21.400 --> 00:01:25.519
<v Speaker 2>Social security numbers, you name it. And so often these

27
00:01:25.640 --> 00:01:29.519
<v Speaker 2>really devastating attacks they didn't start with breaking through the.

28
00:01:29.400 --> 00:01:31.079
<v Speaker 1>Network firewall, no where.

29
00:01:31.159 --> 00:01:34.480
<v Speaker 2>Then they often started with a vulnerability or maybe a

30
00:01:34.519 --> 00:01:37.840
<v Speaker 2>simple design flawed directly within a web application itself.

31
00:01:37.920 --> 00:01:40.040
<v Speaker 1>Okay, so the industry had to react to that. It did.

32
00:01:40.200 --> 00:01:43.120
<v Speaker 2>We saw this rapid rise in defensive tech, things like

33
00:01:43.280 --> 00:01:48.400
<v Speaker 2>web application firewalls wfs and run time applications self protection

34
00:01:48.599 --> 00:01:52.799
<v Speaker 2>are asp plus you know, sophisticated web vulnerability scanners, source

35
00:01:52.799 --> 00:01:56.599
<v Speaker 2>code scanners became standard. Companies finally started realizing the immense

36
00:01:56.680 --> 00:01:58.920
<v Speaker 2>value of testing applications before they go.

37
00:01:58.879 --> 00:02:01.560
<v Speaker 1>Live, which leads us perfectly in today's deep dive topic

38
00:02:01.680 --> 00:02:05.959
<v Speaker 1>penetration testing exactly. Think of this as your shortcut to

39
00:02:06.280 --> 00:02:11.080
<v Speaker 1>understanding how ethical hackers, well if they act like controlled adversaries, right.

40
00:02:11.000 --> 00:02:15.840
<v Speaker 2>Mm hmm, meticulously identifying and exploiting vulnerabilities, especially in those

41
00:02:15.879 --> 00:02:17.520
<v Speaker 2>really critical web applications.

42
00:02:17.599 --> 00:02:21.520
<v Speaker 1>So today we're going to unpack the skills, the surprising facts,

43
00:02:21.960 --> 00:02:26.199
<v Speaker 1>the powerful tools that help strengthen our digital defenses. And

44
00:02:26.280 --> 00:02:30.560
<v Speaker 1>we're drawing insights from a really comprehensive source called improving

45
00:02:30.639 --> 00:02:33.599
<v Speaker 1>your penetration testing Skills. Yeah, it's a great resource, So

46
00:02:33.680 --> 00:02:36.319
<v Speaker 1>get ready to see the world of digital security from

47
00:02:36.319 --> 00:02:37.520
<v Speaker 1>the attacker's perspective.

48
00:02:37.919 --> 00:02:41.400
<v Speaker 2>But you know, for good, that's the key. At its core,

49
00:02:41.680 --> 00:02:45.439
<v Speaker 2>penetration testing is well, it's the art of making a

50
00:02:45.479 --> 00:02:48.599
<v Speaker 2>computer system or an application do things it was never

51
00:02:48.639 --> 00:02:49.280
<v Speaker 2>designed to do.

52
00:02:49.520 --> 00:02:50.199
<v Speaker 1>But ethically.

53
00:02:50.280 --> 00:02:53.319
<v Speaker 2>But ethically, yes, the goal is always to discover flaws

54
00:02:53.360 --> 00:02:56.280
<v Speaker 2>before the malicious actors do and then provide you know,

55
00:02:56.360 --> 00:02:58.240
<v Speaker 2>actionable advice on how to fix them.

56
00:02:58.319 --> 00:03:01.280
<v Speaker 1>So it helps everyone really, company, hospitals.

57
00:03:00.759 --> 00:03:04.439
<v Speaker 2>Schools, government agencies, helping them secure their vital applications and

58
00:03:04.520 --> 00:03:05.520
<v Speaker 2>of course their data.

59
00:03:05.599 --> 00:03:08.719
<v Speaker 1>So it's like a controlled strategic attack to find the

60
00:03:08.759 --> 00:03:12.280
<v Speaker 1>weak spots before the actual bad guys do. How do

61
00:03:12.400 --> 00:03:16.639
<v Speaker 1>these engagements usually work? Does the testing team always get

62
00:03:16.680 --> 00:03:17.719
<v Speaker 1>all the info upfront?

63
00:03:18.199 --> 00:03:20.599
<v Speaker 2>Well, it varies quite a bit, actually depends on the

64
00:03:20.599 --> 00:03:22.719
<v Speaker 2>type of engagement you've got. Black box testing.

65
00:03:22.919 --> 00:03:24.240
<v Speaker 1>Okay, black box.

66
00:03:24.039 --> 00:03:28.360
<v Speaker 2>This simulates an external attacker who's completely uninformed. The pen

67
00:03:28.400 --> 00:03:32.000
<v Speaker 2>tester starts with well zero knowledge, just like a real

68
00:03:32.039 --> 00:03:35.199
<v Speaker 2>world hacker might trying to map the network discover defenses

69
00:03:35.280 --> 00:03:38.719
<v Speaker 2>all from scratch, but you know, for internal applications, this

70
00:03:38.840 --> 00:03:41.520
<v Speaker 2>might sometimes be a less efficient way to go. Why

71
00:03:41.560 --> 00:03:45.319
<v Speaker 2>is that because a real attacker might easily gather public info,

72
00:03:45.599 --> 00:03:48.080
<v Speaker 2>or frankly, they might be a disgruntled insider who already

73
00:03:48.120 --> 00:03:50.759
<v Speaker 2>knows a lot, So the black box test might miss

74
00:03:50.800 --> 00:03:52.400
<v Speaker 2>things an insider threat wouldn't.

75
00:03:52.439 --> 00:03:54.199
<v Speaker 1>Okay, So it's like trying to break into a house

76
00:03:54.240 --> 00:03:56.960
<v Speaker 1>without knowing where the doors or windows are, versus say,

77
00:03:57.039 --> 00:03:58.080
<v Speaker 1>having some basic.

78
00:03:57.759 --> 00:04:00.319
<v Speaker 2>Blueprints exactly that. Then on the other end of the

79
00:04:00.319 --> 00:04:03.199
<v Speaker 2>spectrum you have white box testing total opposite, I'm guessing

80
00:04:03.400 --> 00:04:09.360
<v Speaker 2>complete opposite. The testing team gets full information, source code, architecture, diagrams,

81
00:04:09.400 --> 00:04:12.599
<v Speaker 2>you name it. It's extremely thorough. And in the middle

82
00:04:13.080 --> 00:04:17.879
<v Speaker 2>that's grey box testing, an intermediate approach. Some info is provided,

83
00:04:18.079 --> 00:04:22.000
<v Speaker 2>but not everything. This often simulates, say an insider threat,

84
00:04:22.079 --> 00:04:25.079
<v Speaker 2>or maybe what someone could do with a compromised user account.

85
00:04:25.160 --> 00:04:28.199
<v Speaker 1>What's really interesting, though, is that even with these structured approaches,

86
00:04:28.399 --> 00:04:31.360
<v Speaker 1>pen testing still has limits. Right, It's not like a

87
00:04:31.399 --> 00:04:32.319
<v Speaker 1>magic wand.

88
00:04:32.120 --> 00:04:35.560
<v Speaker 2>You wave, oh, absolutely not. That's a crucial point to understand. First,

89
00:04:35.800 --> 00:04:39.959
<v Speaker 2>there's the limitation of skills, meaning well, it's incredibly tough

90
00:04:40.000 --> 00:04:42.879
<v Speaker 2>to find one person who's equally skilled across all the

91
00:04:42.920 --> 00:04:48.600
<v Speaker 2>major areas network system and web application Penetration testing expertise

92
00:04:48.680 --> 00:04:50.639
<v Speaker 2>is often really specialized, right.

93
00:04:50.720 --> 00:04:53.279
<v Speaker 1>Someone might be brilliant with apatche servers but know nothing

94
00:04:53.319 --> 00:04:54.160
<v Speaker 1>about ISO.

95
00:04:53.959 --> 00:04:57.279
<v Speaker 2>For example, exactly and figuring out how a seemingly low

96
00:04:57.399 --> 00:05:01.000
<v Speaker 2>risk vulnerability could actually so is a high threat to

97
00:05:01.040 --> 00:05:04.079
<v Speaker 2>a specific system that often comes only with you know,

98
00:05:04.240 --> 00:05:05.720
<v Speaker 2>deep experience and I bet.

99
00:05:05.560 --> 00:05:08.319
<v Speaker 1>Time is always a massive factor, especially compared to a

100
00:05:08.319 --> 00:05:08.959
<v Speaker 1>real attacker.

101
00:05:09.079 --> 00:05:13.680
<v Speaker 2>Always. Penetration testing is almost always a short, pre defined project.

102
00:05:14.240 --> 00:05:16.759
<v Speaker 2>Testers have a limited window, maybe a week or two

103
00:05:17.120 --> 00:05:19.759
<v Speaker 2>to find vulnerabilities and produce results.

104
00:05:19.600 --> 00:05:22.000
<v Speaker 1>Whereas a malicious attacker.

105
00:05:21.680 --> 00:05:26.120
<v Speaker 2>They have unlimited time days, weeks, months, plus. The pen

106
00:05:26.199 --> 00:05:29.879
<v Speaker 2>tester has the added burden of writing these incredibly detailed,

107
00:05:29.879 --> 00:05:34.639
<v Speaker 2>defensible reports with screenshots and explanations. An attacker doesn't worry

108
00:05:34.639 --> 00:05:35.040
<v Speaker 2>about that.

109
00:05:35.360 --> 00:05:38.319
<v Speaker 1>So they can't just throw everything they have at a target,

110
00:05:38.560 --> 00:05:40.040
<v Speaker 1>even if they technically.

111
00:05:39.560 --> 00:05:43.920
<v Speaker 2>Could not always know in really secure environments, standard frameworks

112
00:05:44.000 --> 00:05:46.720
<v Speaker 2>or automated tools might just bounce off. They might be.

113
00:05:46.759 --> 00:05:48.399
<v Speaker 1>Useless, So they have to get creative.

114
00:05:48.519 --> 00:05:52.079
<v Speaker 2>Yeah, forcing the team to create custom exploits or manually

115
00:05:52.120 --> 00:05:56.279
<v Speaker 2>write scripts to test specific things, and that's incredibly time consuming.

116
00:05:56.360 --> 00:06:00.399
<v Speaker 2>It directly impacts the project's budget and timeline. Okay, Another

117
00:06:00.439 --> 00:06:04.600
<v Speaker 2>common limitation is deliberately avoiding denial of service or DOS attacks.

118
00:06:04.839 --> 00:06:07.759
<v Speaker 1>Why avoid those seems like something you'd want to test.

119
00:06:07.920 --> 00:06:10.800
<v Speaker 2>Well, many testers intentionally avoid them because they don't want

120
00:06:10.839 --> 00:06:13.879
<v Speaker 2>to inadvertently cause client downtime. It's a business risk.

121
00:06:14.040 --> 00:06:15.279
<v Speaker 1>Ah, makes sense.

122
00:06:15.279 --> 00:06:19.439
<v Speaker 2>But the downside is this inadvertently leaves systems potentially open

123
00:06:19.519 --> 00:06:24.279
<v Speaker 2>to well script kitties, less sophisticated attackers who just want

124
00:06:24.319 --> 00:06:29.199
<v Speaker 2>notoriety by taking systems offline. So it's really vital to

125
00:06:29.399 --> 00:06:32.600
<v Speaker 2>educate clients upfront about the pros and cons of doing

126
00:06:32.600 --> 00:06:33.319
<v Speaker 2>this kinds of test.

127
00:06:33.439 --> 00:06:36.079
<v Speaker 1>That's a really good point. And what about the tools themselves?

128
00:06:36.120 --> 00:06:37.199
<v Speaker 1>Are they always reliable?

129
00:06:37.959 --> 00:06:41.680
<v Speaker 2>That's another limitation The tools used, No single tool, free

130
00:06:41.759 --> 00:06:44.720
<v Speaker 2>or commercial, is perfect. They all have blind spots, so.

131
00:06:44.720 --> 00:06:47.079
<v Speaker 1>The tester needs to know more than just how to

132
00:06:47.160 --> 00:06:48.399
<v Speaker 1>run the tool exactly.

133
00:06:48.759 --> 00:06:51.680
<v Speaker 2>The testing team needs to be knowledgeable enough to adapt,

134
00:06:51.920 --> 00:06:55.519
<v Speaker 2>understand the tool's limitations, and find alternatives when you know

135
00:06:55.560 --> 00:06:58.480
<v Speaker 2>its features just aren't cutting it for a specific scenario.

136
00:06:58.800 --> 00:07:00.639
<v Speaker 1>All this makes me think about where a pen tester

137
00:07:00.800 --> 00:07:03.839
<v Speaker 1>actually practice this stuff. You can't just go poking around

138
00:07:03.920 --> 00:07:04.800
<v Speaker 1>random websites on.

139
00:07:04.720 --> 00:07:08.360
<v Speaker 2>The internet, right, illegal? You're absolutely right. It is illegal

140
00:07:08.360 --> 00:07:11.959
<v Speaker 2>in most countries to scan, test, or exploit vulnerabilities on

141
00:07:11.959 --> 00:07:15.439
<v Speaker 2>the Internet without explicit written authorization from the owner.

142
00:07:15.839 --> 00:07:16.639
<v Speaker 1>So how do they learn?

143
00:07:16.920 --> 00:07:21.000
<v Speaker 2>That's why having a controlled, owned and isolated lab environment

144
00:07:21.120 --> 00:07:25.600
<v Speaker 2>is just paramount, absolutely essential. It's the only place you

145
00:07:25.639 --> 00:07:29.199
<v Speaker 2>can freely practice and develop your skills without any legal worries.

146
00:07:29.680 --> 00:07:32.000
<v Speaker 1>And there are specific vulnerable environments for that.

147
00:07:32.240 --> 00:07:35.800
<v Speaker 2>Yes, things like oh washbroken web applications or hackers on

148
00:07:35.839 --> 00:07:38.560
<v Speaker 2>which we'll definitely talk more about. They're perfect for this

149
00:07:38.680 --> 00:07:39.720
<v Speaker 2>kind of safe practice.

150
00:07:39.800 --> 00:07:44.959
<v Speaker 1>Okay, so setting up this ethical hacking lab, what's the

151
00:07:45.720 --> 00:07:48.079
<v Speaker 1>go to operating system? I always hear Klie Linux.

152
00:07:48.240 --> 00:07:51.079
<v Speaker 2>Ah, Collie Linux. Yes, it really is kind of the

153
00:07:51.240 --> 00:07:53.160
<v Speaker 2>ethical hackers dream toolkit.

154
00:07:53.319 --> 00:07:54.600
<v Speaker 1>Why is that? What's the big deal?

155
00:07:54.879 --> 00:07:58.800
<v Speaker 2>Its main value is just how much it simplifies the setup.

156
00:07:59.000 --> 00:08:01.000
<v Speaker 2>It comes with pretty much whch all the major hacking

157
00:08:01.000 --> 00:08:04.040
<v Speaker 2>tools pre installed along with all their dependencies. Oh nice,

158
00:08:04.040 --> 00:08:06.560
<v Speaker 2>So it means you can focus immediately on learning and

159
00:08:06.639 --> 00:08:10.560
<v Speaker 2>actually doing the attacks, rather than wasting hours just installing

160
00:08:10.600 --> 00:08:14.800
<v Speaker 2>and configuring individual tools and offensive security. The folks behind

161
00:08:14.879 --> 00:08:17.759
<v Speaker 2>Collie they keep these tools frequently updated, so you're always

162
00:08:17.759 --> 00:08:18.800
<v Speaker 2>working with the latest stuff.

163
00:08:18.920 --> 00:08:22.519
<v Speaker 1>So it's like a constantly updated, pre assembled workshop for

164
00:08:22.639 --> 00:08:25.360
<v Speaker 1>digital security. That's incredibly useful.

165
00:08:25.120 --> 00:08:28.160
<v Speaker 2>It really is, and it's remarkably versatile too. Collie runs

166
00:08:28.160 --> 00:08:32.759
<v Speaker 2>on various hardware Google, Chromebooks, Raspberry.

167
00:08:32.279 --> 00:08:33.799
<v Speaker 1>Pie, Raspberry Pie Wow.

168
00:08:34.320 --> 00:08:37.360
<v Speaker 2>There's even net Hunter, which is a version specifically designed

169
00:08:37.360 --> 00:08:38.440
<v Speaker 2>for mobile devices.

170
00:08:38.519 --> 00:08:40.720
<v Speaker 1>Now, a lot of people, myself included, tend to use

171
00:08:40.799 --> 00:08:44.600
<v Speaker 1>virtualization running it in a VM. What are the pros

172
00:08:44.600 --> 00:08:48.279
<v Speaker 1>and cons of that versus installing Collie directly on say,

173
00:08:48.279 --> 00:08:51.159
<v Speaker 1>a dedicated laptop. What's the real trade off there?

174
00:08:51.559 --> 00:08:55.360
<v Speaker 2>Virtualization is definitely an attractive option. It's cost effective, flexible,

175
00:08:55.679 --> 00:08:58.879
<v Speaker 2>You can easily clone virtual machines if you need multiple

176
00:08:58.919 --> 00:09:02.840
<v Speaker 2>testing copies, and the revert to snapshot feature is invaluable.

177
00:09:03.000 --> 00:09:05.559
<v Speaker 2>If you mess up your testing machine break something poof,

178
00:09:05.559 --> 00:09:09.360
<v Speaker 2>you just restore clean slate. Instantly modifying resources like RAM

179
00:09:09.480 --> 00:09:11.120
<v Speaker 2>or CPU is also super easy.

180
00:09:11.200 --> 00:09:12.519
<v Speaker 1>Okay, sounds great. What's the catch?

181
00:09:12.799 --> 00:09:17.240
<v Speaker 2>The major drawback comes with processor intensive tasks think password cracking.

182
00:09:17.440 --> 00:09:21.320
<v Speaker 2>Those tasks are significantly slower because of the virtualization overhead,

183
00:09:21.639 --> 00:09:24.679
<v Speaker 2>and you simply can't fully leverage a dedicated GPU a

184
00:09:24.720 --> 00:09:28.559
<v Speaker 2>graphics card for that kind of raw processing power inside

185
00:09:28.559 --> 00:09:29.720
<v Speaker 2>a standard VM setup.

186
00:09:30.039 --> 00:09:34.200
<v Speaker 1>So for serious number crunching, physical hardware still wins. But

187
00:09:34.320 --> 00:09:37.879
<v Speaker 1>for most day to day practice and exploration, virtualization is

188
00:09:38.120 --> 00:09:38.879
<v Speaker 1>probably fine.

189
00:09:38.919 --> 00:09:41.279
<v Speaker 2>Absolutely for most tasks it's the way to go.

190
00:09:41.399 --> 00:09:44.799
<v Speaker 1>Okay, So what are some of the essential tools packed

191
00:09:44.799 --> 00:09:47.639
<v Speaker 1>into Collie that a pentester would use regularly?

192
00:09:47.840 --> 00:09:50.279
<v Speaker 2>Right, let's touch on a few key categories. For content

193
00:09:50.360 --> 00:09:53.879
<v Speaker 2>management systems, you know CMSs, like WordPress or joom Law,

194
00:09:54.399 --> 00:09:59.120
<v Speaker 2>there are specialized scanners like what well, wp scan is

195
00:09:59.159 --> 00:10:03.240
<v Speaker 2>a really fast WordPress vulnerability scanner. It's surprising how often

196
00:10:03.360 --> 00:10:07.639
<v Speaker 2>organizations just leave default plugins and themes exposed. WP scan

197
00:10:07.759 --> 00:10:09.279
<v Speaker 2>finds those instantly.

198
00:10:08.919 --> 00:10:10.840
<v Speaker 1>Broadcasting their weak points essentially.

199
00:10:10.519 --> 00:10:13.840
<v Speaker 2>Pretty much similarly, jim scan does the same thing for gymlesites.

200
00:10:13.960 --> 00:10:16.960
<v Speaker 1>Got it? What about finding hidden files and directories? That

201
00:10:16.960 --> 00:10:18.879
<v Speaker 1>seems like a really critical first step for.

202
00:10:18.879 --> 00:10:23.320
<v Speaker 2>An attacker, definitely for that. Dirb is a command line tool.

203
00:10:23.519 --> 00:10:27.080
<v Speaker 2>It uses dictionary files to discover hidden files and directories.

204
00:10:27.559 --> 00:10:31.240
<v Speaker 2>Maybe old admin panels, backup files, things that shouldn't.

205
00:10:30.840 --> 00:10:33.200
<v Speaker 1>Be accessible in Nikto, I've heard that name.

206
00:10:33.360 --> 00:10:36.679
<v Speaker 2>Nikto is a longtime favorite. It's a really feature rich

207
00:10:37.080 --> 00:10:41.639
<v Speaker 2>web server scanner. Checks for thousands of outdated software components,

208
00:10:42.039 --> 00:10:45.600
<v Speaker 2>common configuration errors. It's like giving the web server a

209
00:10:45.639 --> 00:10:47.159
<v Speaker 2>thorough digital health check.

210
00:10:47.279 --> 00:10:51.120
<v Speaker 1>Okay, And for broader network scanning, maybe looking beyond just

211
00:10:51.159 --> 00:10:52.759
<v Speaker 1>the web applications themselves, for.

212
00:10:52.759 --> 00:10:57.000
<v Speaker 2>That network wide view. OpenVAS the Open Vulnerability Assessment Scanner

213
00:10:57.120 --> 00:10:58.840
<v Speaker 2>is a powerful tool in Collinge.

214
00:10:58.919 --> 00:11:01.159
<v Speaker 1>Right that used to be or part of it.

215
00:11:01.279 --> 00:11:03.440
<v Speaker 2>Yeah, it's a free fork of what was once nessus.

216
00:11:03.759 --> 00:11:07.360
<v Speaker 2>It's excellent for identifying a wide range of network side vulnerabilities,

217
00:11:07.399 --> 00:11:10.360
<v Speaker 2>giving you that bigger picture of potential entry points. And

218
00:11:10.399 --> 00:11:13.480
<v Speaker 2>these are just a few examples. The Colleague toolkit is vast.

219
00:11:13.840 --> 00:11:17.759
<v Speaker 1>So speaking of practice, you mentioned those vulnerable environments for

220
00:11:17.799 --> 00:11:21.759
<v Speaker 1>safe learning. Which ones are commonly used for training new pendesters? Yeah?

221
00:11:21.799 --> 00:11:25.159
<v Speaker 2>Absolutely. The a wasp p Broken Web Applications Project or

222
00:11:25.320 --> 00:11:30.440
<v Speaker 2>BWA is really crucial. It's a collection of intentionally vulnerable

223
00:11:30.639 --> 00:11:34.799
<v Speaker 2>web applications all packaged up as a single virtual machine.

224
00:11:34.919 --> 00:11:37.519
<v Speaker 2>Easy to set up them super easy, and it's perfect

225
00:11:37.600 --> 00:11:40.840
<v Speaker 2>for hands on learning. It includes apps like Wacko, Pico

226
00:11:40.960 --> 00:11:44.440
<v Speaker 2>and the Bodget Store, which simulate real world apps but

227
00:11:44.519 --> 00:11:47.000
<v Speaker 2>with less obvious flaws, so they really force you to

228
00:11:47.039 --> 00:11:48.080
<v Speaker 2>think like an attacker.

229
00:11:48.320 --> 00:11:49.399
<v Speaker 1>Okay, any others?

230
00:11:49.480 --> 00:11:52.360
<v Speaker 2>Another excellent one is hackazon. It's from Rapid seven, the

231
00:11:52.399 --> 00:11:53.759
<v Speaker 2>folks who make metasploit.

232
00:11:54.039 --> 00:11:54.399
<v Speaker 1>Okay.

233
00:11:54.440 --> 00:11:58.159
<v Speaker 2>It simulates a modern online store using technologies like ajax

234
00:11:58.320 --> 00:12:02.279
<v Speaker 2>and web services, and it has several security problems deliberately

235
00:12:02.320 --> 00:12:04.639
<v Speaker 2>built right in great practice ground.

236
00:12:04.840 --> 00:12:07.360
<v Speaker 1>So you've got your lab set up, your Collie machine ready,

237
00:12:07.399 --> 00:12:10.279
<v Speaker 1>a safe environment to practice in. What's the very first

238
00:12:10.320 --> 00:12:12.240
<v Speaker 1>thing an ethical hacker does when they start looking at

239
00:12:12.279 --> 00:12:13.000
<v Speaker 1>a target.

240
00:12:12.759 --> 00:12:15.200
<v Speaker 2>That brings us squarely into the art of gathering intel.

241
00:12:15.320 --> 00:12:18.759
<v Speaker 2>We often call it reconnaissance or recon Now, while a

242
00:12:18.799 --> 00:12:23.000
<v Speaker 2>malicious attacker might be chaotic, maybe opportunistic, a professional penetration

243
00:12:23.080 --> 00:12:25.679
<v Speaker 2>tester always follows a structured approach.

244
00:12:25.759 --> 00:12:27.200
<v Speaker 1>Right, there's a method, definitely.

245
00:12:27.519 --> 00:12:32.320
<v Speaker 2>The typical sequence is meticulous information gathering first, then identification

246
00:12:32.360 --> 00:12:37.200
<v Speaker 2>of vulnerabilities, often through scanning, and then finally exploitation. This

247
00:12:37.320 --> 00:12:39.600
<v Speaker 2>structured way helps you find as many bugs as you

248
00:12:39.639 --> 00:12:44.360
<v Speaker 2>can and importantly prepares you to write those valuable, comprehensive

249
00:12:44.360 --> 00:12:45.320
<v Speaker 2>reports for the client.

250
00:12:45.559 --> 00:12:48.759
<v Speaker 1>So reconnaissance is the foundation. What kind of information are

251
00:12:48.759 --> 00:12:50.600
<v Speaker 1>they trying to dig up in this phase? What are

252
00:12:50.600 --> 00:12:51.000
<v Speaker 1>the goals?

253
00:12:51.279 --> 00:12:55.679
<v Speaker 2>The aims are pretty broad, actually identifying it addresses, domains,

254
00:12:55.879 --> 00:13:01.080
<v Speaker 2>subdomains using tools like whois and DNS lookups, okay, gathering

255
00:13:01.080 --> 00:13:04.080
<v Speaker 2>public information from regular search engines like Google and bing,

256
00:13:04.559 --> 00:13:08.039
<v Speaker 2>but also specialized ones like Showdowan or even archives like

257
00:13:08.080 --> 00:13:09.080
<v Speaker 2>the Internet Archive.

258
00:13:09.240 --> 00:13:11.000
<v Speaker 1>Looking for clues anywhere they can find.

259
00:13:10.799 --> 00:13:14.559
<v Speaker 2>Them exactly, Identifying key personnel maybe through LinkedIn using tools

260
00:13:14.600 --> 00:13:17.960
<v Speaker 2>like Maltago. Even figuring out the physical location of servers

261
00:13:18.039 --> 00:13:20.200
<v Speaker 2>using GOIP databases can be part of it.

262
00:13:20.600 --> 00:13:22.559
<v Speaker 1>Gay, Let's unpack some of that you mentioned who is,

263
00:13:22.960 --> 00:13:25.919
<v Speaker 1>How does looking up domain records actually give an attacker

264
00:13:25.919 --> 00:13:27.639
<v Speaker 1>and edge seems pretty basic?

265
00:13:27.759 --> 00:13:33.559
<v Speaker 2>Who is records are public databases. They reveal domain owner details, names, addresses,

266
00:13:33.600 --> 00:13:37.919
<v Speaker 2>phone numbers, emails, the DNS servers being used. An attacker

267
00:13:37.960 --> 00:13:41.440
<v Speaker 2>can use this info for highly targeted social engineering attacks

268
00:13:42.120 --> 00:13:45.519
<v Speaker 2>or even for war driving driving around the registered address

269
00:13:45.559 --> 00:13:47.240
<v Speaker 2>looking for unsecured Wi Fi.

270
00:13:47.679 --> 00:13:48.200
<v Speaker 1>Wow.

271
00:13:48.240 --> 00:13:51.080
<v Speaker 2>And a really striking real world example was the New

272
00:13:51.159 --> 00:13:54.919
<v Speaker 2>York Times attack back in twenty thirteen. Their DNS records

273
00:13:54.960 --> 00:13:58.879
<v Speaker 2>were altered after a successful phishing attack against their domain reseller.

274
00:13:59.240 --> 00:14:02.440
<v Speaker 2>It shows how powerful this seemingly mundane data can be.

275
00:14:02.919 --> 00:14:05.960
<v Speaker 1>It really drives it home. Okay, what about DNS enumeration.

276
00:14:06.000 --> 00:14:07.000
<v Speaker 1>How do they leverage that?

277
00:14:07.559 --> 00:14:10.480
<v Speaker 2>Well? DNS servers often use something called zone transfer to

278
00:14:10.480 --> 00:14:14.039
<v Speaker 2>sync their databases. Okay, if that's misconfigured, which happens, it

279
00:14:14.080 --> 00:14:16.720
<v Speaker 2>can expose a complete list of IP host name pairs

280
00:14:16.720 --> 00:14:19.639
<v Speaker 2>within a network, basically gives the attacker a map of

281
00:14:19.720 --> 00:14:21.080
<v Speaker 2>the internal network structure.

282
00:14:21.120 --> 00:14:21.960
<v Speaker 1>How do they try that?

283
00:14:22.159 --> 00:14:25.279
<v Speaker 2>Tools like dig can be used to attempt a zone transfer.

284
00:14:25.679 --> 00:14:30.480
<v Speaker 2>Other tools like dnascinum automate finding basic DNS records MX

285
00:14:30.519 --> 00:14:34.559
<v Speaker 2>for mail, NS for name servers, A records for IPS,

286
00:14:34.639 --> 00:14:37.919
<v Speaker 2>and can perform reverse lookups even brute force subdomains to

287
00:14:38.000 --> 00:14:40.080
<v Speaker 2>reveal more of the target's infrastructure.

288
00:14:40.159 --> 00:14:42.200
<v Speaker 1>So they're using search engines too, but not just for

289
00:14:42.279 --> 00:14:45.000
<v Speaker 1>finding web pages, right, They're digging deeper exactly.

290
00:14:45.320 --> 00:14:49.120
<v Speaker 2>General search engines like Google, Bing, Duck, dot coo. They

291
00:14:49.159 --> 00:14:52.120
<v Speaker 2>allow these advanced search filters. People call them Google dorks.

292
00:14:52.159 --> 00:14:53.279
<v Speaker 1>Google dorks. Yeah.

293
00:14:53.759 --> 00:14:56.799
<v Speaker 2>They let an attacker find specific file types, maybe error

294
00:14:56.840 --> 00:15:00.679
<v Speaker 2>messages containing sensitive info or specific text in URLs that

295
00:15:00.799 --> 00:15:05.600
<v Speaker 2>might reveal misconfigurations. Offensive Security actually maintains a public Google

296
00:15:05.600 --> 00:15:07.559
<v Speaker 2>hacking database full of these techniques.

297
00:15:07.639 --> 00:15:10.799
<v Speaker 1>Okay, but then there's Showdan that sounds completely different, almost

298
00:15:10.840 --> 00:15:11.399
<v Speaker 1>like sci fi.

299
00:15:11.720 --> 00:15:13.759
<v Speaker 2>Showdan really is a different kind of search engine. It

300
00:15:13.759 --> 00:15:16.639
<v Speaker 2>doesn't look for web content. It searches for devices connected

301
00:15:16.679 --> 00:15:20.799
<v Speaker 2>to the Internet, devices like what like everything, industrial control systems,

302
00:15:20.840 --> 00:15:24.960
<v Speaker 2>running power grids, CCTV cameras, baby monitors, routers, servers, you

303
00:15:25.080 --> 00:15:29.399
<v Speaker 2>name it. And what's truly surprising, maybe shocking, is the

304
00:15:29.399 --> 00:15:33.399
<v Speaker 2>sheer volume of unsecured devices it finds, often left with

305
00:15:33.480 --> 00:15:37.440
<v Speaker 2>default passwords. It's like finding the digital blueprint of a city,

306
00:15:37.519 --> 00:15:40.840
<v Speaker 2>including all its unlocked back doors, with just a search query.

307
00:15:41.240 --> 00:15:44.240
<v Speaker 1>That's kind of terrifying. Are there tools that help automate

308
00:15:44.279 --> 00:15:46.840
<v Speaker 1>gathering info from all these different sources? Yeah.

309
00:15:46.879 --> 00:15:49.519
<v Speaker 2>The Harvester is a Collie tool that acts as a rapper.

310
00:15:49.759 --> 00:15:53.720
<v Speaker 2>It queries various search engines to pull together emails, subdomains,

311
00:15:53.799 --> 00:15:57.279
<v Speaker 2>virtual hosts, open ports related to a target, sort of

312
00:15:57.320 --> 00:16:01.519
<v Speaker 2>aggregator exactly. And another powerful frame work is recon. It

313
00:16:01.519 --> 00:16:05.120
<v Speaker 2>consolidates lots of information gathering modules like it can look

314
00:16:05.159 --> 00:16:08.919
<v Speaker 2>up multiple domains hosted on a single SSL certificate or

315
00:16:09.039 --> 00:16:12.159
<v Speaker 2>enumerate LinkedIn contacts associated with a target company.

316
00:16:12.320 --> 00:16:15.159
<v Speaker 1>Okay, so once they'd gathered all this initial intelligence, the

317
00:16:15.200 --> 00:16:19.440
<v Speaker 1>next phase is usually scanning, right actively probing the target

318
00:16:19.519 --> 00:16:22.799
<v Speaker 1>to see what's actually running and where the potential doors are. Correct.

319
00:16:22.879 --> 00:16:25.799
<v Speaker 2>The scanning phase is about identifying the operating system, the

320
00:16:25.840 --> 00:16:30.120
<v Speaker 2>web server version, the underlying infrastructure, specific applications.

321
00:16:29.519 --> 00:16:31.159
<v Speaker 1>Running, starting with open ports.

322
00:16:31.639 --> 00:16:36.000
<v Speaker 2>Usually yes, finding open ports beyond the standard eighty for

323
00:16:36.159 --> 00:16:39.559
<v Speaker 2>HTTP and four forty three for hdtps because other services

324
00:16:39.639 --> 00:16:40.480
<v Speaker 2>might be exposed.

325
00:16:40.879 --> 00:16:44.360
<v Speaker 1>And for port scanning, the most famous tool is probably

326
00:16:44.600 --> 00:16:44.919
<v Speaker 1>end map.

327
00:16:45.120 --> 00:16:49.000
<v Speaker 2>It's legendary enmap network map er. Yes, it's absolutely the

328
00:16:49.000 --> 00:16:52.039
<v Speaker 2>most widely known port scanner and a cornerstone of reconnaissance

329
00:16:52.080 --> 00:16:55.960
<v Speaker 2>and scanning. It's incredibly effective at finding open TCP and

330
00:16:56.080 --> 00:16:59.919
<v Speaker 2>UDP ports, and it's constantly updated. By default, it just

331
00:17:00.120 --> 00:17:03.639
<v Speaker 2>checks the top one thousand most common ports to speed

332
00:17:03.639 --> 00:17:04.079
<v Speaker 2>things up.

333
00:17:04.160 --> 00:17:06.200
<v Speaker 1>How does it actually figure out if a port is open?

334
00:17:06.279 --> 00:17:08.759
<v Speaker 1>Are there different ways it connects? Maybe some sneakier than others.

335
00:17:08.960 --> 00:17:12.000
<v Speaker 2>Yeah, there are different scan types. The most straightforward is

336
00:17:12.039 --> 00:17:15.279
<v Speaker 2>the TCP connect scan. Using the NZST flag, it performs

337
00:17:15.319 --> 00:17:17.799
<v Speaker 2>a full three way TCP handshake.

338
00:17:17.440 --> 00:17:19.039
<v Speaker 1>Like a normal connection exactly.

339
00:17:19.160 --> 00:17:22.079
<v Speaker 2>It's accurate, but it's also more likely to be logged

340
00:17:22.079 --> 00:17:23.519
<v Speaker 2>at the target machine and slower.

341
00:17:23.680 --> 00:17:25.319
<v Speaker 1>Okay, what's the stealthier option.

342
00:17:25.640 --> 00:17:28.720
<v Speaker 2>That's the syn scan using SSS, often called a half

343
00:17:28.759 --> 00:17:31.319
<v Speaker 2>open scan. It starts the handshake but does not complete

344
00:17:31.319 --> 00:17:31.759
<v Speaker 2>the handshake.

345
00:17:31.839 --> 00:17:33.640
<v Speaker 1>Ah, so it doesn't fully connect right.

346
00:17:33.960 --> 00:17:36.799
<v Speaker 2>This makes it less likely to be logged by basic firewalls,

347
00:17:37.400 --> 00:17:41.039
<v Speaker 2>but those initial syn packets can still definitely alert more

348
00:17:41.079 --> 00:17:45.240
<v Speaker 2>advanced intrusion detection or prevention systems in IPS or IDs.

349
00:17:45.319 --> 00:17:48.000
<v Speaker 1>And you mentioned saving results before, Why is that so

350
00:17:48.079 --> 00:17:49.279
<v Speaker 1>critical for a pent tester?

351
00:17:49.720 --> 00:17:53.559
<v Speaker 2>Oh, in a pentest, saving results is absolutely vital for organization,

352
00:17:53.759 --> 00:17:56.359
<v Speaker 2>for building that final report and honestly as a backup

353
00:17:56.400 --> 00:17:59.240
<v Speaker 2>if something goes wrong or a scan gets interrupted. And

354
00:17:59.319 --> 00:18:02.440
<v Speaker 2>map lets use save results in different formats XML its

355
00:18:02.440 --> 00:18:06.039
<v Speaker 2>own format, agrippable text format so you can easily parse

356
00:18:06.039 --> 00:18:07.480
<v Speaker 2>and reuse that data later.

357
00:18:07.720 --> 00:18:10.640
<v Speaker 1>So beyond just finding open ports, they're profiling the whole

358
00:18:10.680 --> 00:18:12.720
<v Speaker 1>server setup. What kind of details that they're looking for?

359
00:18:12.759 --> 00:18:15.400
<v Speaker 2>Then, yeah, exactly. Once you know the OS and the

360
00:18:15.400 --> 00:18:18.680
<v Speaker 2>open ports, the next step is identifying the exact applications

361
00:18:18.759 --> 00:18:22.759
<v Speaker 2>running is it apatche icojinc Serving web pages what web

362
00:18:22.799 --> 00:18:26.279
<v Speaker 2>application frameworks are they using, PHP, dot Net, Java? What

363
00:18:26.400 --> 00:18:29.960
<v Speaker 2>databases are behind it? Are there load balancers involved? Getting

364
00:18:30.000 --> 00:18:32.200
<v Speaker 2>this level of detail is critical for picking the right

365
00:18:32.240 --> 00:18:33.480
<v Speaker 2>potential exploits later on.

366
00:18:33.799 --> 00:18:36.920
<v Speaker 1>How do they deal with situations where maybe multiple websites

367
00:18:36.960 --> 00:18:39.559
<v Speaker 1>are sharing the same server. That seems like it could

368
00:18:39.559 --> 00:18:40.519
<v Speaker 1>be confusing.

369
00:18:40.240 --> 00:18:44.359
<v Speaker 2>Yeah, that's common. Many websites use name based virtual hosting,

370
00:18:44.640 --> 00:18:48.839
<v Speaker 2>sharing one physical server and IP address. They're distinguished by

371
00:18:48.839 --> 00:18:51.960
<v Speaker 2>the host header in the HTTP request that tells the

372
00:18:52.000 --> 00:18:54.440
<v Speaker 2>server which specific site you're trying to reach.

373
00:18:54.640 --> 00:18:56.279
<v Speaker 1>So how do they figure out what else is on

374
00:18:56.319 --> 00:18:56.720
<v Speaker 1>that server?

375
00:18:57.079 --> 00:19:00.920
<v Speaker 2>There are online tools like HTTP dot ipnables is one

376
00:19:00.960 --> 00:19:04.000
<v Speaker 2>example that can help identify other websites hosted on the

377
00:19:04.039 --> 00:19:07.319
<v Speaker 2>same IP. It helps reveal more of a target's overall

378
00:19:07.359 --> 00:19:08.240
<v Speaker 2>digital footprint.

379
00:19:08.480 --> 00:19:11.440
<v Speaker 1>And load balancers you mentioned them? Can those sometimes give

380
00:19:11.480 --> 00:19:12.799
<v Speaker 1>away useful information too?

381
00:19:13.000 --> 00:19:16.359
<v Speaker 2>They absolutely can. High traffic sites use load balancers to

382
00:19:16.400 --> 00:19:19.759
<v Speaker 2>distribute requests and keep things available. Some cookie based load

383
00:19:19.759 --> 00:19:22.160
<v Speaker 2>balancers put a cookie in your browser to keep you

384
00:19:22.200 --> 00:19:26.279
<v Speaker 2>stuck to one specific back end server. Okay, Sometimes these

385
00:19:26.319 --> 00:19:30.519
<v Speaker 2>cookies accidentally reveal critical server details, maybe encoded pool names

386
00:19:30.640 --> 00:19:33.319
<v Speaker 2>or even internal IP addresses and ports of the back

387
00:19:33.440 --> 00:19:36.680
<v Speaker 2>end servers things they really should not be doing. It's

388
00:19:36.720 --> 00:19:39.039
<v Speaker 2>an often overlooked reconnaissance.

389
00:19:38.400 --> 00:19:42.680
<v Speaker 1>Source fascinating little leaks of information. So what about figuring

390
00:19:42.680 --> 00:19:45.680
<v Speaker 1>out the actual web application frameworks being used? Is that

391
00:19:45.720 --> 00:19:46.519
<v Speaker 1>just guesswork? Oh?

392
00:19:46.519 --> 00:19:49.240
<v Speaker 2>No, not at all. There are several clues pen testers

393
00:19:49.279 --> 00:19:53.000
<v Speaker 2>look for. HTTP headers like the server header or maybe

394
00:19:53.000 --> 00:19:57.359
<v Speaker 2>an xass net version header can directly reveal the tech stack. Okay,

395
00:19:57.440 --> 00:20:00.359
<v Speaker 2>custom cookie set by frameworks like asp not netw or

396
00:20:00.480 --> 00:20:04.279
<v Speaker 2>JSESSIOND for Java apps can also be giveaways. Even seemingly

397
00:20:04.319 --> 00:20:07.559
<v Speaker 2>harmless comments left in the HTML source code can sometimes

398
00:20:07.599 --> 00:20:10.440
<v Speaker 2>contain hints about the framework or libraries being used.

399
00:20:10.559 --> 00:20:13.519
<v Speaker 1>And for automating the identification of these technologies, is there

400
00:20:13.559 --> 00:20:15.960
<v Speaker 1>a quick Collie tool for that? What?

401
00:20:16.160 --> 00:20:18.880
<v Speaker 2>Web scanner in Collie is excellent for this. It has

402
00:20:18.960 --> 00:20:21.640
<v Speaker 2>over nine hundred plug ins to identify all sorts of

403
00:20:21.640 --> 00:20:27.079
<v Speaker 2>web technologies, CMS platforms, analytics packages, javscript libraries, server versions.

404
00:20:27.119 --> 00:20:29.240
<v Speaker 2>It gives you a quick, high level overview of the

405
00:20:29.279 --> 00:20:29.759
<v Speaker 2>tech stact.

406
00:20:29.799 --> 00:20:32.519
<v Speaker 1>Okay, so they've profiled the server, the frameworks. Now they

407
00:20:32.559 --> 00:20:36.319
<v Speaker 1>start actively looking for misconfigurations and specific vulnerabilities.

408
00:20:36.720 --> 00:20:40.279
<v Speaker 2>Yes, that's the next logical step analyzing the software and

409
00:20:40.319 --> 00:20:44.359
<v Speaker 2>its configuration. Default settings are often a gold mine for vulnerabilities.

410
00:20:44.720 --> 00:20:47.960
<v Speaker 2>Scanning tools help by crawling the entire website looking for

411
00:20:48.039 --> 00:20:52.119
<v Speaker 2>interesting files, folders, configuration settings that might point to a weakness.

412
00:20:52.519 --> 00:20:55.720
<v Speaker 1>How do they check things like what HTTP methods of

413
00:20:55.799 --> 00:20:59.319
<v Speaker 1>server supports? Like can it accept a delete request when

414
00:20:59.319 --> 00:20:59.920
<v Speaker 1>it really should?

415
00:21:00.640 --> 00:21:03.160
<v Speaker 2>They can use tools like netcat with the options method

416
00:21:03.240 --> 00:21:06.079
<v Speaker 2>to directly ask the server what methods it supports. Nmap

417
00:21:06.160 --> 00:21:09.000
<v Speaker 2>can do this too. Beyond that, Metasplait has some really

418
00:21:09.079 --> 00:21:13.960
<v Speaker 2>useful auxiliary modules like darlisting checks if directory browsing is enabled.

419
00:21:14.160 --> 00:21:17.079
<v Speaker 2>Der Scanner looks for interesting directories or inm wayback queries

420
00:21:17.119 --> 00:21:19.960
<v Speaker 2>the Internet archive for old regions of pages that might

421
00:21:20.000 --> 00:21:23.279
<v Speaker 2>contain now on linked content or comments. These can reveal

422
00:21:23.319 --> 00:21:26.279
<v Speaker 2>forgotten dev folders or old vulnerable scripts.

423
00:21:26.319 --> 00:21:30.880
<v Speaker 1>Okay, let's shift focus slightly to HTTPS configuration obviously critical

424
00:21:30.920 --> 00:21:32.480
<v Speaker 1>for protecting sensitive data.

425
00:21:32.279 --> 00:21:36.119
<v Speaker 2>And transit absolutely critical. HTTP started as clear text right

426
00:21:36.240 --> 00:21:42.799
<v Speaker 2>everything sent and ENCRYPTEDHGTPS HTTP over SSLTLS adds that encrypted channel. Now,

427
00:21:42.839 --> 00:21:46.920
<v Speaker 2>technically SSL is deprecated and TLS currently TLS one point

428
00:21:46.920 --> 00:21:49.559
<v Speaker 2>two or one point three is the standard, but many

429
00:21:49.599 --> 00:21:53.279
<v Speaker 2>sites still support older weaker versions for backward compatibility, which

430
00:21:53.279 --> 00:21:54.400
<v Speaker 2>can be a problem.

431
00:21:54.079 --> 00:21:58.480
<v Speaker 1>And TLS provides that CIA triad right confidentiality.

432
00:21:57.680 --> 00:22:03.000
<v Speaker 2>Confidentiality, integrity, and availability, yes, the core pillars of infosect.

433
00:22:03.319 --> 00:22:07.359
<v Speaker 2>It also provides non repudiation through TLS certificates signed by

434
00:22:07.440 --> 00:22:11.079
<v Speaker 2>certificate authorities or CAAs, meaning you can generally trust the

435
00:22:11.119 --> 00:22:13.359
<v Speaker 2>identity of the survey you're talking to and they can't

436
00:22:13.359 --> 00:22:16.000
<v Speaker 2>easily deny the communication happen. It builds trust.

437
00:22:16.559 --> 00:22:19.279
<v Speaker 1>But I've heard about NL cipher's being a massive flaw here.

438
00:22:19.319 --> 00:22:22.119
<v Speaker 1>That sounds like an oxymoron. An NL cipher in a

439
00:22:22.160 --> 00:22:23.319
<v Speaker 1>secure connection.

440
00:22:23.000 --> 00:22:26.319
<v Speaker 2>It's a really insidious flaw. If NL ciphers are enabled

441
00:22:26.319 --> 00:22:28.920
<v Speaker 2>on the server and get chosen during the connection negotiation,

442
00:22:29.279 --> 00:22:32.200
<v Speaker 2>your browser might still show that reassuring padlock icon, but

443
00:22:33.039 --> 00:22:37.720
<v Speaker 2>the HDP data will actually be transmitted in cleartext, completely unencrypted.

444
00:22:37.759 --> 00:22:41.240
<v Speaker 2>It's a total false sense of security leaving sensitive info

445
00:22:41.319 --> 00:22:41.839
<v Speaker 2>wide open.

446
00:22:41.920 --> 00:22:44.920
<v Speaker 1>Wow. So it's not just about having HTTPS, but having

447
00:22:44.960 --> 00:22:46.680
<v Speaker 1>it configured correctly precisely.

448
00:22:46.799 --> 00:22:50.359
<v Speaker 2>Tools like the open SSL command line utility ss scan,

449
00:22:50.440 --> 00:22:53.759
<v Speaker 2>which can show the ciphers and certificate details, and sslies

450
00:22:53.839 --> 00:22:57.960
<v Speaker 2>are essential for testing these configurations. N MAP also has

451
00:22:58.000 --> 00:23:02.759
<v Speaker 2>scripts like SSL inomsideiers to identify supported cipher suites and

452
00:23:02.839 --> 00:23:07.400
<v Speaker 2>flag known vulnerabilities like crime or poodle associated with weak configurations.

453
00:23:07.480 --> 00:23:10.720
<v Speaker 1>Okay, what about spidering web applications? That's about mapping out

454
00:23:10.720 --> 00:23:12.279
<v Speaker 1>the whole site structure exactly.

455
00:23:12.599 --> 00:23:15.200
<v Speaker 2>Trying to do that manually, especially on a complex site,

456
00:23:15.240 --> 00:23:18.519
<v Speaker 2>is just time consuming and prone to emissions. It's really inefficient.

457
00:23:18.599 --> 00:23:20.559
<v Speaker 1>So automation definitely.

458
00:23:20.279 --> 00:23:23.200
<v Speaker 2>College provides tools for this. BURP Spider, which is part

459
00:23:23.240 --> 00:23:26.400
<v Speaker 2>of the popular burp suite, is well known and very effective.

460
00:23:26.720 --> 00:23:29.880
<v Speaker 2>It automates mapping the entire application, and it can even

461
00:23:29.920 --> 00:23:32.880
<v Speaker 2>handle login authentication to map out areas hidden behind a

462
00:23:32.920 --> 00:23:34.920
<v Speaker 2>login page that a public spider would miss.

463
00:23:35.000 --> 00:23:39.480
<v Speaker 1>And then there's directory brute forcing or forced brows. What's

464
00:23:39.519 --> 00:23:40.240
<v Speaker 1>the idea there?

465
00:23:40.319 --> 00:23:44.000
<v Speaker 2>That's about requesting files and directories that aren't directly linked

466
00:23:44.000 --> 00:23:47.720
<v Speaker 2>anywhere in the application. You basically guess common names from.

467
00:23:47.599 --> 00:23:49.160
<v Speaker 1>A dictionary file. Why do that?

468
00:23:49.599 --> 00:23:53.440
<v Speaker 2>Because it can uncover hidden test environments, forgotten backup files,

469
00:23:53.519 --> 00:23:56.960
<v Speaker 2>administrative pages, configuration files, things that were never meant to

470
00:23:56.960 --> 00:23:59.680
<v Speaker 2>be public but might still be accessible if you guess

471
00:23:59.720 --> 00:24:04.440
<v Speaker 2>the url DIRB and COLLI is a prime tool for this,

472
00:24:04.920 --> 00:24:08.200
<v Speaker 2>it can scan recursively and even use session cookies if

473
00:24:08.240 --> 00:24:09.920
<v Speaker 2>you need to be authenticated.

474
00:24:10.079 --> 00:24:13.480
<v Speaker 1>Okay, we've covered the meticulous reconnaissance in scanning. Let's really

475
00:24:13.559 --> 00:24:18.240
<v Speaker 1>unpack the actual vulnerabilities attackers exploit, starting with authentication and

476
00:24:18.319 --> 00:24:21.559
<v Speaker 1>session management flaws. Why are these so incredibly common?

477
00:24:21.680 --> 00:24:26.920
<v Speaker 2>Well, the core problem really lies in HTTP's statelessness. It's

478
00:24:26.920 --> 00:24:30.279
<v Speaker 2>what now statelessness? Think of it like a forgetful waiter.

479
00:24:30.519 --> 00:24:32.240
<v Speaker 2>Every time you make a request to a web server,

480
00:24:32.319 --> 00:24:35.440
<v Speaker 2>it treats it as a brand new interaction, completely unrelated to.

481
00:24:35.400 --> 00:24:36.000
<v Speaker 1>The last one.

482
00:24:36.039 --> 00:24:39.519
<v Speaker 2>Ah, okay, no memory exactly. So this means we need

483
00:24:39.599 --> 00:24:43.400
<v Speaker 2>session management mechanisms to track user activity, like knowing you're

484
00:24:43.440 --> 00:24:47.160
<v Speaker 2>logged in without forcing you to reauthenticate with every single click.

485
00:24:47.279 --> 00:24:48.400
<v Speaker 1>Right, So how does that work?

486
00:24:48.799 --> 00:24:53.279
<v Speaker 2>Usually through things like unique session identifiers, maybe inactivity timeouts,

487
00:24:53.440 --> 00:24:57.200
<v Speaker 2>session expiration times, and making sure sessions are invalidated when

488
00:24:57.200 --> 00:24:58.839
<v Speaker 2>you explicitly log out.

489
00:24:59.079 --> 00:25:02.200
<v Speaker 1>And what kinds of authentication methods are pen testers usually

490
00:25:02.200 --> 00:25:03.480
<v Speaker 1>looking at? Well.

491
00:25:03.519 --> 00:25:08.119
<v Speaker 2>While HTTP supports older methods like basic digest and NTLM,

492
00:25:08.160 --> 00:25:11.839
<v Speaker 2>which are ways for browsers to send credentials, honestly, form

493
00:25:11.880 --> 00:25:15.640
<v Speaker 2>based authentication is by far the most interesting for pen testers.

494
00:25:15.759 --> 00:25:16.559
<v Speaker 1>Why that one?

495
00:25:16.880 --> 00:25:19.519
<v Speaker 2>Because it's custom built for pretty much every application. There's

496
00:25:19.519 --> 00:25:22.720
<v Speaker 2>no single standard. That means there are way more opportunities

497
00:25:22.720 --> 00:25:26.160
<v Speaker 2>for developers to make mistakes leading to flawed implementations.

498
00:25:26.359 --> 00:25:29.799
<v Speaker 1>Makes sense, more custom cold, more potential bugs exactly.

499
00:25:29.960 --> 00:25:33.720
<v Speaker 2>Though increasingly you see things like two factor authentication MFA

500
00:25:34.160 --> 00:25:37.680
<v Speaker 2>adding an extra layer of security and ooh for letting

501
00:25:37.759 --> 00:25:41.160
<v Speaker 2>third party apps access resources without you actually sharing your

502
00:25:41.160 --> 00:25:41.960
<v Speaker 2>password with them.

503
00:25:42.240 --> 00:25:44.160
<v Speaker 1>So what are some of the most common flaws pen

504
00:25:44.240 --> 00:25:48.640
<v Speaker 1>testers find in these authentication and session management processes? Where

505
00:25:48.640 --> 00:25:49.920
<v Speaker 1>do things go wrong? Oh?

506
00:25:50.039 --> 00:25:51.759
<v Speaker 2>A big one is username enumeration.

507
00:25:52.119 --> 00:25:52.519
<v Speaker 1>What's that?

508
00:25:52.839 --> 00:25:56.880
<v Speaker 2>This happens when an application gives away excessive information. Maybe

509
00:25:56.880 --> 00:25:59.599
<v Speaker 2>it shows a different error message if you enter a

510
00:25:59.640 --> 00:26:02.279
<v Speaker 2>valid user name with the wrong password compared to an

511
00:26:02.279 --> 00:26:03.240
<v Speaker 2>invalid username.

512
00:26:03.359 --> 00:26:05.799
<v Speaker 1>Ah, so the attacker can tell which user names are

513
00:26:05.799 --> 00:26:08.319
<v Speaker 1>real just by the error message. Exactly.

514
00:26:08.480 --> 00:26:10.799
<v Speaker 2>It allows an attacker to methodically build a list of

515
00:26:10.880 --> 00:26:14.680
<v Speaker 2>valid usernames. We can see this demonstrated really effectively using

516
00:26:14.720 --> 00:26:18.680
<v Speaker 2>tools like burp Suite against vulnerable practice apps like a wasp,

517
00:26:18.680 --> 00:26:19.599
<v Speaker 2>plub cooat and.

518
00:26:19.559 --> 00:26:22.240
<v Speaker 1>Weak passwords still a massive issue, I imagine.

519
00:26:22.279 --> 00:26:26.039
<v Speaker 2>Oh, absolutely sadly, yes, the prevalence of weak passwords that

520
00:26:26.079 --> 00:26:30.400
<v Speaker 2>you have things from those most used passwords lists like one, two, three, four, five, six,

521
00:26:30.519 --> 00:26:33.920
<v Speaker 2>or password or quarity. It remains a huge problem.

522
00:26:34.000 --> 00:26:37.680
<v Speaker 1>So how do pangesters approach testing that without getting locked out?

523
00:26:38.000 --> 00:26:41.160
<v Speaker 2>Well? A good approach for conducting online attacks is to

524
00:26:41.240 --> 00:26:45.720
<v Speaker 2>try maybe just a few common passwords per username, then pause,

525
00:26:45.920 --> 00:26:48.279
<v Speaker 2>wait a bit, and try a few more. This helps

526
00:26:48.319 --> 00:26:50.799
<v Speaker 2>avoid triggering account lockout mechanisms.

527
00:26:50.839 --> 00:26:54.920
<v Speaker 1>What about password reset or recovery functions? Those often feel

528
00:26:54.920 --> 00:26:56.079
<v Speaker 1>like a potential weak link.

529
00:26:56.519 --> 00:26:59.480
<v Speaker 2>You're right, they often are. There's an important difference between

530
00:26:59.680 --> 00:27:03.000
<v Speaker 2>recovery where you somehow get your old password back, which

531
00:27:03.079 --> 00:27:06.480
<v Speaker 2>usually implies a major security flaw like storing it in.

532
00:27:06.480 --> 00:27:09.000
<v Speaker 1>Clear text, which should never happen never.

533
00:27:09.000 --> 00:27:11.640
<v Speaker 2>And reset where you set a new one. But the

534
00:27:11.759 --> 00:27:14.799
<v Speaker 2>risks in reset functions include things like maybe being able

535
00:27:14.839 --> 00:27:17.519
<v Speaker 2>to spoof the email or phone number where the reset

536
00:27:17.519 --> 00:27:21.160
<v Speaker 2>link is sent, or finding predictable reset links that include

537
00:27:21.160 --> 00:27:24.759
<v Speaker 2>something easily guessable or exploitable like a user ID.

538
00:27:24.759 --> 00:27:28.079
<v Speaker 1>And predictable session IDs. How does an attacker leverage that?

539
00:27:28.160 --> 00:27:29.279
<v Speaker 1>I assume they should be random.

540
00:27:29.440 --> 00:27:33.319
<v Speaker 2>They absolutely need to be random and unpredictable if they aren't.

541
00:27:33.359 --> 00:27:36.160
<v Speaker 2>Maybe they're based on sequential numbers or the time, or

542
00:27:36.279 --> 00:27:40.519
<v Speaker 2>something easily guessable. An attacker can potentially hijack a valid

543
00:27:40.599 --> 00:27:44.240
<v Speaker 2>user session just by predicting a valid ID. Tools like

544
00:27:44.279 --> 00:27:47.880
<v Speaker 2>burp sequencer can analyze session IDs and show how easily

545
00:27:47.920 --> 00:27:50.920
<v Speaker 2>a weak one like a cookie named wicked based on

546
00:27:50.960 --> 00:27:52.680
<v Speaker 2>sequential numbers can be predicted.

547
00:27:52.920 --> 00:27:55.200
<v Speaker 1>So how do we prevent all these issues you mentioned earlier?

548
00:27:55.240 --> 00:27:58.880
<v Speaker 1>There's no single universal solution, no.

549
00:27:58.440 --> 00:28:01.720
<v Speaker 2>No universal solution has been found, unfortunately, but there are

550
00:28:01.839 --> 00:28:06.559
<v Speaker 2>key preventions. Enforcing strong password policies is fundamental, length, mixed

551
00:28:06.599 --> 00:28:11.119
<v Speaker 2>case special characters, blocking common patterns or sequences always using

552
00:28:11.160 --> 00:28:15.039
<v Speaker 2>TLS for login pages is non negotiable. To protect credentials

553
00:28:15.079 --> 00:28:19.000
<v Speaker 2>in transit. Using generic error messages during login is crucial

554
00:28:19.039 --> 00:28:22.599
<v Speaker 2>to prevent that user name enumeration. We talked about implementing

555
00:28:22.640 --> 00:28:26.440
<v Speaker 2>brute force lockouts like maybe five failed attempts triggers A

556
00:28:26.440 --> 00:28:30.000
<v Speaker 2>twenty thirty minute lockout helps slow down automated attacks. For

557
00:28:30.039 --> 00:28:33.240
<v Speaker 2>password resets, sending one time expiring links to the user's

558
00:28:33.319 --> 00:28:36.079
<v Speaker 2>registered email or SMS is best practice.

559
00:28:36.279 --> 00:28:39.319
<v Speaker 1>And those session cookies themselves, how can they be hardened?

560
00:28:39.599 --> 00:28:41.839
<v Speaker 2>Making sure all the security flags are set on session

561
00:28:41.839 --> 00:28:45.160
<v Speaker 2>cookies is vital. The secure flag ensures the cookie is

562
00:28:45.240 --> 00:28:50.079
<v Speaker 2>only ever sent over an HTTPS connection. HTTP only is critical.

563
00:28:50.119 --> 00:28:53.599
<v Speaker 2>It prevents client side JavaScript from accessing the cookie. This

564
00:28:53.799 --> 00:28:56.720
<v Speaker 2>massively mitigates the impact if an attacker does find an

565
00:28:56.759 --> 00:29:00.519
<v Speaker 2>excess vulnerability, because they can't easily steal the session cookie.

566
00:29:01.119 --> 00:29:04.839
<v Speaker 2>Point setting cookies as non persistent so they expire when

567
00:29:04.839 --> 00:29:09.400
<v Speaker 2>the browser closes. Using expires or maxage attributes, restricting the

568
00:29:09.400 --> 00:29:12.000
<v Speaker 2>path attributes so the cookies only sent where needed and

569
00:29:12.119 --> 00:29:15.480
<v Speaker 2>using the same site attribute provides extra protection against cross

570
00:29:15.480 --> 00:29:17.559
<v Speaker 2>site request forgery CSRF.

571
00:29:18.119 --> 00:29:21.519
<v Speaker 1>Okay, let's move on to injection based flaws. This sounds

572
00:29:21.559 --> 00:29:25.160
<v Speaker 1>like we're an attacker actively shoves malicious data into the application.

573
00:29:25.440 --> 00:29:28.880
<v Speaker 2>That's the core idea. Yeah, the attacker finds an input field,

574
00:29:28.880 --> 00:29:32.720
<v Speaker 2>search box, log in form, urlo, parameter, whatever, and injects

575
00:29:32.799 --> 00:29:36.319
<v Speaker 2>malicious data. The goal is to trick the application into

576
00:29:36.359 --> 00:29:39.720
<v Speaker 2>sending that bad data to some underlying component like a

577
00:29:39.799 --> 00:29:42.920
<v Speaker 2>database or the command line or an XMEL parser, and

578
00:29:43.000 --> 00:29:45.359
<v Speaker 2>make that component execute unintended actions.

579
00:29:45.519 --> 00:29:47.519
<v Speaker 1>Can you give me an example. What's command injection?

580
00:29:47.720 --> 00:29:50.839
<v Speaker 2>Okay? Command injection? Imagine a web page that lets you

581
00:29:50.880 --> 00:29:53.720
<v Speaker 2>ping an IP address you enter one twenty seven dot

582
00:29:53.799 --> 00:29:56.799
<v Speaker 2>zero zero dot one. But what if you enter one

583
00:29:57.039 --> 00:30:01.119
<v Speaker 2>seven dot zero dot zero dot zero one hone email Anyway,

584
00:30:01.279 --> 00:30:03.920
<v Speaker 2>that's a Linux command to show system information. If the

585
00:30:03.960 --> 00:30:07.319
<v Speaker 2>application doesn't properly validate the input and just blindly passes

586
00:30:07.359 --> 00:30:09.319
<v Speaker 2>it to the server's command line, it runs the extra

587
00:30:09.319 --> 00:30:13.359
<v Speaker 2>command exactly. It executes NIEMA on the server. You might

588
00:30:13.400 --> 00:30:16.160
<v Speaker 2>get a non interactive shell. You can run commands, see

589
00:30:16.200 --> 00:30:19.720
<v Speaker 2>the output, but can't interact further. Or sometimes it's blind

590
00:30:19.759 --> 00:30:22.079
<v Speaker 2>command injection where you don't see any output, so you

591
00:30:22.119 --> 00:30:24.240
<v Speaker 2>have to rely on side effects like making the server

592
00:30:24.319 --> 00:30:26.960
<v Speaker 2>pin your machine to confirm the injection work. The famous

593
00:30:26.960 --> 00:30:29.319
<v Speaker 2>shell shock vulnerability a few years back was a huge

594
00:30:29.319 --> 00:30:31.599
<v Speaker 2>example of this, where the bash shell itself.

595
00:30:31.240 --> 00:30:35.720
<v Speaker 1>Was vulnerable right and SQL injection scooply. That's probably the

596
00:30:35.720 --> 00:30:38.240
<v Speaker 1>most famous injection flaw. Hasn't it been around forever?

597
00:30:38.359 --> 00:30:42.079
<v Speaker 2>Yes, Sequel injection squall is incredibly common and has certainly

598
00:30:42.119 --> 00:30:45.920
<v Speaker 2>stood the test of time. The vulnerability happens when user

599
00:30:45.960 --> 00:30:49.920
<v Speaker 2>input is concatenated directly into a SQL query without being

600
00:30:49.920 --> 00:30:52.359
<v Speaker 2>properly validated or sanitized first.

601
00:30:52.359 --> 00:30:55.559
<v Speaker 1>So the attacker's input becomes part of the database command precisely.

602
00:30:56.079 --> 00:30:59.519
<v Speaker 2>This allows them to execute malicious SEQUL commands directly against

603
00:30:59.559 --> 00:31:02.599
<v Speaker 2>the database, and it's crucial to remember the flaw is

604
00:31:02.680 --> 00:31:06.000
<v Speaker 2>almost always in the web applications code that handles the input,

605
00:31:06.160 --> 00:31:08.000
<v Speaker 2>not usually in the database server itself.

606
00:31:08.160 --> 00:31:10.680
<v Speaker 1>How do pen testers actually test for that? How they

607
00:31:10.720 --> 00:31:12.960
<v Speaker 1>poke it an input field to see if it's vulnerable.

608
00:31:13.119 --> 00:31:16.400
<v Speaker 2>They often start by injecting characters like a single quote

609
00:31:16.440 --> 00:31:18.720
<v Speaker 2>to see if it breaks the query and causes an error.

610
00:31:19.160 --> 00:31:23.680
<v Speaker 2>Then they'll try injecting modified select statements, often using union queries.

611
00:31:24.039 --> 00:31:24.319
<v Speaker 1>Yeah.

612
00:31:24.440 --> 00:31:27.640
<v Speaker 2>Union lets you combine the results of two select queries,

613
00:31:28.200 --> 00:31:30.880
<v Speaker 2>so an attacker can craft a query that returns the

614
00:31:30.920 --> 00:31:34.920
<v Speaker 2>normal application data plus extra data they want, like database names,

615
00:31:35.000 --> 00:31:38.880
<v Speaker 2>table names, column names, often by queering system tables like

616
00:31:38.920 --> 00:31:41.519
<v Speaker 2>information schema in myseql or postgress. Wooll.

617
00:31:41.880 --> 00:31:44.160
<v Speaker 1>What if the server doesn't conveniently spit back the data

618
00:31:44.160 --> 00:31:46.160
<v Speaker 1>in an error message or on the page. Is that

619
00:31:46.160 --> 00:31:47.359
<v Speaker 1>where blind cooming comes in again?

620
00:31:47.559 --> 00:31:51.720
<v Speaker 2>Exactly? That's blind seql injection. Since the server doesn't directly

621
00:31:51.759 --> 00:31:56.480
<v Speaker 2>reveal information, detection relies on observing more subtle responses. It

622
00:31:56.519 --> 00:31:59.680
<v Speaker 2>could be booling based asking true false questions via injected

623
00:31:59.720 --> 00:32:02.799
<v Speaker 2>query and seeing if the page content or response code

624
00:32:02.880 --> 00:32:05.720
<v Speaker 2>changes slightly, like does the admin user name start with A?

625
00:32:06.200 --> 00:32:08.799
<v Speaker 2>If yes, maybe the page looks normal. If no, maybe an.

626
00:32:08.759 --> 00:32:09.519
<v Speaker 1>Error page loads.

627
00:32:09.599 --> 00:32:12.359
<v Speaker 2>Okay, so it's inference right, Or it could be time

628
00:32:12.400 --> 00:32:15.480
<v Speaker 2>based injection. You inject a command that tells the database

629
00:32:15.519 --> 00:32:18.279
<v Speaker 2>to pause for say five seconds. If the web page

630
00:32:18.279 --> 00:32:20.519
<v Speaker 2>takes five seconds longer to load than usual, you know

631
00:32:20.599 --> 00:32:23.920
<v Speaker 2>your injection worked. It's much slower and more methodical, but

632
00:32:24.039 --> 00:32:25.359
<v Speaker 2>still very effective.

633
00:32:25.759 --> 00:32:29.559
<v Speaker 1>Are there tools to automate finding SQL because that sounds tedious? Oh?

634
00:32:29.599 --> 00:32:32.799
<v Speaker 2>Absolutely. While there are specific tools like school Ninja for

635
00:32:32.920 --> 00:32:36.880
<v Speaker 2>targeting Microsoft SQL server, often aiming for shell access, the

636
00:32:37.039 --> 00:32:39.359
<v Speaker 2>undisputed champion is school Map.

637
00:32:39.519 --> 00:32:40.759
<v Speaker 1>School Map heard of it.

638
00:32:40.759 --> 00:32:44.359
<v Speaker 2>It's an incredible automatic sequel injection tool. It can detect

639
00:32:44.359 --> 00:32:47.400
<v Speaker 2>the vulnerability, figure out the database type, exploit it to

640
00:32:47.440 --> 00:32:50.880
<v Speaker 2>dump data, and in many cases even reader write files

641
00:32:50.920 --> 00:32:54.559
<v Speaker 2>directly on the database server's operating system, or even gain

642
00:32:54.599 --> 00:32:56.880
<v Speaker 2>a command shell. It's extremely powerful.

643
00:32:56.960 --> 00:32:59.640
<v Speaker 1>Wow. Okay, what about other types of injections you mentioned?

644
00:32:59.680 --> 00:33:00.759
<v Speaker 1>XMLI right?

645
00:33:00.920 --> 00:33:05.279
<v Speaker 2>XML based injections often called XXe for XML External entity

646
00:33:05.319 --> 00:33:10.319
<v Speaker 2>injection attackers manipulate XML's tag based structure. They can define

647
00:33:10.359 --> 00:33:13.960
<v Speaker 2>these external entities that when the server processes the XML,

648
00:33:14.240 --> 00:33:17.359
<v Speaker 2>cause it to fetch and include external resources.

649
00:33:16.839 --> 00:33:18.200
<v Speaker 1>Like what kind of resources like.

650
00:33:18.200 --> 00:33:21.200
<v Speaker 2>Local files on the server such as etcter passed on Linux,

651
00:33:21.240 --> 00:33:24.000
<v Speaker 2>which contains user account info. Or they can make the

652
00:33:24.079 --> 00:33:28.079
<v Speaker 2>server make outbound network connections, potentially hitting internal systems. It

653
00:33:28.079 --> 00:33:31.039
<v Speaker 2>all depends on how the server's XML parser is configured.

654
00:33:31.200 --> 00:33:33.680
<v Speaker 1>And now that no seple databases like Mongo dB are

655
00:33:33.680 --> 00:33:36.160
<v Speaker 1>so popular, are there injection risks there too?

656
00:33:36.640 --> 00:33:40.960
<v Speaker 2>Yes, definitely no SQL injections because no circle databases often

657
00:33:41.039 --> 00:33:44.960
<v Speaker 2>use flexible query structures, sometimes based on JSON. Attackers can

658
00:33:45.000 --> 00:33:50.200
<v Speaker 2>potentially bypass authentication checks or retrieve unauthorized data by manipulating

659
00:33:50.240 --> 00:33:53.720
<v Speaker 2>the structure of the JSON request formats, leveraging how the

660
00:33:53.759 --> 00:33:56.759
<v Speaker 2>database processes queries differently from traditional SQL.

661
00:33:56.880 --> 00:33:59.519
<v Speaker 1>So it seems like the defense against all these different

662
00:33:59.559 --> 00:34:03.920
<v Speaker 1>injections types comes back to the same core principle handling

663
00:34:04.000 --> 00:34:05.000
<v Speaker 1>user inputs safely.

664
00:34:05.359 --> 00:34:07.599
<v Speaker 2>You've absolutely hit the nail on the head. The primary

665
00:34:07.640 --> 00:34:12.320
<v Speaker 2>defense is robust input validation and ideally using a whitelist

666
00:34:12.360 --> 00:34:15.440
<v Speaker 2>as lightless meaning meaning you define exactly which characters are

667
00:34:15.480 --> 00:34:17.880
<v Speaker 2>allowed for a given input field and you reject everything

668
00:34:17.920 --> 00:34:20.320
<v Speaker 2>else by default. It's much safer than trying to guess

669
00:34:20.360 --> 00:34:20.639
<v Speaker 2>all the.

670
00:34:20.559 --> 00:34:22.360
<v Speaker 1>Bad characters blacklisting. Okay.

671
00:34:22.639 --> 00:34:26.280
<v Speaker 2>Then there's sanitization, which involves carefully removing or modifying any

672
00:34:26.280 --> 00:34:30.800
<v Speaker 2>potentially dangerous characters, and encoding, which converts special characters into

673
00:34:30.840 --> 00:34:34.480
<v Speaker 2>their save representations, like converting into ANELT, so the browser

674
00:34:34.519 --> 00:34:37.079
<v Speaker 2>just displays it instead of interpreting it as HTML.

675
00:34:37.119 --> 00:34:39.880
<v Speaker 1>Where does this need to happen? Browser side? Server side?

676
00:34:40.039 --> 00:34:43.559
<v Speaker 2>The absolutely crucial part is these processes must be done

677
00:34:43.599 --> 00:34:46.679
<v Speaker 2>on both the client side and the server side. Client

678
00:34:46.719 --> 00:34:50.280
<v Speaker 2>side validation is good for user experience quick feedback, but

679
00:34:50.320 --> 00:34:53.320
<v Speaker 2>it can always be bypassed by an attacker. Server side

680
00:34:53.400 --> 00:34:56.400
<v Speaker 2>validation is where the real security happens. You need both.

681
00:34:56.719 --> 00:35:00.280
<v Speaker 1>Got it? Okay? Moving on to another huge category, site

682
00:35:00.280 --> 00:35:03.639
<v Speaker 1>scripting or XSS. What is XSS exactly and why is

683
00:35:03.679 --> 00:35:04.840
<v Speaker 1>it seemingly everywhere?

684
00:35:05.360 --> 00:35:09.840
<v Speaker 2>XSS is a type of code injection where malicious script

685
00:35:09.960 --> 00:35:13.760
<v Speaker 2>usually JavaScript, gets injected into a website, typically through user input,

686
00:35:14.119 --> 00:35:16.599
<v Speaker 2>and is then executed by the victim's web browser.

687
00:35:16.719 --> 00:35:19.119
<v Speaker 1>So the malicious code runs in my browser, not on

688
00:35:19.159 --> 00:35:20.199
<v Speaker 1>the server exactly.

689
00:35:20.280 --> 00:35:22.760
<v Speaker 2>It exploits the trust your browser has on the website

690
00:35:22.760 --> 00:35:25.840
<v Speaker 2>you're visiting. It makes the web page load and execute

691
00:35:25.840 --> 00:35:28.320
<v Speaker 2>scripts it wasn't supposed to all within the context of

692
00:35:28.360 --> 00:35:30.440
<v Speaker 2>your session on that trusted site. That's why it's so

693
00:35:30.519 --> 00:35:31.719
<v Speaker 2>pervasive and dangerous.

694
00:35:32.079 --> 00:35:34.440
<v Speaker 1>How does an attack typically work? What's the flow?

695
00:35:34.760 --> 00:35:38.599
<v Speaker 2>Okay, the typical workflow. An attacker finds a vulnerable parameter

696
00:35:38.639 --> 00:35:41.320
<v Speaker 2>on a website, maybe a search query or a comment field.

697
00:35:41.920 --> 00:35:45.760
<v Speaker 2>They craft a malicious URL or piece of content containing JavaScript.

698
00:35:46.360 --> 00:35:50.280
<v Speaker 2>Then they trick a victim into clicking that URL or viewing.

699
00:35:50.000 --> 00:35:52.320
<v Speaker 1>That content, often through phishing, I guess, very.

700
00:35:52.199 --> 00:35:53.800
<v Speaker 2>Often through targeted fishing emails.

701
00:35:53.840 --> 00:35:54.119
<v Speaker 1>Yeah.

702
00:35:54.480 --> 00:35:57.559
<v Speaker 2>When the victim clicks their browser requests the page, the

703
00:35:57.679 --> 00:36:01.119
<v Speaker 2>vulnerable application includes the attacker script in the response, and

704
00:36:01.159 --> 00:36:04.239
<v Speaker 2>the victim's browser executes it thinking it's legitimate code from

705
00:36:04.239 --> 00:36:08.599
<v Speaker 2>the website. Attackers often use URL shortening services to hide

706
00:36:08.639 --> 00:36:11.519
<v Speaker 2>the long, odd looking script and make the link look

707
00:36:11.599 --> 00:36:12.519
<v Speaker 2>less suspicious.

708
00:36:12.880 --> 00:36:17.639
<v Speaker 1>You mentioned different types reflected stored, dom based. Yeah, what's

709
00:36:17.639 --> 00:36:19.400
<v Speaker 1>the key difference between them? Good question.

710
00:36:19.519 --> 00:36:22.719
<v Speaker 2>Reflected exss is where the injected script is immediately reflected

711
00:36:22.840 --> 00:36:24.880
<v Speaker 2>back to the user from the server, maybe in a

712
00:36:25.039 --> 00:36:28.039
<v Speaker 2>search result page or an error message. It only affects

713
00:36:28.039 --> 00:36:31.679
<v Speaker 2>the user who clicks the specific malicious link stored persistent

714
00:36:31.760 --> 00:36:35.760
<v Speaker 2>EXSS is generally considered more dangerous. Here, the malicious script

715
00:36:35.800 --> 00:36:38.519
<v Speaker 2>is actually stored in the server's database, maybe in a

716
00:36:38.559 --> 00:36:41.639
<v Speaker 2>forum post, a product review, a user profile.

717
00:36:41.920 --> 00:36:45.360
<v Speaker 1>Ah So anyone who've used that page gets hit exactly.

718
00:36:45.440 --> 00:36:48.440
<v Speaker 2>It affects a large number of users automatically, without needing

719
00:36:48.440 --> 00:36:51.800
<v Speaker 2>to target each one individually. This is often how website

720
00:36:51.880 --> 00:36:54.159
<v Speaker 2>defacement happens via EXSS.

721
00:36:53.840 --> 00:36:55.880
<v Speaker 1>And DOM based. That sounds different.

722
00:36:56.199 --> 00:36:59.800
<v Speaker 2>Dom based EXSS is unique because the vulnerability isn't really

723
00:36:59.800 --> 00:37:02.920
<v Speaker 2>on the server side. The malicious script gets executed purely

724
00:37:02.960 --> 00:37:06.480
<v Speaker 2>because of how legitimate client side code JavaScript already on

725
00:37:06.480 --> 00:37:09.679
<v Speaker 2>the page handles user supplied input, often from a URL

726
00:37:09.719 --> 00:37:13.400
<v Speaker 2>fragment hashtag, and uses it to dynamically update the web

727
00:37:13.480 --> 00:37:17.239
<v Speaker 2>page's document object model or DOM. The server might never

728
00:37:17.280 --> 00:37:18.559
<v Speaker 2>even see the malicious script.

729
00:37:18.679 --> 00:37:21.199
<v Speaker 1>Can excess has happen with post requests too, not just

730
00:37:21.320 --> 00:37:23.360
<v Speaker 1>get requests where the script is in the URL.

731
00:37:23.719 --> 00:37:28.960
<v Speaker 2>Yes, absolutely, XSS via post method is possible. The script

732
00:37:28.960 --> 00:37:32.119
<v Speaker 2>would be in the body of the post request. It's

733
00:37:32.159 --> 00:37:35.159
<v Speaker 2>a bit harder for the attacker to deliver, usually requiring

734
00:37:35.239 --> 00:37:37.559
<v Speaker 2>them to get the victim to visit a malicious page

735
00:37:37.559 --> 00:37:41.599
<v Speaker 2>that automatically submits the harmful post request to the vulnerable site.

736
00:37:41.840 --> 00:37:46.239
<v Speaker 1>So, once an attacker successfully triggers an EXSS vulnerability, what

737
00:37:46.239 --> 00:37:48.280
<v Speaker 1>can they actually do with it? What's the impact?

738
00:37:48.480 --> 00:37:51.400
<v Speaker 2>The possibilities are pretty alarming because the script runs with

739
00:37:51.480 --> 00:37:54.639
<v Speaker 2>the permissions of the website and the victim's browser. They

740
00:37:54.679 --> 00:37:59.039
<v Speaker 2>can perform cookie stealing, reading the victim's session cookies and

741
00:37:59.119 --> 00:38:00.599
<v Speaker 2>sending them to the attack.

742
00:38:00.360 --> 00:38:02.039
<v Speaker 1>If they're not HGTP only right.

743
00:38:02.000 --> 00:38:04.800
<v Speaker 2>Exactly If the hpp only flag isn't set on the cookie,

744
00:38:04.960 --> 00:38:07.639
<v Speaker 2>JavaScript can read it. If it is set, This attack

745
00:38:07.719 --> 00:38:10.039
<v Speaker 2>is much harder, though not always impossible.

746
00:38:09.559 --> 00:38:11.119
<v Speaker 1>Depending on other factors. What else?

747
00:38:11.320 --> 00:38:13.840
<v Speaker 2>They can turn the victim's browser into a key logger,

748
00:38:14.119 --> 00:38:17.280
<v Speaker 2>capturing everything they type into forms on that page, passwords,

749
00:38:17.400 --> 00:38:20.440
<v Speaker 2>credit card numbers. They can use frameworks like the Browser

750
00:38:20.480 --> 00:38:22.199
<v Speaker 2>Exploitation framework beef.

751
00:38:23.039 --> 00:38:23.320
<v Speaker 1>Yeah.

752
00:38:23.800 --> 00:38:27.639
<v Speaker 2>Beef lets an attacker hook a victims browser. Once hooked,

753
00:38:27.880 --> 00:38:30.079
<v Speaker 2>they have a command and control channel to the browser,

754
00:38:30.239 --> 00:38:33.199
<v Speaker 2>allowing them to launch further attacks, use it as a proxy,

755
00:38:33.400 --> 00:38:38.119
<v Speaker 2>explore the internal network. It's incredibly powerful, and of course,

756
00:38:38.159 --> 00:38:42.159
<v Speaker 2>simpler things like defacement just visually altering the web page content.

757
00:38:42.559 --> 00:38:46.400
<v Speaker 1>Is there an automated tool specifically for finding XSS flaws?

758
00:38:46.599 --> 00:38:50.519
<v Speaker 2>Yes, xsor is a well known automatic EXSS scanner in

759
00:38:50.639 --> 00:38:54.800
<v Speaker 2>Collie that can help identify potential EXSS points by injecting

760
00:38:54.840 --> 00:38:57.559
<v Speaker 2>various payloads and analyzing the server's responses.

761
00:38:57.679 --> 00:39:01.119
<v Speaker 1>So, given how versatile XSS is, how do we prevent

762
00:39:01.119 --> 00:39:01.760
<v Speaker 1>it effectively?

763
00:39:02.000 --> 00:39:05.159
<v Speaker 2>Again, it comes back to handling user inputs securely. Input

764
00:39:05.199 --> 00:39:08.519
<v Speaker 2>validation is the first line of defense. Sanitization, removing dangerous

765
00:39:08.599 --> 00:39:12.519
<v Speaker 2>characters and output encoding converting special characters before displaying them

766
00:39:12.559 --> 00:39:14.760
<v Speaker 2>back to the user are absolutely key aspects.

767
00:39:14.800 --> 00:39:16.760
<v Speaker 1>Encoding on output that's important.

768
00:39:16.440 --> 00:39:19.920
<v Speaker 2>Critically important. You encode data right before it gets inserted

769
00:39:19.960 --> 00:39:25.480
<v Speaker 2>into the htmnel page. And to reiterate that crucial point, validations, sanitization,

770
00:39:25.559 --> 00:39:28.199
<v Speaker 2>and encoding processes must be done on both the client

771
00:39:28.320 --> 00:39:31.800
<v Speaker 2>side and the server side. Relying only on client side

772
00:39:31.880 --> 00:39:33.559
<v Speaker 2>checks is insecure.

773
00:39:33.880 --> 00:39:38.079
<v Speaker 1>Okay, Let's move to cross site request forgery or CSRF.

774
00:39:38.679 --> 00:39:41.599
<v Speaker 1>This one always sounds particularly sneaky because it involves someone

775
00:39:41.639 --> 00:39:42.519
<v Speaker 1>who's already logged in.

776
00:39:42.639 --> 00:39:46.280
<v Speaker 2>It is sneaky. CSRF is about forcing an authenticated, logged

777
00:39:46.320 --> 00:39:49.320
<v Speaker 2>in user to submit a malicious request without their knowledge

778
00:39:49.360 --> 00:39:52.920
<v Speaker 2>or consent. The attacker crafts a request, maybe embedded in

779
00:39:52.920 --> 00:39:55.280
<v Speaker 2>an image pack or a link, that performs an action

780
00:39:55.360 --> 00:39:57.239
<v Speaker 2>on a site where the user is logged in, like

781
00:39:57.519 --> 00:40:00.760
<v Speaker 2>changing their email address, transferring funds a message.

782
00:40:00.840 --> 00:40:01.559
<v Speaker 1>How does that work?

783
00:40:01.599 --> 00:40:04.159
<v Speaker 2>The attacker leverages the fact that the user's browser will

784
00:40:04.199 --> 00:40:07.679
<v Speaker 2>automatically include any relevant session cookies when making a request

785
00:40:07.679 --> 00:40:10.199
<v Speaker 2>to that site. So if you're logged into your bank

786
00:40:10.239 --> 00:40:13.480
<v Speaker 2>and you unknowingly trigger a malicious request crafted by an attacker,

787
00:40:13.800 --> 00:40:17.239
<v Speaker 2>maybe by visiting their dodgy website, your browser sends the

788
00:40:17.320 --> 00:40:20.360
<v Speaker 2>request with your valid banking session cookie and the bank

789
00:40:20.360 --> 00:40:21.719
<v Speaker 2>thinks you initiated the action.

790
00:40:22.199 --> 00:40:25.639
<v Speaker 1>Yikes. How do you identify if an application is vulnerable

791
00:40:25.719 --> 00:40:28.119
<v Speaker 1>to CSRF? What's the telltale sign?

792
00:40:28.239 --> 00:40:30.639
<v Speaker 2>You look for? State changing actions like submitting a form,

793
00:40:30.960 --> 00:40:33.239
<v Speaker 2>clicking a button that does something that don't include any

794
00:40:33.280 --> 00:40:36.840
<v Speaker 2>special header or form parameter that's unique and unpredictable for

795
00:40:36.920 --> 00:40:40.199
<v Speaker 2>that specific user session. If the request relies only on

796
00:40:40.239 --> 00:40:43.960
<v Speaker 2>the session cookie for authentication and authorization, it's likely vulnerable.

797
00:40:44.320 --> 00:40:47.960
<v Speaker 2>The Perugia vulnerable app example where submitting a comment only

798
00:40:48.000 --> 00:40:50.079
<v Speaker 2>needed the session cookie is a classic case.

799
00:40:50.400 --> 00:40:53.039
<v Speaker 1>And how is it exploited? Is it easier with geet

800
00:40:53.119 --> 00:40:56.519
<v Speaker 1>you requests like in a URL or post requests like

801
00:40:56.840 --> 00:40:57.599
<v Speaker 1>form data.

802
00:40:57.760 --> 00:41:00.719
<v Speaker 2>Exploiting it with geek requests is often simpler. Just embedding

803
00:41:00.719 --> 00:41:04.880
<v Speaker 2>the malicious URL in an image tag mmgsrc, on another side,

804
00:41:04.920 --> 00:41:07.960
<v Speaker 2>is enough. For post requests, it's a bit more involved.

805
00:41:08.119 --> 00:41:11.000
<v Speaker 2>The attacker usually needs to create a hidden HTML form

806
00:41:11.039 --> 00:41:14.440
<v Speaker 2>on their malicious page that automatically submits the harmful data

807
00:41:14.480 --> 00:41:16.280
<v Speaker 2>to the target site when the victim visits.

808
00:41:16.360 --> 00:41:20.079
<v Speaker 1>Now, can an EXSS vulnerability be used to bypass CSRF protections?

809
00:41:20.119 --> 00:41:21.519
<v Speaker 1>That sounds like a nasty combination.

810
00:41:21.880 --> 00:41:25.000
<v Speaker 2>Yes, it's a very common and dangerous scenario. If an

811
00:41:25.000 --> 00:41:29.760
<v Speaker 2>application uses anti CSRF tokens unique secret values in forms

812
00:41:29.800 --> 00:41:34.119
<v Speaker 2>to prevent CSRF, but is also vulnerable to EXSS.

813
00:41:33.639 --> 00:41:36.519
<v Speaker 1>The attacker can use EXSS to steal the token exactly.

814
00:41:36.880 --> 00:41:40.280
<v Speaker 2>The attacker uses the EXSS vulnerability to run JavaScript that

815
00:41:40.400 --> 00:41:43.719
<v Speaker 2>reads the anti CSRF token from the page's form, and

816
00:41:43.800 --> 00:41:46.119
<v Speaker 2>then they can craft a valid request with the stolen

817
00:41:46.159 --> 00:41:50.239
<v Speaker 2>token completely bypassing the CSRF protection. It shows how vulnerabilities

818
00:41:50.280 --> 00:41:51.199
<v Speaker 2>often chain together.

819
00:41:51.360 --> 00:41:53.679
<v Speaker 1>So what's the prevention for CSRF? How do you start it?

820
00:41:53.719 --> 00:41:57.639
<v Speaker 2>The primary defense is implementing anti CSRF tokens These are unique,

821
00:41:57.679 --> 00:42:00.920
<v Speaker 2>unpredictable secret values generated by the so for each user

822
00:42:01.039 --> 00:42:04.519
<v Speaker 2>session and embedded informs. The server validates this token on

823
00:42:04.559 --> 00:42:08.360
<v Speaker 2>every state changing request. The same site cookie attribute, especially

824
00:42:08.440 --> 00:42:12.400
<v Speaker 2>set to strict or lacks, provides significant protection by controlling

825
00:42:12.440 --> 00:42:15.360
<v Speaker 2>when cookies are sent with cross origin requests, though browser

826
00:42:15.360 --> 00:42:19.800
<v Speaker 2>support and implementation details matter. Requiring user interaction for sensitive

827
00:42:19.840 --> 00:42:24.119
<v Speaker 2>actions like entering a captcha or reauthenticating with a password

828
00:42:24.320 --> 00:42:28.519
<v Speaker 2>is also effective, and properly configured cross origin resource sharing

829
00:42:28.599 --> 00:42:32.079
<v Speaker 2>CRS policies on the server can help restrict how JavaScript

830
00:42:32.119 --> 00:42:34.960
<v Speaker 2>from other origins interacts with the site.

831
00:42:35.159 --> 00:42:40.079
<v Speaker 1>All right, onto our last major vulnerability category, attacking flaws

832
00:42:40.119 --> 00:42:43.800
<v Speaker 1>and cryptographic implementations. This sounds really complex, like breaking codes.

833
00:42:43.920 --> 00:42:46.840
<v Speaker 2>It definitely sounds that way. The goal of cryptography here is,

834
00:42:46.960 --> 00:42:50.800
<v Speaker 2>of course, protecting data confidentiality and integrity, But for pentesters

835
00:42:50.800 --> 00:42:54.079
<v Speaker 2>the focus usually isn't on trying to break strong established

836
00:42:54.079 --> 00:42:58.280
<v Speaker 2>cryptographic algorithms like AES or SAHA two fifty six. That's

837
00:42:58.400 --> 00:43:01.039
<v Speaker 2>generally mathematically infeasible with current tech.

838
00:43:01.119 --> 00:43:02.039
<v Speaker 1>So what are they looking for?

839
00:43:02.159 --> 00:43:05.599
<v Speaker 2>They're looking for implementation failures using the right algorithm but

840
00:43:05.639 --> 00:43:09.239
<v Speaker 2>in the wrong way, and perhaps more commonly seriously flawed

841
00:43:09.239 --> 00:43:14.199
<v Speaker 2>custom implementations. Developers sometimes think they can invent their own secure.

842
00:43:14.000 --> 00:43:16.440
<v Speaker 1>Encryption, which is a bad idea, a.

843
00:43:16.280 --> 00:43:20.280
<v Speaker 2>Really bad idea. Strong algorithms are designed and rigorously tested

844
00:43:20.280 --> 00:43:24.199
<v Speaker 2>by highly specialized teams of mathematicians and computer scientists. It's

845
00:43:24.239 --> 00:43:26.239
<v Speaker 2>not something you should roll your own unless you are

846
00:43:26.239 --> 00:43:27.280
<v Speaker 2>one of those experts.

847
00:43:28.000 --> 00:43:30.519
<v Speaker 1>What are the basics of encryption we need to grasp here?

848
00:43:30.559 --> 00:43:34.760
<v Speaker 2>Okay, briefly. With symmetric algorithms, the same secret key is

849
00:43:34.880 --> 00:43:38.599
<v Speaker 2>used for both encryption and decryption. You have stream ciphers,

850
00:43:38.599 --> 00:43:41.159
<v Speaker 2>which encrypt data bit by bit or byte by byte.

851
00:43:41.199 --> 00:43:44.280
<v Speaker 2>Good for streaming ciphertext is the same size as the

852
00:43:44.280 --> 00:43:48.440
<v Speaker 2>clear text, and block ciphers, which encrypt fixed sized blocks

853
00:43:48.440 --> 00:43:51.519
<v Speaker 2>of data that the ciphertext is usually a multiple.

854
00:43:51.079 --> 00:43:53.639
<v Speaker 1>Of the block size. Right and hash.

855
00:43:53.199 --> 00:43:56.039
<v Speaker 2>Hashing functions take an input of any size and produce

856
00:43:56.079 --> 00:43:59.400
<v Speaker 2>a fixed length value the hash er digest. Their main

857
00:43:59.440 --> 00:44:02.800
<v Speaker 2>purpose is ensuring the integrity of the message. Any tiny

858
00:44:02.880 --> 00:44:05.639
<v Speaker 2>change in the input results in a drastically different hash.

859
00:44:05.960 --> 00:44:07.920
<v Speaker 2>They should also be non reversible. You can't get the

860
00:44:07.920 --> 00:44:10.079
<v Speaker 2>original input back from the hash, and it should be

861
00:44:10.159 --> 00:44:13.440
<v Speaker 2>computationally impossible to find two different inputs that produce the

862
00:44:13.480 --> 00:44:15.559
<v Speaker 2>same hash a collision.

863
00:44:15.320 --> 00:44:18.440
<v Speaker 1>And thels SSL in web apps brings us all together

864
00:44:18.559 --> 00:44:19.199
<v Speaker 1>pretty much.

865
00:44:19.480 --> 00:44:23.719
<v Speaker 2>Https is the everyday application of TLSSSL to secure client

866
00:44:23.800 --> 00:44:30.000
<v Speaker 2>server communication. As we said, TLS provides that CIA triad confidentiality, integrity, availability,

867
00:44:30.280 --> 00:44:33.880
<v Speaker 2>plus non repudiation via certificate signed by CAAs verifying the

868
00:44:33.880 --> 00:44:38.679
<v Speaker 2>server's identity. The actual process cleverly combines both asymmetric public

869
00:44:38.679 --> 00:44:42.400
<v Speaker 2>private key encryption for the initial secure key exchange and

870
00:44:42.440 --> 00:44:45.480
<v Speaker 2>then faster symmetric encryption using that exchange key for the

871
00:44:45.559 --> 00:44:46.559
<v Speaker 2>bulk data transfer.

872
00:44:46.599 --> 00:44:49.239
<v Speaker 1>And that critical flaw the nl cipher pops up here again,

873
00:44:49.559 --> 00:44:50.760
<v Speaker 1>that false sense of security.

874
00:44:51.119 --> 00:44:54.119
<v Speaker 2>Yes, it's worth repeating. If n CEL ciphers are enabled

875
00:44:54.159 --> 00:44:57.320
<v Speaker 2>and get negotiated, the browser might show the padlock, but

876
00:44:57.880 --> 00:45:02.079
<v Speaker 2>HTTP data will actually be transmitted in cleartext. Looks secure,

877
00:45:02.199 --> 00:45:04.440
<v Speaker 2>but isn't like a locked door made of glass.

878
00:45:04.679 --> 00:45:09.039
<v Speaker 1>What tools help pentesters scrutinize these ssltls configurations.

879
00:45:09.440 --> 00:45:13.239
<v Speaker 2>The open SSL command line tool is fundamental for manual checks.

880
00:45:13.519 --> 00:45:16.920
<v Speaker 2>SSL scan is great. It can show cipher's certificate details

881
00:45:16.960 --> 00:45:19.440
<v Speaker 2>and crucially it helps you watch out when NSL is

882
00:45:19.480 --> 00:45:23.000
<v Speaker 2>pointed out in the cipher list. Sslies is another powerful

883
00:45:23.119 --> 00:45:27.559
<v Speaker 2>dedicated SSLTLS scanner, and NMP again has scripts like SSL

884
00:45:27.719 --> 00:45:30.800
<v Speaker 2>enom ciphers to identify cipher suites, rate their strength, and

885
00:45:30.880 --> 00:45:33.920
<v Speaker 2>flag specific protocol vulnerabilities like crime or poodle.

886
00:45:34.199 --> 00:45:37.159
<v Speaker 1>Speaking of those, what about exploiting well known crypto flaws

887
00:45:37.199 --> 00:45:39.519
<v Speaker 1>like heart bleed or poodle that caused such panics?

888
00:45:39.639 --> 00:45:42.079
<v Speaker 2>Yeah, those were big ones. Heart Bleed back in April

889
00:45:42.119 --> 00:45:45.559
<v Speaker 2>twenty fourteen, was a devastating buffer over red situation in

890
00:45:45.599 --> 00:45:49.519
<v Speaker 2>the open SSL TLS implementation. Basically due to a missing

891
00:45:49.599 --> 00:45:52.800
<v Speaker 2>bounds check in the heartbeat extension, an attacker could request

892
00:45:52.880 --> 00:45:55.039
<v Speaker 2>more data back from the server than they sent, and

893
00:45:55.079 --> 00:45:57.880
<v Speaker 2>the server would accidentally return extra chunks of its own.

894
00:45:57.679 --> 00:45:59.960
<v Speaker 1>Memory, including potentially sensitive data.

895
00:46:00.079 --> 00:46:03.960
<v Speaker 2>Including potentially sensitive data like private keys, session cookies, passwords,

896
00:46:04.000 --> 00:46:06.480
<v Speaker 2>all in clear text read directly from the server's memory

897
00:46:06.480 --> 00:46:10.039
<v Speaker 2>without needing to decrypt anything. Metasploit quickly got an.

898
00:46:09.920 --> 00:46:12.440
<v Speaker 1>Explorit module for it and poodle.

899
00:46:12.280 --> 00:46:17.800
<v Speaker 2>Poodle padding oracle On downgraded legacy encryption specifically exploited a

900
00:46:17.840 --> 00:46:22.119
<v Speaker 2>weakness in how SSLv three handled blocks cipher padding, combined

901
00:46:22.119 --> 00:46:24.840
<v Speaker 2>with the fact that browsers could be tricked into downgrading

902
00:46:24.840 --> 00:46:29.719
<v Speaker 2>the connection from TLS to the much older, insecure SSLv three.

903
00:46:29.800 --> 00:46:33.400
<v Speaker 2>If a server still allowed SSLv three connections, it was vulnerable.

904
00:46:33.840 --> 00:46:37.079
<v Speaker 2>In practice, executing the full poodle attack was complex, but

905
00:46:37.199 --> 00:46:41.199
<v Speaker 2>simply allowing SSLv three was a bad sign. Attackers often

906
00:46:41.199 --> 00:46:43.519
<v Speaker 2>found it easier just to use SSL stripping to force

907
00:46:43.559 --> 00:46:44.360
<v Speaker 2>plan HTTP.

908
00:46:44.519 --> 00:46:47.760
<v Speaker 1>Anyway, you mentioned developers rolling their own crypto being a

909
00:46:47.840 --> 00:46:49.679
<v Speaker 1>huge risk. Why is that so dangerous?

910
00:46:50.239 --> 00:46:54.159
<v Speaker 2>It's dangerous because custom encryption protocols are almost invariably weak.

911
00:46:54.280 --> 00:46:57.000
<v Speaker 2>Developers might think, oh, only I know the algorithm, so

912
00:46:57.039 --> 00:46:59.679
<v Speaker 2>it must be secure. That security through obscurity, and it

913
00:46:59.760 --> 00:47:00.519
<v Speaker 2>never works.

914
00:47:00.400 --> 00:47:02.079
<v Speaker 1>Long term because real crypto is.

915
00:47:02.039 --> 00:47:07.000
<v Speaker 2>Hard, incredibly hard. Common mistakes involve simple techniques like basic

916
00:47:07.159 --> 00:47:12.360
<v Speaker 2>xor operations, simple character substitution, or just scrambling the data order.

917
00:47:12.920 --> 00:47:16.639
<v Speaker 2>All of these are easily breakable with standard cryptanalysis techniques

918
00:47:16.679 --> 00:47:18.159
<v Speaker 2>taught in introductory courses.

919
00:47:18.199 --> 00:47:21.280
<v Speaker 1>And where the keys are stored must be another massive failure. Points.

920
00:47:21.440 --> 00:47:25.559
<v Speaker 2>Huge one key storage flaws are rife encryption keys stored

921
00:47:25.559 --> 00:47:29.679
<v Speaker 2>in totally unsafe places, maybe in downloadable configuration files, hard

922
00:47:29.679 --> 00:47:33.039
<v Speaker 2>coded directly in application source code, or even embedded in

923
00:47:33.079 --> 00:47:35.159
<v Speaker 2>client side jobscript where anyone can see them.

924
00:47:35.280 --> 00:47:35.760
<v Speaker 1>Yikes.

925
00:47:36.000 --> 00:47:40.159
<v Speaker 2>Also just using outdated algorithms things like DEES encryption or

926
00:47:40.280 --> 00:47:44.119
<v Speaker 2>using MBFI for password hashing, especially for passwords under sy

927
00:47:44.199 --> 00:47:48.599
<v Speaker 2>ten characters. Modern CPUs and especially GPUs can crack these

928
00:47:48.639 --> 00:47:52.639
<v Speaker 2>relatively easily, sometimes in minutes or hours, using readily available tools.

929
00:47:53.079 --> 00:47:55.440
<v Speaker 1>So if a pin tester finds some data that looks

930
00:47:55.519 --> 00:47:58.000
<v Speaker 1>encrypted or hashed, how do they figure out what it

931
00:47:58.079 --> 00:47:59.199
<v Speaker 1>is and maybe try to break it?

932
00:47:59.360 --> 00:48:01.519
<v Speaker 2>Well, if the out put is always the same fixed

933
00:48:01.599 --> 00:48:04.320
<v Speaker 2>length regardless of the input size, it's almost certainly a hash.

934
00:48:04.559 --> 00:48:07.280
<v Speaker 2>There's a Collie tool called hash identifier that can help

935
00:48:07.360 --> 00:48:10.400
<v Speaker 2>guess the hash type based on common patterns and links.

936
00:48:11.280 --> 00:48:14.599
<v Speaker 1>Okay, what about telling encrypted data apart from just say

937
00:48:15.159 --> 00:48:16.599
<v Speaker 1>random binary data?

938
00:48:16.679 --> 00:48:19.400
<v Speaker 2>Frequency analysis is a very useful way to tell if

939
00:48:19.440 --> 00:48:23.679
<v Speaker 2>a set of data is encrypted, encoded, or obfuscated. Properly,

940
00:48:23.800 --> 00:48:26.719
<v Speaker 2>encrypted data should have a very similar frequency for every

941
00:48:26.800 --> 00:48:30.480
<v Speaker 2>character from zero to two fifty five. The byte distribution

942
00:48:30.599 --> 00:48:34.639
<v Speaker 2>looks almost random, very flat. Clear text, on the other hand,

943
00:48:34.719 --> 00:48:37.960
<v Speaker 2>has very uneven distributions. Think how often E appears in

944
00:48:38.039 --> 00:48:41.880
<v Speaker 2>English text compared to Z. Entropy analysis also helps it

945
00:48:41.920 --> 00:48:46.599
<v Speaker 2>measures randomness. Ideally, a strong encryption algorithm should produce ciphertext

946
00:48:46.679 --> 00:48:49.559
<v Speaker 2>with entropy values very close to eight for eight bits

947
00:48:49.599 --> 00:48:53.639
<v Speaker 2>per bitte, indicating high randomness. Lower entropy might suggest weak

948
00:48:53.760 --> 00:48:55.480
<v Speaker 2>encryption or just obfuscation.

949
00:48:55.880 --> 00:48:58.360
<v Speaker 1>And if they identify a hash, what tools do they

950
00:48:58.440 --> 00:49:00.840
<v Speaker 1>use to try and crack it offline back on their

951
00:49:00.880 --> 00:49:01.480
<v Speaker 1>own machine.

952
00:49:01.519 --> 00:49:04.599
<v Speaker 2>Two mainstays and Collie are John the Ripper and Hashcat.

953
00:49:04.800 --> 00:49:07.559
<v Speaker 2>John jtr is pre installed, it's a classic. It can

954
00:49:07.599 --> 00:49:11.119
<v Speaker 2>often auto detect hash types, run powerful dictionary attacks using

955
00:49:11.119 --> 00:49:13.880
<v Speaker 2>massive word lists like the famous Rocky list compiled from

956
00:49:13.960 --> 00:49:17.440
<v Speaker 2>real world breaches, apply mangling rules to dictionary words, and

957
00:49:17.519 --> 00:49:18.760
<v Speaker 2>perform brute force.

958
00:49:18.559 --> 00:49:19.559
<v Speaker 1>Attacks in hashcat.

959
00:49:19.719 --> 00:49:22.960
<v Speaker 2>Hashcat is a more modern, highly optimized cracking tool designed

960
00:49:22.960 --> 00:49:25.840
<v Speaker 2>to leverage the power of GPUs graphics cards as well

961
00:49:25.840 --> 00:49:29.559
<v Speaker 2>as CPUs for brute forcing or complex dictionary attacks. It

962
00:49:29.599 --> 00:49:32.400
<v Speaker 2>can be orders of magnitude faster than a CPU only

963
00:49:32.480 --> 00:49:35.119
<v Speaker 2>tool like John, assuming you have a decent GPU.

964
00:49:35.320 --> 00:49:38.719
<v Speaker 1>So bottom line, how do we prevent these cryptographic flaws

965
00:49:38.719 --> 00:49:39.639
<v Speaker 1>in our applications?

966
00:49:39.760 --> 00:49:43.599
<v Speaker 2>First, always use secure standard protocols like TLS and configure

967
00:49:43.639 --> 00:49:48.400
<v Speaker 2>them correctly. Use things like HTTP Strict Transport Security HSTS

968
00:49:48.440 --> 00:49:52.320
<v Speaker 2>headers to tell browsers to only connect via htps, preventing

969
00:49:52.400 --> 00:49:53.280
<v Speaker 2>SSL strip.

970
00:49:53.079 --> 00:49:54.639
<v Speaker 1>Attacks and password storage.

971
00:49:54.719 --> 00:49:58.199
<v Speaker 2>Passwords must never be stored in clear text. Ever, use

972
00:49:58.280 --> 00:50:01.880
<v Speaker 2>modern one way salted hash fundnctions. Good choices currently include

973
00:50:01.880 --> 00:50:05.639
<v Speaker 2>PBKDF two be crypt or script, often combined with a

974
00:50:05.679 --> 00:50:09.079
<v Speaker 2>strong hash like SAHA five twelve. The salting part adding

975
00:50:09.079 --> 00:50:11.880
<v Speaker 2>a unique random value to each password before hashing, is

976
00:50:11.920 --> 00:50:15.440
<v Speaker 2>critical to defeat rainbow table attacks. Using older hashes like

977
00:50:15.559 --> 00:50:18.400
<v Speaker 2>MD five or SAJA one for passwords is now strongly

978
00:50:18.440 --> 00:50:21.320
<v Speaker 2>discouraged due to known weaknesses and collision vulnerabilities.

979
00:50:21.480 --> 00:50:24.320
<v Speaker 1>Okay, we've covered a ton on finding vulnerabilities. Now let's

980
00:50:24.360 --> 00:50:28.760
<v Speaker 1>shift to the hacker's arsenal, starting with automated scanners in practice.

981
00:50:29.119 --> 00:50:31.639
<v Speaker 1>What's their real role in a pen test? Are they

982
00:50:32.000 --> 00:50:33.000
<v Speaker 1>the magic bullet?

983
00:50:33.239 --> 00:50:36.800
<v Speaker 2>Automated scanners definitely have a role. They're good for quick scans,

984
00:50:36.840 --> 00:50:40.039
<v Speaker 2>for finding that low hanging fruit, the obvious common vulnerabilities,

985
00:50:40.559 --> 00:50:44.679
<v Speaker 2>but they are absolutely not a magic bullet, far from it.

986
00:50:44.760 --> 00:50:45.920
<v Speaker 1>What are the big caveats?

987
00:50:46.519 --> 00:50:51.039
<v Speaker 2>Several critical considerations. First, always always check the scope and

988
00:50:51.079 --> 00:50:54.000
<v Speaker 2>project documentation to make sure you even have permission to

989
00:50:54.079 --> 00:50:58.880
<v Speaker 2>use automated scanners. Some clients forbid them or restrict their use. Second,

990
00:50:58.960 --> 00:51:02.639
<v Speaker 2>ideally test only in a QA development or testing environment.

991
00:51:03.239 --> 00:51:06.440
<v Speaker 2>Never run an aggressive automated scanner against a live production

992
00:51:06.519 --> 00:51:10.559
<v Speaker 2>system without explicit written consent, because there's an inherent risk

993
00:51:10.599 --> 00:51:12.679
<v Speaker 2>of damaging the data or causing downtime.

994
00:51:12.800 --> 00:51:14.360
<v Speaker 1>Makes sense anything else.

995
00:51:14.400 --> 00:51:18.400
<v Speaker 2>Keep the scanners, plugins and vulnerability definitions updated, Configure it

996
00:51:18.440 --> 00:51:21.199
<v Speaker 2>for the maximum level of logging so you have evidence,

997
00:51:21.440 --> 00:51:24.000
<v Speaker 2>and critically, do not leave the scanner unattended. You need

998
00:51:24.039 --> 00:51:25.280
<v Speaker 2>to monitor what it's doing.

999
00:51:25.519 --> 00:51:28.400
<v Speaker 1>And the most important thing to remember about relying.

1000
00:51:28.039 --> 00:51:30.960
<v Speaker 2>On them, the absolute most important thing is do not

1001
00:51:31.119 --> 00:51:34.599
<v Speaker 2>rely on a single tool. Use multiple scanners if possible,

1002
00:51:34.639 --> 00:51:39.599
<v Speaker 2>but most importantly, always manually validate findings. Automated scans are

1003
00:51:39.639 --> 00:51:42.719
<v Speaker 2>notorious for false positives, and they often fail to provide

1004
00:51:42.760 --> 00:51:46.840
<v Speaker 2>any value without that crucial manual verification and interpretation by

1005
00:51:46.880 --> 00:51:48.199
<v Speaker 2>an experienced.

1006
00:51:47.599 --> 00:51:51.199
<v Speaker 1>Tester, which CALI. Linux scanners are commonly used for web applications.

1007
00:51:51.559 --> 00:51:53.480
<v Speaker 1>Besides nikto which we mentioned well.

1008
00:51:53.400 --> 00:51:56.159
<v Speaker 2>There's skipfish, which is known for being fast and generating

1009
00:51:56.280 --> 00:52:00.559
<v Speaker 2>nice HTML reports that categorize vulnerabilities by risk level. Where

1010
00:52:00.599 --> 00:52:03.320
<v Speaker 2>PD is another command line scanner that detects variety of

1011
00:52:03.320 --> 00:52:07.960
<v Speaker 2>flies like xss, uculi, file inclusions, etc. And the WASP

1012
00:52:08.079 --> 00:52:12.079
<v Speaker 2>d app proxy includes an active vulnerability scanner component that

1013
00:52:12.119 --> 00:52:15.840
<v Speaker 2>sends specifically crafted requests to probe for vulnerabilities.

1014
00:52:15.920 --> 00:52:18.400
<v Speaker 1>Whatout fuzzing. That sounds a bit like just throwing random

1015
00:52:18.440 --> 00:52:19.440
<v Speaker 1>stuff at an application.

1016
00:52:19.840 --> 00:52:23.639
<v Speaker 2>It is essentially, but in a structured way. Fuzzing involves

1017
00:52:23.679 --> 00:52:28.000
<v Speaker 2>sending large amounts of unexpected, malformed or semi malformed data

1018
00:52:28.039 --> 00:52:31.960
<v Speaker 2>to an application's inputs to see if you can trigger crashes, errors,

1019
00:52:32.199 --> 00:52:33.880
<v Speaker 2>or uncover hidden vulnerabilities.

1020
00:52:33.920 --> 00:52:35.159
<v Speaker 1>How do tools help with that?

1021
00:52:35.599 --> 00:52:38.599
<v Speaker 2>Tools like the o waspps app fuzzer let you select

1022
00:52:38.639 --> 00:52:42.360
<v Speaker 2>specific insertion points in an HTTP request parts you want

1023
00:52:42.360 --> 00:52:44.639
<v Speaker 2>to replace with fuzzed data, like from a list of

1024
00:52:44.639 --> 00:52:47.760
<v Speaker 2>common attack strings or just random data. Then you analyze

1025
00:52:47.800 --> 00:52:51.239
<v Speaker 2>the responses, maybe looking for error messages or specific keywords

1026
00:52:51.320 --> 00:52:56.280
<v Speaker 2>like reflected, which might indicate potential EXSS. Burb Intruder is

1027
00:52:56.280 --> 00:53:00.719
<v Speaker 2>also extremely powerful for fuzzing and dictionary attacks, trying thousands

1028
00:53:00.760 --> 00:53:03.360
<v Speaker 2>of usernames and passwords on a login page, or testing

1029
00:53:03.400 --> 00:53:06.679
<v Speaker 2>for SQL injection by setting up rules repmatch to flag

1030
00:53:06.719 --> 00:53:08.039
<v Speaker 2>interesting server responses.

1031
00:53:08.119 --> 00:53:11.800
<v Speaker 1>Okay, now for the really big gun, the Metasplit framework.

1032
00:53:12.039 --> 00:53:14.480
<v Speaker 1>It is often called the pintester's Swiss army knife. Right.

1033
00:53:14.719 --> 00:53:19.000
<v Speaker 2>It absolutely is metasplit is huge. Its power comes from

1034
00:53:19.000 --> 00:53:25.480
<v Speaker 2>its modular architecture. Everything exploits payloads and coders, auxiliary modules

1035
00:53:25.480 --> 00:53:29.480
<v Speaker 2>for scanning or reconnaissance. They're all individual modules. This makes

1036
00:53:29.519 --> 00:53:32.920
<v Speaker 2>it incredibly flexible and easy to extend with new capabilities.

1037
00:53:33.039 --> 00:53:35.280
<v Speaker 1>How easy is set up in calling very easy.

1038
00:53:35.320 --> 00:53:38.320
<v Speaker 2>It's usually pre installed or a quick install. The important

1039
00:53:38.320 --> 00:53:42.920
<v Speaker 2>setup step is initializing its postgresscool database. Metasploit uses this

1040
00:53:43.000 --> 00:53:48.239
<v Speaker 2>database to store all the information you gather about hosts, services, vulnerabilities, credentials.

1041
00:53:48.559 --> 00:53:52.119
<v Speaker 2>Using workspaces within the database is also key for staying organized.

1042
00:53:52.280 --> 00:53:55.159
<v Speaker 2>It lets use separate data sets for different penetration tests

1043
00:53:55.239 --> 00:53:56.960
<v Speaker 2>or different parts of a network.

1044
00:53:57.000 --> 00:53:59.000
<v Speaker 1>And how does it integrate with the scanning and info

1045
00:53:59.079 --> 00:53:59.960
<v Speaker 1>gathering we already talked to.

1046
00:54:00.559 --> 00:54:03.840
<v Speaker 2>Metasploid itself has a vast array of auxiliary modules for

1047
00:54:03.920 --> 00:54:07.559
<v Speaker 2>information gathering and scanning. For passive recon there are modules

1048
00:54:07.599 --> 00:54:11.360
<v Speaker 2>to query dns, scrape subdomains from search engines like Yahoo

1049
00:54:11.440 --> 00:54:14.519
<v Speaker 2>and bing search, showdan if you have an apikey to

1050
00:54:14.719 --> 00:54:18.159
<v Speaker 2>find devices and open ports, or collect email addresses associated

1051
00:54:18.159 --> 00:54:19.679
<v Speaker 2>with a domain from search engines.

1052
00:54:19.400 --> 00:54:21.960
<v Speaker 1>So it could do its own recon yes and.

1053
00:54:21.920 --> 00:54:25.159
<v Speaker 2>For active scanning, it has its own TCP port scanner

1054
00:54:25.199 --> 00:54:28.679
<v Speaker 2>and syn port scanner modules. But even better, it integrates

1055
00:54:28.719 --> 00:54:31.760
<v Speaker 2>directly with nmap. You can run enmap scans using the

1056
00:54:31.800 --> 00:54:34.519
<v Speaker 2>dbn met command and the results are automatically imported and

1057
00:54:34.559 --> 00:54:38.880
<v Speaker 2>stored right in metasploids database. This is incredibly useful. You

1058
00:54:38.920 --> 00:54:43.440
<v Speaker 2>can leverage enmap's powerful enmap scripting engine NSC scripts maybe

1059
00:54:43.480 --> 00:54:47.960
<v Speaker 2>to find specific HTTP vulnerabilities like servers allowing dangerous methods

1060
00:54:48.320 --> 00:54:51.320
<v Speaker 2>UQT delete trace, and have all that data ready in

1061
00:54:51.360 --> 00:54:52.639
<v Speaker 2>metasploit for the next steps.

1062
00:54:52.719 --> 00:54:54.599
<v Speaker 1>So it's not just a collection of exploits, but a

1063
00:54:54.639 --> 00:54:58.320
<v Speaker 1>full framework that manages the whole process, including the data.

1064
00:54:58.440 --> 00:55:01.400
<v Speaker 1>What about discovering hosts and services beyond web stuff?

1065
00:55:01.440 --> 00:55:05.119
<v Speaker 2>Definitely? Metasploit has modules like ARP sweep to find live

1066
00:55:05.159 --> 00:55:08.280
<v Speaker 2>hosts on the local network segment a UDP service. Sweeper

1067
00:55:08.320 --> 00:55:12.079
<v Speaker 2>can probe for common UDP services like net biosportmap, SMMP,

1068
00:55:12.559 --> 00:55:16.400
<v Speaker 2>DNS for SMB server, message block and numeration on Windows networks.

1069
00:55:16.400 --> 00:55:20.440
<v Speaker 2>It's very powerful. Modules like seminom shares find accessible network shares,

1070
00:55:20.440 --> 00:55:23.639
<v Speaker 2>spend and aversion gets detailed OS info Somedenom users can

1071
00:55:23.639 --> 00:55:26.679
<v Speaker 2>sometimes list local users via the SAM RPC interface. That's

1072
00:55:26.719 --> 00:55:30.639
<v Speaker 2>the Security Account Manager database where Windows keeps user credentials.

1073
00:55:30.800 --> 00:55:32.639
<v Speaker 1>Can it brute force logins.

1074
00:55:32.280 --> 00:55:35.719
<v Speaker 2>Yep, some log in can brute force SMB passwords and crucially,

1075
00:55:35.800 --> 00:55:38.960
<v Speaker 2>as we mentioned, the summess WEE TA ten module can

1076
00:55:39.000 --> 00:55:41.960
<v Speaker 2>detect the critical Eternal Blue vulnerability and check for the

1077
00:55:41.960 --> 00:55:44.719
<v Speaker 2>double Pulsar back door without needing any valid credentials.

1078
00:55:44.760 --> 00:55:48.480
<v Speaker 1>That was huge massive. What about SNMP The Network Management

1079
00:55:48.519 --> 00:55:49.320
<v Speaker 1>Protocol For.

1080
00:55:49.360 --> 00:55:53.800
<v Speaker 2>SNMP Simple Network Management Protocol Enumeration metasploid has some log

1081
00:55:53.840 --> 00:55:57.599
<v Speaker 2>in to try common default community strings like passwords for SMMP.

1082
00:55:58.000 --> 00:56:01.800
<v Speaker 2>If successful, sempenem can gather a wealth of information system details,

1083
00:56:01.840 --> 00:56:06.400
<v Speaker 2>network interfaces, running processes, open ports, installed software depending on

1084
00:56:06.440 --> 00:56:08.079
<v Speaker 2>how the devices configured.

1085
00:56:07.719 --> 00:56:09.039
<v Speaker 1>Okay, and other protocols.

1086
00:56:09.119 --> 00:56:12.559
<v Speaker 2>It also has modules for scanning things like HTTT services

1087
00:56:12.599 --> 00:56:15.760
<v Speaker 2>for example Jenkin sentum to check genkin ci service status

1088
00:56:16.199 --> 00:56:20.079
<v Speaker 2>or Windows Remote Management when RM using win RMCMD and

1089
00:56:20.119 --> 00:56:23.559
<v Speaker 2>importantly metasplit can directly integrate with and import scan results

1090
00:56:23.559 --> 00:56:27.639
<v Speaker 2>from commercial vulnerability scanners like nessis or nexpos, as well

1091
00:56:27.639 --> 00:56:30.760
<v Speaker 2>as the open source open bas This lets you consolidate

1092
00:56:30.800 --> 00:56:32.480
<v Speaker 2>all your vulnerability data in one place.

1093
00:56:32.800 --> 00:56:37.000
<v Speaker 1>Okay, so you've gatted all this information identified potential vulnerabilities.

1094
00:56:37.880 --> 00:56:41.599
<v Speaker 1>The next big leap is server side exploitation. This is

1095
00:56:41.639 --> 00:56:43.960
<v Speaker 1>where the actual hacking part happens, right. That's right.

1096
00:56:44.159 --> 00:56:48.199
<v Speaker 2>After meticulously gathering intel about the target OS, the running services,

1097
00:56:48.239 --> 00:56:51.559
<v Speaker 2>and potential vulnerabilities, the next step is finding a suitable

1098
00:56:51.599 --> 00:56:54.079
<v Speaker 2>exploit module in metasploit and the launching it.

1099
00:56:54.280 --> 00:56:57.079
<v Speaker 1>Can you walk us through an example? Maybe on Linux? Sure?

1100
00:56:57.159 --> 00:57:00.440
<v Speaker 2>A classic example often used on the Metasploitable two vulnerable

1101
00:57:00.480 --> 00:57:04.000
<v Speaker 2>practice VM, involves exploiting the Samba service. There is a

1102
00:57:04.039 --> 00:57:10.079
<v Speaker 2>specific metasport module exploit multi sambasser mapscript. This exploit cleverly

1103
00:57:10.159 --> 00:57:13.719
<v Speaker 2>leverages a flaw in how Samba handled usernames, allowing for

1104
00:57:13.800 --> 00:57:16.599
<v Speaker 2>remote command execution without any authentication.

1105
00:57:16.840 --> 00:57:18.480
<v Speaker 1>No password needed, none at all.

1106
00:57:18.679 --> 00:57:21.039
<v Speaker 2>You just point the exploit at the target, run it,

1107
00:57:21.360 --> 00:57:24.320
<v Speaker 2>and if successful, metasploit connects back, giving you a command

1108
00:57:24.360 --> 00:57:27.280
<v Speaker 2>shell on the Linux server. You can then verify access

1109
00:57:27.280 --> 00:57:29.719
<v Speaker 2>by running simple commands like host name or ID to

1110
00:57:29.719 --> 00:57:31.920
<v Speaker 2>see who you are on the compromised machine.

1111
00:57:32.039 --> 00:57:35.119
<v Speaker 1>You keep mentioning payloads when you talk about exploits, What

1112
00:57:35.239 --> 00:57:36.480
<v Speaker 1>exactly is the payload?

1113
00:57:36.800 --> 00:57:39.360
<v Speaker 2>The payload is the piece of code that the exploit

1114
00:57:39.400 --> 00:57:42.159
<v Speaker 2>delivers to the target machine after the vulnerability has been

1115
00:57:42.199 --> 00:57:46.960
<v Speaker 2>successfully exploited, it's what actually gives you control. For example,

1116
00:57:47.079 --> 00:57:49.800
<v Speaker 2>after using the Samba exploit, you might choose a payload

1117
00:57:49.960 --> 00:57:54.079
<v Speaker 2>like cimnikus reverse netcat or more commonly Linux eighty six

1118
00:57:54.119 --> 00:57:58.199
<v Speaker 2>Mesori reverse x. This payload connects back from the victim

1119
00:57:58.239 --> 00:58:01.679
<v Speaker 2>machine to your metasplay listener, establishing that remote access session.

1120
00:58:01.760 --> 00:58:04.559
<v Speaker 1>Okay. And Windows server exploitation similar.

1121
00:58:04.239 --> 00:58:07.719
<v Speaker 2>Ideas, similar concepts yes on the metasploitable three VM which

1122
00:58:07.800 --> 00:58:11.599
<v Speaker 2>runs Windows. Examples might include exploiting vulnerabilities in jenkin Ci

1123
00:58:11.679 --> 00:58:14.679
<v Speaker 2>if it's running, or using the sexc module if you

1124
00:58:14.719 --> 00:58:17.800
<v Speaker 2>somehow manage to obtain valid administrator credentials.

1125
00:58:17.840 --> 00:58:20.440
<v Speaker 1>But the really big one for Windows was Eternal.

1126
00:58:20.079 --> 00:58:24.800
<v Speaker 2>Blue, absolutely the MS seventeen zero ten Eternal Blue SMB

1127
00:58:25.039 --> 00:58:29.400
<v Speaker 2>Remote Windows Kernel pool corruption vulnerability. This was a critical

1128
00:58:29.440 --> 00:58:33.360
<v Speaker 2>buffer overflow flaw in the Windows SMB one server. It

1129
00:58:33.400 --> 00:58:36.280
<v Speaker 2>was allegedly developed by the NSA's Equation group, leaked by

1130
00:58:36.320 --> 00:58:39.119
<v Speaker 2>the Shadow Brokers group, and then infamously use as the

1131
00:58:39.159 --> 00:58:42.800
<v Speaker 2>primary spreading mechanism for the global Wanacry ransomware attack in

1132
00:58:42.840 --> 00:58:46.920
<v Speaker 2>twenty seventeen it allowed unauthenticated remote code execution on a

1133
00:58:46.960 --> 00:58:48.280
<v Speaker 2>massive scale.

1134
00:58:47.920 --> 00:58:50.400
<v Speaker 1>Just devastating. And once an attacker gets in, how they

1135
00:58:50.400 --> 00:58:51.679
<v Speaker 1>make sure they can get back in later.

1136
00:58:51.800 --> 00:58:55.239
<v Speaker 2>A key post exploitation step is installing backdoors or setting

1137
00:58:55.320 --> 00:58:58.719
<v Speaker 2>up other persistence mechanisms. This ensures they can maintain access

1138
00:58:58.760 --> 00:59:00.880
<v Speaker 2>even if the initial vulnerability it gets patched or the

1139
00:59:00.880 --> 00:59:02.119
<v Speaker 2>system reboots, and.

1140
00:59:02.000 --> 00:59:04.880
<v Speaker 1>They also just try to break things. Yeah, denial of service.

1141
00:59:04.840 --> 00:59:08.639
<v Speaker 2>Yes, they can perform denial of service. Thus attacks this

1142
00:59:08.719 --> 00:59:11.599
<v Speaker 2>might involve flooding a service with traffic to overload it,

1143
00:59:12.039 --> 00:59:15.400
<v Speaker 2>or exploiting a specific vulnerability that causes the service or

1144
00:59:15.440 --> 00:59:19.239
<v Speaker 2>the entire system to crash or become unresponsive. An example

1145
00:59:19.280 --> 00:59:23.239
<v Speaker 2>mentioned in the source is Smblorus, a remote and uncredential

1146
00:59:23.400 --> 00:59:26.960
<v Speaker 2>doss attack against Microsoft Windows that exploited a flaw in

1147
00:59:27.000 --> 00:59:31.480
<v Speaker 2>the SMB protocol to consume excessive memory, potentially crashing the system.

1148
00:59:31.559 --> 00:59:34.280
<v Speaker 1>Okay, now let's talk about Interpreter. This always comes up

1149
00:59:34.280 --> 00:59:38.480
<v Speaker 1>when talking about Metasploid. It's described as the post exploitation powerhouse.

1150
00:59:38.679 --> 00:59:39.800
<v Speaker 1>What makes it so special.

1151
00:59:40.239 --> 00:59:44.920
<v Speaker 2>Interpreter is essentially Metasploid's advanced feature rich payload. It gets

1152
00:59:44.920 --> 00:59:47.920
<v Speaker 2>loaded into the memory of the compromise machine and provides

1153
00:59:47.960 --> 00:59:52.039
<v Speaker 2>an incredibly flexible and extensible command shell, allowing automation of

1154
00:59:52.079 --> 00:59:57.239
<v Speaker 2>many post exploitation tasks. It's largely replaced older, less dynamic methods.

1155
00:59:57.719 --> 01:00:00.440
<v Speaker 2>Its real power is its ability to run into hirely

1156
01:00:00.480 --> 01:00:04.440
<v Speaker 2>in memory, often avoiding writing files to disc making it stealthier.

1157
01:00:04.599 --> 01:00:06.480
<v Speaker 1>Give me some examples. What kind of things can you

1158
01:00:06.480 --> 01:00:08.960
<v Speaker 1>do once you have a interpreter session? Oh a lot.

1159
01:00:09.280 --> 01:00:11.880
<v Speaker 2>It has a whole suite of built in commands. Basic

1160
01:00:11.920 --> 01:00:14.599
<v Speaker 2>system commands like get tuids see what user you're running as,

1161
01:00:14.719 --> 01:00:18.440
<v Speaker 2>get tupid, get the process id PS, list running processes,

1162
01:00:18.639 --> 01:00:21.400
<v Speaker 2>sink and FOE, get OS details alls some stuff. Full

1163
01:00:21.400 --> 01:00:26.199
<v Speaker 2>filesystem commands dot, LCDPWD like Linux upload download files between

1164
01:00:26.239 --> 01:00:30.039
<v Speaker 2>your machine and the victim, edit files directly, cat file contents.

1165
01:00:30.360 --> 01:00:32.000
<v Speaker 2>You have extensive control.

1166
01:00:32.440 --> 01:00:35.760
<v Speaker 1>Can it interact with the user's desktop or peripherals.

1167
01:00:36.119 --> 01:00:38.920
<v Speaker 2>Yes, that's where it gets really powerful for surveillance. UI

1168
01:00:39.039 --> 01:00:42.480
<v Speaker 2>interaction commands like screenshot to grab the desktop, keyscan start,

1169
01:00:42.559 --> 01:00:45.679
<v Speaker 2>keyscan stop keyscin dump for keylog and capturing keystrokes. Even

1170
01:00:45.719 --> 01:00:48.280
<v Speaker 2>webcam snap to take pictures from the webcam if available.

1171
01:00:48.599 --> 01:00:52.880
<v Speaker 1>WHOA, What about escalating privileges or dumping credentials.

1172
01:00:52.360 --> 01:00:56.719
<v Speaker 2>Absolutely key tasks for privileged escalation and data dumping. Interpreter

1173
01:00:56.840 --> 01:00:59.719
<v Speaker 2>has the get system command, which tries various techniques to

1174
01:01:00.039 --> 01:01:03.159
<v Speaker 2>escalate to the system user on Windows highest privileged level.

1175
01:01:03.639 --> 01:01:06.239
<v Speaker 2>Hash dump attempts to extract the password hashes from the

1176
01:01:06.280 --> 01:01:10.199
<v Speaker 2>SAM database and crucially, it integrates mimicat's functionality.

1177
01:01:10.519 --> 01:01:13.800
<v Speaker 1>Mimicats is famous for credential dumping right exactly.

1178
01:01:14.079 --> 01:01:18.519
<v Speaker 2>A materpreter can load mimicats directly into memory to extract plaintext, passwords,

1179
01:01:18.559 --> 01:01:22.159
<v Speaker 2>corberos tickets, and password hashes directly from the memory of

1180
01:01:22.239 --> 01:01:26.039
<v Speaker 2>processes like LSAs dot ex. It often needs to migrate

1181
01:01:26.079 --> 01:01:29.440
<v Speaker 2>into that lsaas dot ex process first. It can also

1182
01:01:29.480 --> 01:01:33.760
<v Speaker 2>try to bypasswhack user account control on Windows.

1183
01:01:33.519 --> 01:01:36.119
<v Speaker 1>And maintaining persistence getting back in later.

1184
01:01:36.280 --> 01:01:39.480
<v Speaker 2>Interpreters can help with persistence. Commands like get gee can

1185
01:01:39.599 --> 01:01:43.880
<v Speaker 2>enable remote desktop access. There are also specific metasplit post

1186
01:01:43.920 --> 01:01:48.360
<v Speaker 2>exploitation modules for setting up more robust backdoors like installment

1187
01:01:48.480 --> 01:01:49.119
<v Speaker 2>MIC backdoor.

1188
01:01:49.559 --> 01:01:52.519
<v Speaker 1>What about networking from the compromise machine.

1189
01:01:52.400 --> 01:01:56.360
<v Speaker 2>Crucial for moving laterally. Networking commands like ipconfig and route

1190
01:01:56.400 --> 01:02:00.679
<v Speaker 2>help you understand the victim machines network configuration date allows

1191
01:02:00.679 --> 01:02:03.440
<v Speaker 2>you to set up port forwarding, relaying traffic through the

1192
01:02:03.519 --> 01:02:05.559
<v Speaker 2>victim machine. This is essential for pivoting.

1193
01:02:05.719 --> 01:02:06.159
<v Speaker 1>Pivoting.

1194
01:02:06.440 --> 01:02:09.519
<v Speaker 2>Pivoting is using the initially compromised machine as a foothold

1195
01:02:09.519 --> 01:02:12.039
<v Speaker 2>to attack other machines on the same internal network that

1196
01:02:12.079 --> 01:02:15.320
<v Speaker 2>you can't root directly. Interpreter is excellent for this, allowing

1197
01:02:15.320 --> 01:02:17.480
<v Speaker 2>you to add routes so you can scan and attack

1198
01:02:17.559 --> 01:02:19.519
<v Speaker 2>internal systems through your Materpreter session.

1199
01:02:19.880 --> 01:02:23.000
<v Speaker 1>Can it sniff network traffic passing through the compromised host.

1200
01:02:23.199 --> 01:02:28.760
<v Speaker 2>Yes, it has packet sniffing capabilities, sniffer interfaces, lists network interfaces,

1201
01:02:28.840 --> 01:02:31.559
<v Speaker 2>sniffer start, sniffer stops, sniffer dump let you capture traffic

1202
01:02:31.559 --> 01:02:33.679
<v Speaker 2>on the victim machine and save it as a pcap

1203
01:02:33.800 --> 01:02:37.559
<v Speaker 2>file for later analysis with tools like wireshark or TCP dump.

1204
01:02:37.679 --> 01:02:39.800
<v Speaker 1>Credential harvesting too, Yes, there.

1205
01:02:39.679 --> 01:02:42.960
<v Speaker 2>Are modules like post Windows gatherfish Windows credentials that can

1206
01:02:43.000 --> 01:02:46.000
<v Speaker 2>pop up fake login prompts to try and trick users

1207
01:02:46.000 --> 01:02:47.280
<v Speaker 2>into entering their credentials.

1208
01:02:47.400 --> 01:02:50.559
<v Speaker 1>Wow, and just general enumeration. Once you're insight.

1209
01:02:50.480 --> 01:02:54.159
<v Speaker 2>Lots of that. Post exploitation modules like wineum can gather

1210
01:02:54.239 --> 01:02:58.599
<v Speaker 2>huge amounts of information installed applications, network shares, user accounts policies.

1211
01:02:59.039 --> 01:03:02.000
<v Speaker 2>The Gathering Suite module can scan the local network for

1212
01:03:02.119 --> 01:03:03.199
<v Speaker 2>other live hosts.

1213
01:03:03.760 --> 01:03:07.400
<v Speaker 1>You mentioned routing traffic through this session for pivoting. How

1214
01:03:07.440 --> 01:03:08.840
<v Speaker 1>did that work with other tools?

1215
01:03:09.199 --> 01:03:13.079
<v Speaker 2>Materpreter's post multimanage out or root module automatically adds the

1216
01:03:13.119 --> 01:03:17.119
<v Speaker 2>necessary routes in metasplit. Then you can use Metasplate's auxiliary

1217
01:03:17.119 --> 01:03:20.480
<v Speaker 2>service SoCs for a module to set up metasplate itself

1218
01:03:20.519 --> 01:03:24.800
<v Speaker 2>as a soocks proxy server. Now you can configure other

1219
01:03:24.840 --> 01:03:27.559
<v Speaker 2>tools on your own attack machine, like enmap or a

1220
01:03:27.599 --> 01:03:30.840
<v Speaker 2>web browser to use this proxy, often via a tool

1221
01:03:30.880 --> 01:03:34.719
<v Speaker 2>called proxy chains. This routes their traffic through the Materpreter session,

1222
01:03:34.760 --> 01:03:38.039
<v Speaker 2>allowing you scan and interact with the victim's internal network

1223
01:03:38.079 --> 01:03:40.360
<v Speaker 2>as if you were sitting on the compromise machine.

1224
01:03:40.559 --> 01:03:43.519
<v Speaker 1>That's incredibly powerful. Can you automate some of these post

1225
01:03:43.559 --> 01:03:44.599
<v Speaker 1>exploitation steps.

1226
01:03:44.719 --> 01:03:47.840
<v Speaker 2>Yes, you can use the autoorunscript option in metasploit to

1227
01:03:47.880 --> 01:03:51.119
<v Speaker 2>automatically run a Materpreter script like scraper, dot orb or

1228
01:03:51.159 --> 01:03:54.159
<v Speaker 2>winum as soon as a session is established, automating that

1229
01:03:54.239 --> 01:03:55.559
<v Speaker 2>initial information gathering.

1230
01:03:56.079 --> 01:03:58.639
<v Speaker 1>And how does materpreter try to keep its connection alive.

1231
01:03:58.880 --> 01:04:01.039
<v Speaker 1>If say the network drops.

1232
01:04:00.679 --> 01:04:04.599
<v Speaker 2>Briefly it uses transports, you can add backup transports using

1233
01:04:04.599 --> 01:04:07.920
<v Speaker 2>transport ad maybe setting up a reverse TTP or reverse

1234
01:04:07.960 --> 01:04:12.719
<v Speaker 2>TTPs transport alongside the initial TCP connection. These use standard

1235
01:04:12.719 --> 01:04:15.599
<v Speaker 2>webports and protocols, which are often less likely to be

1236
01:04:15.639 --> 01:04:18.400
<v Speaker 2>blocked by firewalls and can help maintain the session if

1237
01:04:18.400 --> 01:04:19.840
<v Speaker 2>the primary connection fails.

1238
01:04:20.119 --> 01:04:23.559
<v Speaker 1>Okay. One last tool in the metasploit arsenal MSF venom.

1239
01:04:24.039 --> 01:04:25.400
<v Speaker 1>What's his specific job?

1240
01:04:25.880 --> 01:04:30.880
<v Speaker 2>Msf venom is Metasploit's standalone payload generator and encoder. Its

1241
01:04:30.960 --> 01:04:34.000
<v Speaker 2>job is to create the actual malicious files or scripts

1242
01:04:34.079 --> 01:04:37.000
<v Speaker 2>that you'll deliver to the victim, perhaps via exploit or

1243
01:04:37.039 --> 01:04:38.480
<v Speaker 2>maybe through social engineering.

1244
01:04:38.559 --> 01:04:40.639
<v Speaker 1>She used to build the interpreter payload.

1245
01:04:40.280 --> 01:04:43.800
<v Speaker 2>For example, exactly use msfvenom to generate payloads for various

1246
01:04:43.800 --> 01:04:48.239
<v Speaker 2>operating systems Windows, Linux, Android, mac os architectures by eighty six,

1247
01:04:48.280 --> 01:04:52.000
<v Speaker 2>by sixty four ARM and formats ex files, DLLs, shell

1248
01:04:52.039 --> 01:04:55.119
<v Speaker 2>code scripts. It also incorporates powerful encoders.

1249
01:04:55.199 --> 01:04:56.519
<v Speaker 1>Wiringcoder is so important.

1250
01:04:56.840 --> 01:05:01.000
<v Speaker 2>Encoders are crucial for evading antivirus software where and bypassing

1251
01:05:01.000 --> 01:05:05.360
<v Speaker 2>and organization's defenses. They work by obfuscating the payloads code,

1252
01:05:05.639 --> 01:05:08.840
<v Speaker 2>changing its signature so that basic anti virus scanners might

1253
01:05:08.880 --> 01:05:13.119
<v Speaker 2>not recognize it as malicious. Metasploit includes several enquoders, like

1254
01:05:13.119 --> 01:05:18.159
<v Speaker 2>the polymorphic chicatagan i encoder. However, av products are constantly updated,

1255
01:05:18.199 --> 01:05:22.440
<v Speaker 2>so standard encoders often get detected quickly. Pen testers frequently

1256
01:05:22.440 --> 01:05:26.280
<v Speaker 2>need to use custom encoding techniques or combiningcoders to improve evasion.

1257
01:05:26.840 --> 01:05:28.679
<v Speaker 1>Okay, so we've spent a lot of time on server

1258
01:05:28.719 --> 01:05:31.599
<v Speaker 1>side exploits and the powerful tools used there. But you

1259
01:05:31.639 --> 01:05:34.440
<v Speaker 1>mentioned earlier that the landscape is shifting and often the

1260
01:05:34.440 --> 01:05:37.480
<v Speaker 1>most successful attacks now target the human element and client

1261
01:05:37.519 --> 01:05:41.960
<v Speaker 1>side systems. Why is that becoming the new frontier?

1262
01:05:42.519 --> 01:05:45.760
<v Speaker 2>Well, partly because server side security has gotten better. Generally speaking,

1263
01:05:45.800 --> 01:05:50.280
<v Speaker 2>companies spend more on securing servers, but endpoints laptops, desktops,

1264
01:05:50.320 --> 01:05:54.679
<v Speaker 2>mobile devices, they're often less consistently patched, running more diverse software,

1265
01:05:54.960 --> 01:05:57.800
<v Speaker 2>and critically, they're operated by humans who can be tricked.

1266
01:05:57.960 --> 01:05:59.440
<v Speaker 1>So the user is the weak link.

1267
01:06:00.440 --> 01:06:04.719
<v Speaker 2>Yes, this makes client machines a softer target. Attackers realize

1268
01:06:04.719 --> 01:06:07.599
<v Speaker 2>that tricking a user into running malware can often bypass

1269
01:06:07.639 --> 01:06:12.440
<v Speaker 2>even sophisticated network perameter defenses entirely, the most successful attacks

1270
01:06:12.480 --> 01:06:13.360
<v Speaker 2>target endpoints.

1271
01:06:13.599 --> 01:06:17.239
<v Speaker 1>How does reconnaissance work when you're targeting clients specifically? How

1272
01:06:17.239 --> 01:06:19.400
<v Speaker 1>do attackers' profile potential victims?

1273
01:06:19.480 --> 01:06:23.400
<v Speaker 2>Metasploit has modules for this too, like Auxiliary Gather Browser info.

1274
01:06:23.519 --> 01:06:25.400
<v Speaker 2>If an attacker can get a user to visit a

1275
01:06:25.440 --> 01:06:28.840
<v Speaker 2>web page they control, this module can fingerprint the victim's

1276
01:06:28.880 --> 01:06:34.000
<v Speaker 2>browser OS, install plugins like flash, Java, and check JavaScript support.

1277
01:06:34.280 --> 01:06:37.960
<v Speaker 2>This intel helps them choose the most effective client site exploit.

1278
01:06:37.840 --> 01:06:40.960
<v Speaker 1>And bypassing antivirus on the client machine, how do they

1279
01:06:40.960 --> 01:06:43.519
<v Speaker 1>get their malicious payloads past endpoint security?

1280
01:06:43.960 --> 01:06:47.159
<v Speaker 2>Again, this often comes down to antivirus idea of sifts

1281
01:06:47.159 --> 01:06:51.079
<v Speaker 2>bypass using custom payloads and encoders generated with MSF, Venom

1282
01:06:51.239 --> 01:06:55.119
<v Speaker 2>or other tools. Standard, well known payloads generated by metasploit

1283
01:06:55.159 --> 01:06:58.000
<v Speaker 2>are likely to get caught by modern av so attackers

1284
01:06:58.039 --> 01:07:01.159
<v Speaker 2>need to modify them, you sophisticated and curing or packing techniques,

1285
01:07:01.280 --> 01:07:04.719
<v Speaker 2>or even write completely custom malware to evade detection. It's

1286
01:07:04.760 --> 01:07:06.199
<v Speaker 2>that constant cat and mouse game.

1287
01:07:06.400 --> 01:07:09.800
<v Speaker 1>What are some specific client side attack techniques that really

1288
01:07:10.320 --> 01:07:13.519
<v Speaker 1>leverage this human element or software flaws on the client?

1289
01:07:13.679 --> 01:07:17.599
<v Speaker 2>Oh, there are many metasploit macro exploits are common malicious

1290
01:07:17.679 --> 01:07:21.920
<v Speaker 2>VBA macros embedded in office documents, word excel. If the

1291
01:07:22.000 --> 01:07:26.000
<v Speaker 2>victim enables macros enable content, the macro executes and can

1292
01:07:26.039 --> 01:07:27.320
<v Speaker 2>download and run a payload.

1293
01:07:27.400 --> 01:07:30.039
<v Speaker 1>Right those scary yellow warning bars and office exactly.

1294
01:07:30.480 --> 01:07:34.599
<v Speaker 2>Then there are human interface device HID attacks. These use

1295
01:07:34.679 --> 01:07:38.079
<v Speaker 2>USB devices like the keen c Usb hid or similar

1296
01:07:38.119 --> 01:07:40.239
<v Speaker 2>tools that pretend to be a keyboard or mouse when

1297
01:07:40.239 --> 01:07:40.840
<v Speaker 2>plugged in.

1298
01:07:41.159 --> 01:07:42.320
<v Speaker 1>So the computer just trusts it.

1299
01:07:42.480 --> 01:07:45.639
<v Speaker 2>Yeah. The device can then rapidly type commands to download

1300
01:07:45.679 --> 01:07:48.639
<v Speaker 2>and execute malware, often faster than a human could react,

1301
01:07:48.880 --> 01:07:52.360
<v Speaker 2>completely bypassing software based security controls because it looks like

1302
01:07:52.440 --> 01:07:53.480
<v Speaker 2>legitimate user input.

1303
01:07:53.719 --> 01:07:54.719
<v Speaker 1>Wow, what else?

1304
01:07:54.920 --> 01:07:59.440
<v Speaker 2>The HTML application HTA attack is quite effective against Windows users.

1305
01:08:00.000 --> 01:08:03.000
<v Speaker 2>Dot HGA files are basically HTML files that run with

1306
01:08:03.039 --> 01:08:09.360
<v Speaker 2>higher privileges capable of executing scripting languages like VBScript or JScript. Metasploits.

1307
01:08:09.480 --> 01:08:13.519
<v Speaker 2>HTA webserver module hosts some malicious HTA file. If an

1308
01:08:13.519 --> 01:08:16.279
<v Speaker 2>attacker tricks a user into downloading and running it, it

1309
01:08:16.319 --> 01:08:19.279
<v Speaker 2>will prompt the user for confirmation. But because the underlying

1310
01:08:19.399 --> 01:08:24.279
<v Speaker 2>MGAHG process is a legitimate sign Microsoft Windows application, many

1311
01:08:24.359 --> 01:08:26.319
<v Speaker 2>users will trust it and will allow it to run,

1312
01:08:26.479 --> 01:08:28.039
<v Speaker 2>giving the attacker code execution.

1313
01:08:28.520 --> 01:08:32.399
<v Speaker 1>That's incredibly deceptive, playing on trust in legitimate Windows components.

1314
01:08:32.760 --> 01:08:35.800
<v Speaker 1>What about backdooring legitimate software as someone downloads it.

1315
01:08:36.119 --> 01:08:39.199
<v Speaker 2>That's possible via Man in the middle MIKM attacks often

1316
01:08:39.239 --> 01:08:42.279
<v Speaker 2>on insecure networks like public Wi Fi. Using frameworks like

1317
01:08:42.399 --> 01:08:45.319
<v Speaker 2>MITMF man in the middle framework, which often requires ARP

1318
01:08:45.479 --> 01:08:49.159
<v Speaker 2>poisoning to intercept traffic, an attacker can intercept unencrypted downloads.

1319
01:08:49.199 --> 01:08:51.920
<v Speaker 2>They can then patch some executables like maybe notepad, dot

1320
01:08:51.960 --> 01:08:54.640
<v Speaker 2>exc or putty dot ex on the fly as the

1321
01:08:54.720 --> 01:08:55.720
<v Speaker 2>victim downloads them.

1322
01:08:55.840 --> 01:08:57.960
<v Speaker 1>So the victim gets a file that looks and maybe

1323
01:08:58.000 --> 01:08:59.159
<v Speaker 1>even works like the real.

1324
01:08:59.000 --> 01:09:02.920
<v Speaker 2>Thing exactly, but it's been secretly backdoored in transit to

1325
01:09:02.960 --> 01:09:07.039
<v Speaker 2>include the attacker's payload. They run the seemingly legitimate program

1326
01:09:07.199 --> 01:09:11.359
<v Speaker 2>and the backdoor executes. Attackers can also craft mobile exploits,

1327
01:09:11.640 --> 01:09:15.319
<v Speaker 2>using m's venom to create malicious Linux trojans or Android

1328
01:09:15.319 --> 01:09:20.479
<v Speaker 2>backdoors packaged as dot appk files usually delivered via social engineering.

1329
01:09:20.640 --> 01:09:23.159
<v Speaker 2>For example, fake app stores phishing links.

1330
01:09:23.600 --> 01:09:26.359
<v Speaker 1>So it really seems like many, if not most, of

1331
01:09:26.399 --> 01:09:30.279
<v Speaker 1>these successful client side attacks ultimately rely on exploiting human

1332
01:09:30.279 --> 01:09:33.560
<v Speaker 1>trust or maybe just a lack of awareness, which brings

1333
01:09:33.640 --> 01:09:36.079
<v Speaker 1>us to the Social Engineer Toolkit s set.

1334
01:09:36.479 --> 01:09:39.000
<v Speaker 2>You're absolutely right, the human element is often the easiest

1335
01:09:39.039 --> 01:09:42.560
<v Speaker 2>path in the Social Engineer Toolkit. SSET, created by Dave Kennedy,

1336
01:09:42.920 --> 01:09:47.600
<v Speaker 2>is an incredibly powerful open source penetration testing framework specifically

1337
01:09:47.640 --> 01:09:50.920
<v Speaker 2>designed to perform advanced attacks against the human element. It's

1338
01:09:50.960 --> 01:09:54.079
<v Speaker 2>a standard tool for simulating sophisticated phishing and other social

1339
01:09:54.119 --> 01:09:56.279
<v Speaker 2>engineering campaigns during a pen test.

1340
01:09:56.479 --> 01:09:59.880
<v Speaker 1>What kinds of attack vectors does set automate or make easier?

1341
01:10:00.159 --> 01:10:04.199
<v Speaker 2>It streamlines several key social engineering attacks. It's great for

1342
01:10:04.239 --> 01:10:09.000
<v Speaker 2>spearfishing campaigns, sending highly malicious emails to target specific users,

1343
01:10:09.520 --> 01:10:12.760
<v Speaker 2>often with options to spoof the sender's email address to

1344
01:10:12.760 --> 01:10:16.680
<v Speaker 2>make it look legitimate. Its web attack vectors are very popular.

1345
01:10:16.760 --> 01:10:20.920
<v Speaker 2>For instance, the HTA attack method within set can automatically

1346
01:10:21.000 --> 01:10:23.880
<v Speaker 2>clone a legitimate website like a company portal or a

1347
01:10:23.920 --> 01:10:28.800
<v Speaker 2>popular service to create a more credible pretext for delivering

1348
01:10:28.800 --> 01:10:31.960
<v Speaker 2>a malicious payload when the user interacts with the fake.

1349
01:10:31.800 --> 01:10:36.000
<v Speaker 1>Site, combining website cloning with payload delivery clever very.

1350
01:10:36.079 --> 01:10:38.840
<v Speaker 2>It also offers a multi attack web method that combines

1351
01:10:38.880 --> 01:10:42.039
<v Speaker 2>several different browser exploits and attack techniques under a single

1352
01:10:42.119 --> 01:10:45.720
<v Speaker 2>malicious link when the victim clicks set tries them one

1353
01:10:45.760 --> 01:10:48.479
<v Speaker 2>by one unless a successful attack is launched, increasing the

1354
01:10:48.560 --> 01:10:52.000
<v Speaker 2>chances of compromising different browser or plug in versions. It

1355
01:10:52.039 --> 01:10:55.479
<v Speaker 2>also includes an infectious media generator for creating malicious USB

1356
01:10:55.680 --> 01:10:58.600
<v Speaker 2>drives or other files designed to execute payloads when open.

1357
01:10:58.720 --> 01:11:02.960
<v Speaker 1>Wow. Okay, we have taking an absolute whirlwind tour through

1358
01:11:02.960 --> 01:11:04.840
<v Speaker 1>the complex world of penetration testing.

1359
01:11:04.960 --> 01:11:09.079
<v Speaker 2>We certainly have from understanding why it's so fundamentally crucial

1360
01:11:09.159 --> 01:11:12.680
<v Speaker 2>in our web centric world to really digging into the

1361
01:11:12.720 --> 01:11:16.039
<v Speaker 2>sophisticated tools and techniques that ethical hackers employ.

1362
01:11:16.279 --> 01:11:18.840
<v Speaker 1>Yeah, we explored setting up your own practice lab with

1363
01:11:18.920 --> 01:11:23.000
<v Speaker 1>Collie Linux, the meticulous art of gathering intelligence, the nitty

1364
01:11:23.039 --> 01:11:26.319
<v Speaker 1>gritty of exploiting all sorts of vulnerabilities.

1365
01:11:25.680 --> 01:11:28.720
<v Speaker 2>Right from sequel injections and cross sites scripting right up

1366
01:11:28.720 --> 01:11:32.279
<v Speaker 2>to exploiting major flaws like eternal blue, and then even

1367
01:11:32.319 --> 01:11:35.760
<v Speaker 2>how attackers manipulate that human element with social engineering.

1368
01:11:35.960 --> 01:11:38.640
<v Speaker 1>This deep dive. The aim was really to give you

1369
01:11:38.680 --> 01:11:41.640
<v Speaker 1>a shortcut to being truly well informed on this topic,

1370
01:11:41.760 --> 01:11:45.720
<v Speaker 1>packed with hopefully some surprising facts and practical insights that

1371
01:11:45.840 --> 01:11:48.399
<v Speaker 1>go way beyond the typical headlines.

1372
01:11:48.439 --> 01:11:51.840
<v Speaker 2>Absolutely, it's a complex field, but understanding the attackers' perspective

1373
01:11:51.880 --> 01:11:53.560
<v Speaker 2>is key to building better defenses.

1374
01:11:53.760 --> 01:11:57.319
<v Speaker 1>So here's a final thought. As digital defenses continue to evolve,

1375
01:11:57.479 --> 01:12:01.119
<v Speaker 1>and they are evolving rapidly, that human element often remains

1376
01:12:01.119 --> 01:12:04.840
<v Speaker 1>the weakest link. Considering everything we've unpacked today, all the techniques,

1377
01:12:04.880 --> 01:12:09.159
<v Speaker 1>the psychology, what surprising ways might you personally be susceptible

1378
01:12:09.199 --> 01:12:12.399
<v Speaker 1>to the very techniques designed to test these systems. Something

1379
01:12:12.399 --> 01:12:14.199
<v Speaker 1>to mull over until our next deep dive.