WEBVTT

1
00:00:00.080 --> 00:00:01.960
<v Speaker 1>Welcome to the deep dive. We take a stack of

2
00:00:02.000 --> 00:00:05.839
<v Speaker 1>information and extract those surprising nuggets of knowledge. Today we're

3
00:00:05.839 --> 00:00:09.640
<v Speaker 1>plunging into a truly fascinating and frankly a bit in

4
00:00:09.759 --> 00:00:14.359
<v Speaker 1>settling area that has entirely redefined cybersecurity, hacking the cloud.

5
00:00:15.080 --> 00:00:17.320
<v Speaker 1>Our mission for this deep dive really is to understand

6
00:00:17.359 --> 00:00:20.480
<v Speaker 1>just how profoundly the landscape of digital intrusion has shifted.

7
00:00:20.760 --> 00:00:23.280
<v Speaker 1>We're going to sort of shed the old mental models

8
00:00:23.280 --> 00:00:26.839
<v Speaker 1>of traditional network attacks and instead explore what it truly

9
00:00:26.920 --> 00:00:29.640
<v Speaker 1>means to hack like a ghost in our modern cloud

10
00:00:29.679 --> 00:00:33.280
<v Speaker 1>powered world. We're drawing our insights from Sparkflow's compelling work

11
00:00:33.600 --> 00:00:36.200
<v Speaker 1>how to Hack like a Ghost Breaching the Cloud.

12
00:00:36.479 --> 00:00:38.960
<v Speaker 2>And what's truly fascinating here, I think, is how the

13
00:00:39.079 --> 00:00:42.560
<v Speaker 2>very architecture of cloud computing, and also principles like DevOps

14
00:00:42.600 --> 00:00:45.320
<v Speaker 2>you know, which are designed for efficiency for speed, they

15
00:00:45.359 --> 00:00:48.840
<v Speaker 2>also kind of inadvertently create entirely new classes.

16
00:00:48.439 --> 00:00:50.200
<v Speaker 1>Of vulnerability right new ways.

17
00:00:50.200 --> 00:00:54.079
<v Speaker 2>In exactly, we'll discover how attackers can manipulate core infrastructure

18
00:00:54.079 --> 00:00:57.520
<v Speaker 2>elements from well virtually anywhere on Earth, which is a

19
00:00:57.560 --> 00:01:00.600
<v Speaker 2>stark contrast to the old days of simply mischie hopping

20
00:01:00.640 --> 00:01:03.560
<v Speaker 2>within a physical network a huge change.

21
00:01:04.000 --> 00:01:06.640
<v Speaker 1>So what does this cutting edge knowledge mean for you

22
00:01:06.719 --> 00:01:09.840
<v Speaker 1>listening in? Maybe you're prepping for a crucial meeting, or

23
00:01:09.920 --> 00:01:11.680
<v Speaker 1>just catching up on the field, or maybe you're just

24
00:01:11.719 --> 00:01:14.799
<v Speaker 1>driven by pure curiosity. Well, you're about to get a

25
00:01:14.879 --> 00:01:17.599
<v Speaker 1>unique shortcut to being well informed on the bleeding edge

26
00:01:17.599 --> 00:01:21.719
<v Speaker 1>of cybersecurity. We're going to trace a hacker's sophisticated journey

27
00:01:22.159 --> 00:01:26.040
<v Speaker 1>from setting up completely anonymous operations to taking over critical

28
00:01:26.079 --> 00:01:30.760
<v Speaker 1>cloud infrastructure and ultimately even accessing deeply personal data and

29
00:01:30.799 --> 00:01:34.519
<v Speaker 1>company emails. Okay, so let's unpack this. The book argues

30
00:01:34.519 --> 00:01:37.400
<v Speaker 1>that the entire zeitgeist, the spirit of the times, is

31
00:01:37.519 --> 00:01:41.760
<v Speaker 1>changing in cybersecurity. Why can't attackers just use their traditional

32
00:01:41.840 --> 00:01:44.159
<v Speaker 1>bag of tricks, you know, like a classic sequel injection

33
00:01:44.239 --> 00:01:47.239
<v Speaker 1>attack against these sprawling modern cloud companies.

34
00:01:47.400 --> 00:01:48.959
<v Speaker 2>Well, if we zoom out and connect this to the

35
00:01:49.000 --> 00:01:52.000
<v Speaker 2>bigger picture, it's really about a fundamental architectural shift. Think

36
00:01:52.000 --> 00:01:55.319
<v Speaker 2>about it. Companies aren't typically spinning up physical windows domain

37
00:01:55.319 --> 00:01:58.319
<v Speaker 2>controllers in their server rooms anymore, not usually.

38
00:01:58.120 --> 00:02:00.480
<v Speaker 1>Right, it's all cloud consoles now exactly.

39
00:02:00.760 --> 00:02:06.120
<v Speaker 2>Instead, they're launching databases, dock or containers, even entire identity

40
00:02:06.159 --> 00:02:09.680
<v Speaker 2>systems like active directory with literally one click in a

41
00:02:09.680 --> 00:02:14.439
<v Speaker 2>cloud environment, and this fundamentally alters the attacker's ultimate goal.

42
00:02:14.520 --> 00:02:15.280
<v Speaker 1>It's huge.

43
00:02:16.159 --> 00:02:19.520
<v Speaker 2>It's no longer just about taking control of individual machines.

44
00:02:19.520 --> 00:02:23.800
<v Speaker 2>That's almost secondary. Sometimes it's about gaining control over the

45
00:02:24.000 --> 00:02:27.039
<v Speaker 2>entire infrastructure itself, the control plane.

46
00:02:27.080 --> 00:02:30.000
<v Speaker 1>In DevOps too, you mentioned it's more than just a buzzword,

47
00:02:30.039 --> 00:02:31.520
<v Speaker 1>isn't it. It feels like it changes everything.

48
00:02:31.560 --> 00:02:33.039
<v Speaker 3>Oh, absolutely exactly.

49
00:02:33.199 --> 00:02:36.479
<v Speaker 2>DevOps principles things like infrastructure as code, where.

50
00:02:36.360 --> 00:02:38.800
<v Speaker 1>The whole setup is basically a script precisely.

51
00:02:39.280 --> 00:02:42.240
<v Speaker 2>That and containerization mean companies are in this state of

52
00:02:42.479 --> 00:02:47.000
<v Speaker 2>constant change. They're deploying new code, new applications at lightning speed.

53
00:02:47.360 --> 00:02:49.759
<v Speaker 2>The old it mantra you know, if it's working, don't

54
00:02:49.840 --> 00:02:51.719
<v Speaker 2>change it, that's completely out the window.

55
00:02:51.840 --> 00:02:54.919
<v Speaker 1>Okay, So constant change, more opportunities for.

56
00:02:54.919 --> 00:02:58.199
<v Speaker 2>Mistakes, that's part of it. This rapid evolution means that

57
00:02:58.319 --> 00:03:01.719
<v Speaker 2>vulnerabilities that might have been mind or may be overlooked

58
00:03:01.879 --> 00:03:05.120
<v Speaker 2>in a classic setup, they can acquire what the source

59
00:03:05.159 --> 00:03:09.520
<v Speaker 2>calls lethal potential in the cloud. Your traditional hacker intuition,

60
00:03:09.639 --> 00:03:11.879
<v Speaker 2>which might have served you well in the past, well,

61
00:03:11.960 --> 00:03:14.479
<v Speaker 2>it definitely benefits from some small adjustments.

62
00:03:14.520 --> 00:03:15.879
<v Speaker 3>Let's say to stay effective.

63
00:03:16.080 --> 00:03:19.560
<v Speaker 1>Got a doubt, Okay, So before any actual hacking begins,

64
00:03:19.919 --> 00:03:24.240
<v Speaker 1>the book emphasizes a crucial first step, becoming a ghost.

65
00:03:24.719 --> 00:03:29.039
<v Speaker 1>This means focusing heavily on operational security OPSEC and building

66
00:03:29.080 --> 00:03:33.240
<v Speaker 1>an anonymous, efficient hacking infrastructure. Why is this initial set

67
00:03:33.319 --> 00:03:37.159
<v Speaker 1>up so incredibly vital, especially for real world attackers, not

68
00:03:37.319 --> 00:03:38.319
<v Speaker 1>just you know testers.

69
00:03:38.520 --> 00:03:42.000
<v Speaker 2>Yeah, this raises a really important question about anonymity. It's

70
00:03:42.039 --> 00:03:45.520
<v Speaker 2>critical Unlike professional red teamers or penetration testers who often

71
00:03:45.560 --> 00:03:46.879
<v Speaker 2>have a clear scope, maybe even do.

72
00:03:46.919 --> 00:03:48.960
<v Speaker 1>Over the permission basically.

73
00:03:48.639 --> 00:03:51.960
<v Speaker 2>Right, real hackers, though, they're betting their actual freedom on

74
00:03:52.000 --> 00:03:55.719
<v Speaker 2>their ability to remain completely anonymous. And the source makes

75
00:03:55.719 --> 00:03:59.520
<v Speaker 2>it crystal clear. Even popular VPN services will always always

76
00:03:59.639 --> 00:04:03.319
<v Speaker 2>keep some form of logs, always, despite the marketing, despite

77
00:04:03.319 --> 00:04:06.199
<v Speaker 2>the marketing, and even privacy networks like tour aren't a

78
00:04:06.199 --> 00:04:09.680
<v Speaker 2>magical shield. They have limitations. You have to pay, As

79
00:04:09.719 --> 00:04:12.439
<v Speaker 2>the book says, as much attention to your physical trail

80
00:04:12.479 --> 00:04:16.279
<v Speaker 2>as you do to your Internet fingerprint. Leave no trace anywhere,

81
00:04:17.040 --> 00:04:17.920
<v Speaker 2>so walk.

82
00:04:17.720 --> 00:04:21.240
<v Speaker 1>Us through it. What does this anonymous setup actually look

83
00:04:21.360 --> 00:04:23.920
<v Speaker 1>like in practice? The book gets pretty specific.

84
00:04:24.240 --> 00:04:28.680
<v Speaker 2>It's all about layers, layers of obfuscation. First, an attacker

85
00:04:28.680 --> 00:04:32.399
<v Speaker 2>would likely use an ephemeral operating system, something like TAILS

86
00:04:32.560 --> 00:04:33.800
<v Speaker 2>loaded onto a USB.

87
00:04:33.720 --> 00:04:36.240
<v Speaker 1>Drive fhmeral meaning temporary exactly.

88
00:04:36.639 --> 00:04:40.160
<v Speaker 2>This OS is designed to flush everything away on every reboot.

89
00:04:40.360 --> 00:04:43.639
<v Speaker 2>Nothing sticks, and it forces all Internet connections through tour,

90
00:04:44.000 --> 00:04:46.199
<v Speaker 2>making it incredibly difficult to trace back.

91
00:04:46.279 --> 00:04:47.319
<v Speaker 1>Okay, step one.

92
00:04:47.519 --> 00:04:49.759
<v Speaker 2>Then what From there? They connect to a series of

93
00:04:49.759 --> 00:04:53.839
<v Speaker 2>bouncing servers. These are virtual hosts like vms, set up

94
00:04:53.839 --> 00:04:57.959
<v Speaker 2>anonymously in different locations, maybe different providers. Crucially, these bouncing

95
00:04:57.959 --> 00:04:59.920
<v Speaker 2>servers never directly interact with the target.

96
00:05:00.360 --> 00:05:00.959
<v Speaker 3>That's key.

97
00:05:01.040 --> 00:05:02.079
<v Speaker 1>You're like middleman.

98
00:05:02.079 --> 00:05:06.160
<v Speaker 2>Exactly, secure staging grounds. They host management tools like Terraform,

99
00:05:06.319 --> 00:05:11.240
<v Speaker 2>Docker stuff to build the next layer. The actual attack infrastructure,

100
00:05:11.319 --> 00:05:14.360
<v Speaker 2>the servers doing the real work, is even more fleeting,

101
00:05:14.759 --> 00:05:17.639
<v Speaker 2>used for only a few days maybe, and completely unique

102
00:05:17.680 --> 00:05:20.160
<v Speaker 2>to each operation, then destroyed.

103
00:05:20.800 --> 00:05:25.560
<v Speaker 1>Wow. This level of automation using tools like Docker and Terraform,

104
00:05:26.079 --> 00:05:28.680
<v Speaker 1>it all sounds like adopting a DevOps mindset for the

105
00:05:28.720 --> 00:05:30.000
<v Speaker 1>hacking process itself.

106
00:05:30.040 --> 00:05:33.199
<v Speaker 2>That's spot on it really is. It's about embracing efficiency.

107
00:05:33.519 --> 00:05:36.480
<v Speaker 2>By automating the setup, it becomes much easier to spring

108
00:05:36.560 --> 00:05:40.560
<v Speaker 2>fully configured attacking servers into existence, pop them up, tear

109
00:05:40.600 --> 00:05:43.600
<v Speaker 2>them down, and that significantly reduces the gens of making

110
00:05:43.600 --> 00:05:45.680
<v Speaker 2>critical mistakes when you're operating under pressure.

111
00:05:45.759 --> 00:05:48.560
<v Speaker 1>Makes sense, fewer manual steps, fewer errors, right.

112
00:05:48.800 --> 00:05:50.920
<v Speaker 2>The book gives examples of how an attacker can use

113
00:05:50.920 --> 00:05:53.839
<v Speaker 2>simple commands like Docker, pul potion stuff to grab a

114
00:05:53.839 --> 00:05:57.319
<v Speaker 2>pre built hacking tool, or terraform apply to automatically deploy

115
00:05:57.399 --> 00:05:59.319
<v Speaker 2>their command and control servers their C two.

116
00:05:59.399 --> 00:06:01.279
<v Speaker 1>That's the hacker mission control right.

117
00:06:01.319 --> 00:06:05.480
<v Speaker 2>Yeah, basically where they manage the compromise systems and Terraform

118
00:06:05.519 --> 00:06:09.120
<v Speaker 2>sets it all up even with secure connections, TLS certificates

119
00:06:09.199 --> 00:06:09.680
<v Speaker 2>the works.

120
00:06:09.839 --> 00:06:15.040
<v Speaker 1>Okay, anonymous infrastructure meticulously set up. What's next reconnaissance. I

121
00:06:15.079 --> 00:06:19.199
<v Speaker 1>assume our fictional targets in this deep dive are Gretch, Politico,

122
00:06:19.560 --> 00:06:23.160
<v Speaker 1>a firm specializing in political campaigns, and its close partner

123
00:06:23.399 --> 00:06:27.000
<v Speaker 1>ms r ADS. How do hackers even begin to dig

124
00:06:27.040 --> 00:06:29.759
<v Speaker 1>into these targets in a vast cloud environment, Where do

125
00:06:29.800 --> 00:06:30.399
<v Speaker 1>you start looking?

126
00:06:30.600 --> 00:06:30.759
<v Speaker 3>Well?

127
00:06:30.800 --> 00:06:34.000
<v Speaker 2>This phase is all about what the book calls healthy stocking.

128
00:06:34.120 --> 00:06:34.560
<v Speaker 3>Huh.

129
00:06:34.639 --> 00:06:38.720
<v Speaker 2>It means gathering every piece of public facing information imaginable,

130
00:06:38.920 --> 00:06:42.759
<v Speaker 2>just scooping it all up. The source emphasizes searching platforms

131
00:06:42.759 --> 00:06:47.240
<v Speaker 2>like SlideShare, loogle drives, script document cloud places where documents might.

132
00:06:47.160 --> 00:06:50.079
<v Speaker 1>Leak publicly accessible files they forgot about or didn't secure

133
00:06:50.120 --> 00:06:51.000
<v Speaker 1>properly exactly.

134
00:06:51.040 --> 00:06:54.839
<v Speaker 2>They use specific targeted search engine terms like site dot dox,

135
00:06:54.879 --> 00:06:57.480
<v Speaker 2>c stack, Google dot com, gretch, Politico to uncover these

136
00:06:57.480 --> 00:06:59.120
<v Speaker 2>digital breadcrumbs.

137
00:06:58.560 --> 00:07:01.720
<v Speaker 1>And beyond public document where else can they unearth valuable

138
00:07:01.759 --> 00:07:04.240
<v Speaker 1>clues about their target? Seems like documents are just one piece,

139
00:07:04.480 --> 00:07:05.120
<v Speaker 1>oh for sure.

140
00:07:05.319 --> 00:07:08.920
<v Speaker 2>GitHub is an absolute gold mine, a potential gold mine anyway.

141
00:07:09.279 --> 00:07:11.759
<v Speaker 2>While basic searches have their limits, The real trick the

142
00:07:11.759 --> 00:07:15.560
<v Speaker 2>book suggests is to download entire public repositories related to

143
00:07:15.600 --> 00:07:19.240
<v Speaker 2>the target and then unleash the full wrath of good

144
00:07:19.240 --> 00:07:20.720
<v Speaker 2>old rep on them.

145
00:07:20.839 --> 00:07:24.439
<v Speaker 1>Rep The command line search tool YEP a powerful.

146
00:07:24.040 --> 00:07:26.720
<v Speaker 2>Tool that can quickly search through massive amounts of text

147
00:07:26.720 --> 00:07:30.959
<v Speaker 2>for specific patterns. They'd be looking for sensitive strings like ossicritic,

148
00:07:31.040 --> 00:07:34.279
<v Speaker 2>sess kei, or maybe begin private key, things that should

149
00:07:34.319 --> 00:07:34.759
<v Speaker 2>never be.

150
00:07:34.759 --> 00:07:36.920
<v Speaker 1>In public code credentials just sitting there.

151
00:07:37.240 --> 00:07:40.399
<v Speaker 2>It happens more often than you'd think. They also script

152
00:07:40.439 --> 00:07:43.600
<v Speaker 2>code snippets from public code sharing sites like just dot

153
00:07:43.680 --> 00:07:47.800
<v Speaker 2>GitHub dot com and pastebin dot com. Sometimes developers paste

154
00:07:47.800 --> 00:07:50.959
<v Speaker 2>things there for quick sharing or debugging and accidentally expose

155
00:07:51.079 --> 00:07:53.879
<v Speaker 2>log file extracts or even database extracts hops.

156
00:07:54.199 --> 00:07:56.800
<v Speaker 1>Wow. Okay, so after all this digital slew thing, this

157
00:07:56.920 --> 00:08:00.879
<v Speaker 1>healthy stocking, what did the reconnaissance reveal about Gretch, Politico

158
00:08:01.000 --> 00:08:02.079
<v Speaker 1>and mxr ADS.

159
00:08:02.319 --> 00:08:05.079
<v Speaker 2>Well, the initial SUITEP showed their core service is building

160
00:08:05.120 --> 00:08:09.240
<v Speaker 2>these detailed voter profiles and that they have this incredibly

161
00:08:09.319 --> 00:08:12.959
<v Speaker 2>intertwined relationship with mxr ADS for the advertising side, very

162
00:08:12.959 --> 00:08:13.959
<v Speaker 2>close partners.

163
00:08:13.639 --> 00:08:16.480
<v Speaker 1>Which could be good for business but bad for security exactly.

164
00:08:17.240 --> 00:08:21.199
<v Speaker 2>The book notes this intertwined connection, while profitable, could prove

165
00:08:21.240 --> 00:08:24.720
<v Speaker 2>fatal to both companies if one gets compromised. They also

166
00:08:24.759 --> 00:08:29.759
<v Speaker 2>identified numerous subdomains like Dashboard dot Gretchpolitico dot com using

167
00:08:29.800 --> 00:08:33.399
<v Speaker 2>specialized tools like sublister R and fern Melder, and then

168
00:08:33.399 --> 00:08:36.480
<v Speaker 2>they performed ENDMP scans on those domains to see what

169
00:08:36.559 --> 00:08:39.080
<v Speaker 2>ports were open, what services were running.

170
00:08:38.799 --> 00:08:40.399
<v Speaker 1>Building a map of their online presence.

171
00:08:40.600 --> 00:08:44.840
<v Speaker 2>Right. This whole process ultimately provided over one hundred domains

172
00:08:44.879 --> 00:08:48.279
<v Speaker 2>belonging to both organizations, which, as the book says, offers

173
00:08:48.320 --> 00:08:50.960
<v Speaker 2>a significant luxury of choice for finding a way in

174
00:08:51.440 --> 00:08:52.399
<v Speaker 2>lots of doors.

175
00:08:52.159 --> 00:08:58.200
<v Speaker 1>To check one hundred domains with literally dozens maybe hundreds identified.

176
00:08:58.399 --> 00:09:00.840
<v Speaker 1>How do you even begin to find the ulnerabilities? It

177
00:09:00.879 --> 00:09:03.039
<v Speaker 1>sounds like trying to find a needle in a haystack

178
00:09:03.080 --> 00:09:04.879
<v Speaker 1>the size of a continent. Overwhelming.

179
00:09:05.200 --> 00:09:06.639
<v Speaker 3>It absolutely can feel that way.

180
00:09:06.759 --> 00:09:09.720
<v Speaker 2>Yeah, but the book emphasizes, you know, the more you practice,

181
00:09:09.720 --> 00:09:12.759
<v Speaker 2>the better you will get. Experience counts, and in a

182
00:09:12.799 --> 00:09:16.759
<v Speaker 2>full cloud environment, there are shortcuts. A crucial one is

183
00:09:16.799 --> 00:09:20.879
<v Speaker 2>to reveal the real domains behind public facing domains.

184
00:09:21.120 --> 00:09:21.759
<v Speaker 1>How do you do that?

185
00:09:22.039 --> 00:09:25.960
<v Speaker 2>By looking for cnam entries in DNS records instead of

186
00:09:26.000 --> 00:09:29.159
<v Speaker 2>just the raw IP addresses. A CNME is basically like

187
00:09:29.200 --> 00:09:31.840
<v Speaker 2>a nickname for a server. It lets multiple web adjustes

188
00:09:31.879 --> 00:09:33.720
<v Speaker 2>point to the same underlying resource.

189
00:09:34.039 --> 00:09:36.679
<v Speaker 1>Oh okay, so it reveals the actual service provider.

190
00:09:36.440 --> 00:09:37.480
<v Speaker 3>Sometimes exactly.

191
00:09:37.919 --> 00:09:41.120
<v Speaker 2>This simple step revealed that many msr ADS domains were

192
00:09:41.159 --> 00:09:45.039
<v Speaker 2>actually hosted on AWS using common services like CloudFront for

193
00:09:45.080 --> 00:09:49.080
<v Speaker 2>content delivery, S three for storage, and ELB for load balancing.

194
00:09:49.360 --> 00:09:54.879
<v Speaker 2>Standard stuff, but crucially gretch Politico's own dashboard URL dashboard

195
00:09:54.919 --> 00:09:58.279
<v Speaker 2>dot gretsch politico dot com even pointed to an mxr

196
00:09:58.360 --> 00:09:59.399
<v Speaker 2>ADS domain.

197
00:09:59.200 --> 00:10:01.159
<v Speaker 1>Directly confirmed how tightly length they are.

198
00:10:01.240 --> 00:10:03.919
<v Speaker 2>Yeah, strong confirmation of those deep operational ties.

199
00:10:04.080 --> 00:10:06.480
<v Speaker 1>And what was the big aha moment in this phase,

200
00:10:06.480 --> 00:10:09.399
<v Speaker 1>the critical breakthrough that opened the first real door.

201
00:10:09.440 --> 00:10:13.240
<v Speaker 2>The discovery of vulnerable S three buckets. S three aws'

202
00:10:13.279 --> 00:10:15.600
<v Speaker 2>is simple storage service basically.

203
00:10:15.279 --> 00:10:17.679
<v Speaker 1>Cloud file story right use for everything.

204
00:10:17.399 --> 00:10:20.279
<v Speaker 2>Pretty much now default S three security has tightened up

205
00:10:20.320 --> 00:10:23.039
<v Speaker 2>over time, thankfully, but the book explains that the four

206
00:10:23.159 --> 00:10:28.559
<v Speaker 2>overlapping settings, things like access control lists ACLS, core S configurations,

207
00:10:28.639 --> 00:10:32.399
<v Speaker 2>bucket policies, and IAM policies. It all makes S three

208
00:10:32.440 --> 00:10:33.799
<v Speaker 2>security very.

209
00:10:33.720 --> 00:10:35.799
<v Speaker 1>Convoluted, easy to mess up, them.

210
00:10:35.799 --> 00:10:39.159
<v Speaker 2>Very easy to misconfigure, and for one domain misc dot

211
00:10:39.279 --> 00:10:43.159
<v Speaker 2>mxrads dot com, while directory listing was denied, you couldn't

212
00:10:43.200 --> 00:10:46.639
<v Speaker 2>just browse it using the awscli, the command line tool

213
00:10:46.840 --> 00:10:50.480
<v Speaker 2>to run list objects h V two. While that surprisingly

214
00:10:50.519 --> 00:10:54.440
<v Speaker 2>revealed over four hundred thousand files stored in the single.

215
00:10:54.159 --> 00:10:57.120
<v Speaker 1>Bucket, whoa just sitting there accessible.

216
00:10:56.639 --> 00:10:59.120
<v Speaker 2>Accessible if you knew the command to list them, including

217
00:10:59.120 --> 00:11:01.200
<v Speaker 2>an empty index dot m HTML at the root, which

218
00:11:01.240 --> 00:11:02.799
<v Speaker 2>is often assigned. Something's not quite right.

219
00:11:02.919 --> 00:11:05.600
<v Speaker 1>Okay, four hundred thousand files is a lot, but maybe not.

220
00:11:05.679 --> 00:11:08.159
<v Speaker 1>The keys to the kingdom was that the biggest find.

221
00:11:07.840 --> 00:11:11.879
<v Speaker 2>No, not the biggest breakthrough, but certainly highlighted poor configuration hygiene.

222
00:11:11.919 --> 00:11:12.679
<v Speaker 3>A warning sign.

223
00:11:13.519 --> 00:11:16.799
<v Speaker 2>The truly critical vulnerability, the one that really crack things open,

224
00:11:17.039 --> 00:11:20.840
<v Speaker 2>was a server side request forgery or SSRF, found on

225
00:11:21.120 --> 00:11:23.440
<v Speaker 2>demo dot mxrads dot com.

226
00:11:23.639 --> 00:11:26.919
<v Speaker 1>SSRF. Okay, remind me again what that lets an attacker do, right.

227
00:11:27.279 --> 00:11:30.320
<v Speaker 2>SSRF is like tricking a server one that's sitting inside

228
00:11:30.320 --> 00:11:33.559
<v Speaker 2>a supposedly secure network to make a request on your behalf.

229
00:11:33.879 --> 00:11:36.399
<v Speaker 2>It makes requests to other internal systems that the server

230
00:11:36.480 --> 00:11:38.360
<v Speaker 2>can reach, but you from the outside can't.

231
00:11:38.440 --> 00:11:40.960
<v Speaker 1>Okay, So you're using the server as a proxy to

232
00:11:41.080 --> 00:11:42.240
<v Speaker 1>hit internal stuff.

233
00:11:42.360 --> 00:11:43.000
<v Speaker 3>Essentially, Yes.

234
00:11:43.360 --> 00:11:46.399
<v Speaker 2>By manipulating a URL and the demo application using a

235
00:11:46.399 --> 00:11:49.159
<v Speaker 2>tool like burke Suite, a standard web app testing toolkit,

236
00:11:49.480 --> 00:11:52.440
<v Speaker 2>the attacker could force the application to make internal requests

237
00:11:52.799 --> 00:11:55.600
<v Speaker 2>specifically to the AWS metadata API.

238
00:11:55.879 --> 00:11:59.440
<v Speaker 1>Ah, that's special address HTTP dot one six nine point

239
00:11:59.440 --> 00:12:01.559
<v Speaker 1>two five four point one six nine point two five

240
00:12:01.600 --> 00:12:04.279
<v Speaker 1>four littles, that's the one. Here's where it gets really interesting.

241
00:12:04.279 --> 00:12:06.240
<v Speaker 1>As you said, this isn't a normal web address. What

242
00:12:06.320 --> 00:12:09.840
<v Speaker 1>kind of information does this mysterious metadata API actually reveal?

243
00:12:10.120 --> 00:12:13.600
<v Speaker 2>Yeah, it's a special internal address unique to cloud environments

244
00:12:13.639 --> 00:12:18.240
<v Speaker 2>like AWS instances. Those virtual computers can query it to

245
00:12:18.320 --> 00:12:21.000
<v Speaker 2>get information about themselves. Like asking who am I, what.

246
00:12:21.000 --> 00:12:24.159
<v Speaker 3>Can I do? It reveals a whole trove.

247
00:12:23.919 --> 00:12:27.679
<v Speaker 2>Of metadata, the machine's host name, its internal IP address,

248
00:12:27.879 --> 00:12:30.679
<v Speaker 2>firewall rules, basic identity cards.

249
00:12:30.679 --> 00:12:33.279
<v Speaker 1>Stuff. Okay, useful but maybe not devastating.

250
00:12:33.360 --> 00:12:36.159
<v Speaker 2>Ah. But the dirty secret, as the book puts it,

251
00:12:36.240 --> 00:12:38.080
<v Speaker 2>is that it can also expose the user.

252
00:12:37.919 --> 00:12:40.759
<v Speaker 1>Data script, the script that runs when the machine first boots.

253
00:12:40.559 --> 00:12:44.639
<v Speaker 2>Up exactly, often used for setup configuration, and sometimes developers

254
00:12:44.639 --> 00:12:47.799
<v Speaker 2>put sensitive stuff in there. For mxri ads demo server,

255
00:12:48.159 --> 00:12:51.799
<v Speaker 2>this user data script contained crucial environment variables, including a

256
00:12:51.840 --> 00:12:54.759
<v Speaker 2>reference to a secrets dot em V file and guess

257
00:12:54.759 --> 00:12:55.279
<v Speaker 2>what was in.

258
00:12:55.159 --> 00:12:57.440
<v Speaker 1>There, daz passwords jackpot.

259
00:12:57.679 --> 00:13:00.080
<v Speaker 2>The script or the file it pointed to yielded many

260
00:13:00.080 --> 00:13:04.759
<v Speaker 2>passwords to access Cassandra clusters, Cassandra being a popular Noseql database.

261
00:13:04.840 --> 00:13:07.639
<v Speaker 1>Yeah, okay, direct database access and it gets better.

262
00:13:07.759 --> 00:13:11.240
<v Speaker 2>It also revealed IAM role credentials for the machine.

263
00:13:10.960 --> 00:13:14.240
<v Speaker 1>Itself, imm identity and access management. The permissions in the

264
00:13:14.320 --> 00:13:16.519
<v Speaker 1>machine has within AWS.

265
00:13:16.120 --> 00:13:19.080
<v Speaker 2>Correct and these role credentials are often not subject to

266
00:13:19.120 --> 00:13:23.399
<v Speaker 2>the same IP restrictions as regular user credentials. They're incredibly

267
00:13:23.480 --> 00:13:26.399
<v Speaker 2>valuable because they can potentially be used from anywhere, So.

268
00:13:26.840 --> 00:13:31.240
<v Speaker 1>A seemingly simple SSRF vulnerability maybe in a forgotten demo

269
00:13:31.320 --> 00:13:35.480
<v Speaker 1>app could spiral into gaining highly privileged credentials for other

270
00:13:35.519 --> 00:13:38.039
<v Speaker 1>AWS services. That's quite a leap.

271
00:13:38.279 --> 00:13:41.279
<v Speaker 2>Absolutely, It's a classic cloud escalation path. Even though the

272
00:13:41.320 --> 00:13:44.360
<v Speaker 2>attacker was initially denied direct access to list all S

273
00:13:44.399 --> 00:13:47.960
<v Speaker 2>three buckets using these credentials, the im role itself, the

274
00:13:47.960 --> 00:13:51.519
<v Speaker 2>specific permissions assigned to that demo application was successfully used

275
00:13:51.519 --> 00:13:55.000
<v Speaker 2>to list objects V two within a different important looking

276
00:13:55.039 --> 00:13:59.080
<v Speaker 2>bucket mex rads DL, and that revealed hundreds of thousands

277
00:13:59.080 --> 00:14:03.320
<v Speaker 2>of JR files and other binaries, probably application code libraries.

278
00:14:03.399 --> 00:14:05.600
<v Speaker 1>It's like finding a key that doesn't open the front door,

279
00:14:05.799 --> 00:14:07.960
<v Speaker 1>but opens a side door to the engineering lab.

280
00:14:08.039 --> 00:14:10.960
<v Speaker 2>That's a good analogy. Yes, once you're inside, even limited

281
00:14:10.960 --> 00:14:13.519
<v Speaker 2>permissions can often be leveraged to find more access.

282
00:14:13.639 --> 00:14:16.679
<v Speaker 1>Okay. The book then describes another major vulnerability found on

283
00:14:16.720 --> 00:14:21.000
<v Speaker 1>a different site Www. Dot surveysandstats dot com. What was

284
00:14:21.039 --> 00:14:21.440
<v Speaker 1>that one?

285
00:14:21.600 --> 00:14:25.360
<v Speaker 2>That was a server side template injection or SSTI vulnerability.

286
00:14:25.600 --> 00:14:28.720
<v Speaker 1>SSTI sounds similar to SSRF, but different.

287
00:14:28.759 --> 00:14:32.039
<v Speaker 2>Similar in that you're tricking the server, but the mechanism

288
00:14:32.120 --> 00:14:35.200
<v Speaker 2>is different. Instead of making external requests, you're tricking the

289
00:14:35.200 --> 00:14:39.159
<v Speaker 2>server into executing code you provide within its own templating engine.

290
00:14:39.200 --> 00:14:41.679
<v Speaker 1>Templeting engine like for generating web.

291
00:14:41.480 --> 00:14:45.240
<v Speaker 2>Pages exactly things like jinga two in Python or handlebars

292
00:14:45.279 --> 00:14:48.600
<v Speaker 2>and JavaScript. They take data and put it into a template.

293
00:14:48.919 --> 00:14:51.879
<v Speaker 2>By injecting a simple string like into a form field

294
00:14:51.879 --> 00:14:54.320
<v Speaker 2>on the website and seeing the server respond with sixteen

295
00:14:54.440 --> 00:14:56.440
<v Speaker 2>instead of the original string means.

296
00:14:56.240 --> 00:14:59.519
<v Speaker 1>The server actually calculated eight times too it ran code.

297
00:14:59.240 --> 00:15:03.679
<v Speaker 2>Bingo confirmed the vulnerability. This then allowed the attacker to

298
00:15:03.759 --> 00:15:06.840
<v Speaker 2>use advanced features of the programming language Python, in this

299
00:15:06.919 --> 00:15:11.159
<v Speaker 2>case things like introspection and reflection, essentially letting the code

300
00:15:11.159 --> 00:15:15.519
<v Speaker 2>examine and modify itself to eventually call subprocess.

301
00:15:15.039 --> 00:15:16.919
<v Speaker 1>Popin, which basically means.

302
00:15:16.879 --> 00:15:20.639
<v Speaker 2>Arbitrary code execution on the server. Full control, They could

303
00:15:20.639 --> 00:15:22.639
<v Speaker 2>make the server run almost any command they wanted.

304
00:15:22.879 --> 00:15:25.480
<v Speaker 1>Game over for that server then, and what was the

305
00:15:25.519 --> 00:15:29.639
<v Speaker 1>immediate juicy payoff from gaining that arbitrary code execution.

306
00:15:29.480 --> 00:15:34.360
<v Speaker 2>Well, they immediately gained SEES simple Email Service credentials, aws's

307
00:15:34.399 --> 00:15:36.159
<v Speaker 2>email service, useful.

308
00:15:35.960 --> 00:15:38.879
<v Speaker 1>For sending spam maybe or something more.

309
00:15:38.759 --> 00:15:42.679
<v Speaker 2>More importantly, it confirmed that survey sandstats dot com belonged

310
00:15:42.679 --> 00:15:46.519
<v Speaker 2>to the same AWS account as mxr ads, tying the

311
00:15:46.559 --> 00:15:50.600
<v Speaker 2>infrastructure together. Further, and even more critically, they found that

312
00:15:50.720 --> 00:15:54.360
<v Speaker 2>while external Internet access was blocked on this particular server

313
00:15:54.879 --> 00:15:56.639
<v Speaker 2>at common security measures, so they.

314
00:15:56.519 --> 00:15:58.919
<v Speaker 1>Couldn't just download tools or send data out easily.

315
00:15:59.039 --> 00:16:01.519
<v Speaker 2>Right, But they discovered they could smuggle in a request

316
00:16:01.600 --> 00:16:05.039
<v Speaker 2>to a bucket in our own AWS account by exploiting

317
00:16:05.080 --> 00:16:08.919
<v Speaker 2>something for an S three VPC N point configuration. It's

318
00:16:08.960 --> 00:16:11.080
<v Speaker 2>a way for internal servers to talk to S three

319
00:16:11.320 --> 00:16:13.720
<v Speaker 2>without going over the public Internet clever, so.

320
00:16:13.679 --> 00:16:16.600
<v Speaker 1>They could use S three as a communication channel exactly.

321
00:16:17.000 --> 00:16:19.879
<v Speaker 3>This was huge. It led to a reliable way to

322
00:16:19.919 --> 00:16:20.600
<v Speaker 3>communicate with.

323
00:16:20.559 --> 00:16:23.559
<v Speaker 2>The outside world from this otherwise sealed off survey app,

324
00:16:24.080 --> 00:16:27.960
<v Speaker 2>and it enabled command execution through S three files. They'd

325
00:16:28.000 --> 00:16:30.399
<v Speaker 2>upload a command file to their own bucket, the server

326
00:16:30.480 --> 00:16:32.759
<v Speaker 2>would fetch and run it via the endpoint and send

327
00:16:32.759 --> 00:16:34.000
<v Speaker 2>results back the same.

328
00:16:33.799 --> 00:16:37.320
<v Speaker 1>Way, essentially creating an S three base back door. Wow,

329
00:16:37.639 --> 00:16:39.799
<v Speaker 1>it's like finding a secret pneumatic tube system out of

330
00:16:39.840 --> 00:16:40.440
<v Speaker 1>a locked room.

331
00:16:40.639 --> 00:16:43.480
<v Speaker 2>Hey, yeah, something like that. A very effective stealthy channel.

332
00:16:43.559 --> 00:16:47.519
<v Speaker 1>Okay, So with initial access established via SSRF and SSTI

333
00:16:47.799 --> 00:16:50.679
<v Speaker 1>leading to code execution and a back door, the hacker

334
00:16:50.720 --> 00:16:53.879
<v Speaker 1>discovers there inside a container, but not just any container

335
00:16:53.960 --> 00:16:57.519
<v Speaker 1>one managed by a Kubernetes cluster. For those less familiar,

336
00:16:57.720 --> 00:17:00.960
<v Speaker 1>what does Kubernetes fundamentally change about the hacking target compared

337
00:17:00.960 --> 00:17:04.039
<v Speaker 1>to just compromising a single traditional server. Right.

338
00:17:04.240 --> 00:17:07.559
<v Speaker 2>Kubernetes, or cube as it's often called, is described in

339
00:17:07.599 --> 00:17:11.319
<v Speaker 2>the book as the ultimate container orchestrator. It's a game changer.

340
00:17:11.759 --> 00:17:16.880
<v Speaker 2>Imagine hundreds, maybe thousands of software containers which are like lightweight,

341
00:17:17.039 --> 00:17:22.519
<v Speaker 2>isolated virtual machines, all running different parts of applications. Kubernetes

342
00:17:22.559 --> 00:17:25.359
<v Speaker 2>manages all of them. It starts them, stops them, connects them,

343
00:17:25.519 --> 00:17:28.279
<v Speaker 2>scales them up or down automatically based on demand.

344
00:17:28.400 --> 00:17:30.960
<v Speaker 1>So it's like the conductor of a huge orchestra of software.

345
00:17:31.000 --> 00:17:32.000
<v Speaker 3>That's a great way to put it.

346
00:17:32.400 --> 00:17:36.160
<v Speaker 2>The book explains its core components pods, which are groups

347
00:17:36.200 --> 00:17:38.960
<v Speaker 2>of one or more containers that run together, services which

348
00:17:38.960 --> 00:17:43.160
<v Speaker 2>handle internal load balancing and networking between pods, and crucially,

349
00:17:43.400 --> 00:17:47.039
<v Speaker 2>the API server and the etcetera database. These maintain the

350
00:17:47.079 --> 00:17:50.839
<v Speaker 2>cluster's desired state. Kubernetes is always trying to make reality

351
00:17:51.000 --> 00:17:54.160
<v Speaker 2>match that desired state, so attacking it isn't like attacking

352
00:17:54.200 --> 00:17:59.119
<v Speaker 2>one server. It's about understanding and manipulating this complex dynamic system.

353
00:17:59.200 --> 00:18:02.279
<v Speaker 1>Okay, so find yourself inside one of these containers, maybe

354
00:18:02.279 --> 00:18:05.039
<v Speaker 1>through web vulnerability like we just discussed, how do you

355
00:18:05.160 --> 00:18:08.119
<v Speaker 1>break out or gain more control over the entire Kubernetes

356
00:18:08.200 --> 00:18:11.200
<v Speaker 1>cluster itself. That sounds like a monumental leap.

357
00:18:11.240 --> 00:18:14.039
<v Speaker 2>It is, but often, like with S three, it comes

358
00:18:14.039 --> 00:18:18.720
<v Speaker 2>down to misconfigurations. Small oversights can have big impacts and cube.

359
00:18:19.599 --> 00:18:22.240
<v Speaker 2>The first key discovering the book scenario was that the

360
00:18:22.319 --> 00:18:26.079
<v Speaker 2>compromised container was running with a default service account.

361
00:18:26.119 --> 00:18:29.039
<v Speaker 1>A service account being like an identity for the software.

362
00:18:28.640 --> 00:18:33.039
<v Speaker 2>Itself exactly, and Kubernetes gives containers a token, a JWT

363
00:18:33.319 --> 00:18:37.079
<v Speaker 2>JSON webtoken like a digital passport associated with the service account.

364
00:18:37.440 --> 00:18:41.000
<v Speaker 2>It's usually mounted automatically inside the container at a specific

365
00:18:41.039 --> 00:18:46.240
<v Speaker 2>filepath run secret Scubernetes dot Io service account token. By

366
00:18:46.240 --> 00:18:49.680
<v Speaker 2>grabbing this token, the attacker could directly query the Kubernetes

367
00:18:49.720 --> 00:18:52.000
<v Speaker 2>API server pretending to be that container.

368
00:18:52.079 --> 00:18:54.559
<v Speaker 1>Okay, but what can a default account usually do? Isn't

369
00:18:54.559 --> 00:18:55.200
<v Speaker 1>it lockdown?

370
00:18:55.480 --> 00:18:58.359
<v Speaker 2>It should be, But here's the critical part. The book

371
00:18:58.400 --> 00:19:01.680
<v Speaker 2>notes that if this default account was unwittingly granted extra

372
00:19:01.720 --> 00:19:05.880
<v Speaker 2>privileges by an administrator, maybe for some forgotten reason, then

373
00:19:06.240 --> 00:19:08.400
<v Speaker 2>all the other pods running with the same identity will

374
00:19:08.440 --> 00:19:12.279
<v Speaker 2>automatically inherit these same privileges. Suddenly, that default account isn't

375
00:19:12.319 --> 00:19:13.240
<v Speaker 2>so basic anymore.

376
00:19:13.440 --> 00:19:17.759
<v Speaker 1>Uh, A shared identity with escalated permissions precisely, and in

377
00:19:17.799 --> 00:19:20.440
<v Speaker 1>this case, it allowed the attacker to list hundreds of

378
00:19:20.559 --> 00:19:23.960
<v Speaker 1>pods specifically in the prod name space, usually the live

379
00:19:24.000 --> 00:19:24.839
<v Speaker 1>production environment.

380
00:19:25.200 --> 00:19:29.559
<v Speaker 2>And even more, they could extract their full Yamel manifests.

381
00:19:29.319 --> 00:19:31.640
<v Speaker 1>The configuration files for those pods.

382
00:19:31.440 --> 00:19:36.119
<v Speaker 2>Yes, revealing things like environment variables, container images used, and

383
00:19:36.200 --> 00:19:39.799
<v Speaker 2>even secret key ref pointers. These are references that tell

384
00:19:39.839 --> 00:19:43.240
<v Speaker 2>Kubernetes where to find other secrets like database passwords or

385
00:19:43.279 --> 00:19:45.640
<v Speaker 2>API keys and inject them into the pod.

386
00:19:45.839 --> 00:19:49.039
<v Speaker 1>So looking at the POD's configuration reveals pointers to the

387
00:19:49.079 --> 00:19:50.480
<v Speaker 1>actual secrets if.

388
00:19:50.279 --> 00:19:51.039
<v Speaker 3>Configured that way.

389
00:19:51.119 --> 00:19:54.000
<v Speaker 2>Yes, it's like finding a treasure map inside the container.

390
00:19:54.359 --> 00:19:57.119
<v Speaker 1>This sounds like a massive win an insider's view of

391
00:19:57.119 --> 00:20:01.480
<v Speaker 1>the entire production environment, potentially exposing very sensitive data. What

392
00:20:01.640 --> 00:20:05.240
<v Speaker 1>kind of stuff was actually exposed through this elevated Kubernetes access.

393
00:20:05.319 --> 00:20:09.720
<v Speaker 2>They literally discovered containers configured to load AWS credentials directly

394
00:20:09.759 --> 00:20:14.319
<v Speaker 2>as secrets, very sensitive stuff by abusing those Kubernetes service

395
00:20:14.319 --> 00:20:17.880
<v Speaker 2>account privileges. Using the token they found, they could ask

396
00:20:17.920 --> 00:20:21.640
<v Speaker 2>the Cube API to retrieve secrets like dbcore password directly

397
00:20:21.640 --> 00:20:23.000
<v Speaker 2>from the cluster's secret store.

398
00:20:23.319 --> 00:20:25.920
<v Speaker 1>Wow, just ask Cube for the password.

399
00:20:25.559 --> 00:20:28.480
<v Speaker 2>If the service account had permission, Yes, and this led

400
00:20:28.519 --> 00:20:33.000
<v Speaker 2>directly to campaign database credentials for a mysucle database. This

401
00:20:33.079 --> 00:20:36.400
<v Speaker 2>allowed them to infiltrate gretch Politico's core campaign database and

402
00:20:36.440 --> 00:20:41.319
<v Speaker 2>pull pretty much everything detailed customer data, campaign budgets, conternal notes,

403
00:20:41.559 --> 00:20:44.920
<v Speaker 2>and even links to the creatives. The actual campaign materials

404
00:20:44.960 --> 00:20:47.519
<v Speaker 2>like videos and images which were hosted.

405
00:20:47.160 --> 00:20:50.039
<v Speaker 1>On S three And could they access those S three

406
00:20:50.079 --> 00:20:50.640
<v Speaker 1>files too?

407
00:20:50.960 --> 00:20:54.839
<v Speaker 2>Yes, because the Kubernetes secrets also likely contained AWS keys,

408
00:20:55.279 --> 00:20:58.960
<v Speaker 2>or maybe the service account itself had im permissions. They

409
00:20:59.079 --> 00:21:02.039
<v Speaker 2>leveraged their new found I AM access to download these

410
00:21:02.119 --> 00:21:05.559
<v Speaker 2>videos directly from S three, which, as the book points out,

411
00:21:05.680 --> 00:21:08.920
<v Speaker 2>underscores a key cloud principle. A cloud provider does not

412
00:21:08.960 --> 00:21:10.480
<v Speaker 2>care where you are. As long as you have the

413
00:21:10.519 --> 00:21:12.720
<v Speaker 2>right credentials, you can download whatever you want.

414
00:21:12.920 --> 00:21:17.680
<v Speaker 1>Location is irrelevant. Only credentials matter. Chilling very much So Okay,

415
00:21:17.880 --> 00:21:21.440
<v Speaker 1>beyond databases and file storage, what other powerful tools did

416
00:21:21.440 --> 00:21:25.160
<v Speaker 1>the hacker's target to achieve even deeper more systemic access

417
00:21:25.160 --> 00:21:27.000
<v Speaker 1>within the organization's infrastructure.

418
00:21:27.200 --> 00:21:31.880
<v Speaker 2>They pivoted to the infrastructure management tools, things like Jenkins.

419
00:21:31.279 --> 00:21:35.960
<v Speaker 1>And chef AH, the CICD pipeline tools, continuous integration, continuous

420
00:21:36.000 --> 00:21:37.359
<v Speaker 1>delivery exactly.

421
00:21:37.519 --> 00:21:41.519
<v Speaker 2>These are absolutely central to modern development and deployment processes.

422
00:21:42.000 --> 00:21:46.359
<v Speaker 2>Jenkins in particular is often described, maybe slightly dramatically, as

423
00:21:46.440 --> 00:21:49.119
<v Speaker 2>the almighty god of any infrastructure.

424
00:21:49.240 --> 00:21:50.960
<v Speaker 1>Why so powerful because.

425
00:21:50.640 --> 00:21:54.519
<v Speaker 2>It often has permissions to do everything. It can compile code,

426
00:21:54.720 --> 00:21:59.119
<v Speaker 2>run automated tests, deploy applications straight to production. It can

427
00:21:59.200 --> 00:22:02.480
<v Speaker 2>even create new U Kubernetes resources, or spin up entirely

428
00:22:02.559 --> 00:22:06.519
<v Speaker 2>new AWS machines. It's the engine driving the whole development

429
00:22:06.559 --> 00:22:10.480
<v Speaker 2>life cycle. So if you compromise Jenkins, you potentially own everything.

430
00:22:11.039 --> 00:22:14.440
<v Speaker 2>By identifying these Jenkins instances, the next logical step for

431
00:22:14.480 --> 00:22:17.960
<v Speaker 2>the attacker was clear, pay in an infrastructure management tool,

432
00:22:18.200 --> 00:22:19.680
<v Speaker 2>take control of the God machine.

433
00:22:19.759 --> 00:22:22.359
<v Speaker 1>Right. How did they manage to gain access to these

434
00:22:22.359 --> 00:22:25.880
<v Speaker 1>incredibly powerful automation tools. That sounds like it should be

435
00:22:25.920 --> 00:22:26.480
<v Speaker 1>locked down.

436
00:22:26.359 --> 00:22:28.960
<v Speaker 2>Tight It should be, But they got creative. They leveraged

437
00:22:29.000 --> 00:22:32.119
<v Speaker 2>their existing GitHub token, the one they'd previously obtained via

438
00:22:32.119 --> 00:22:33.440
<v Speaker 2>that Kubernetes secret.

439
00:22:33.440 --> 00:22:35.680
<v Speaker 1>Ah reusing credentials found earlier.

440
00:22:35.880 --> 00:22:39.799
<v Speaker 2>Exactly, they used it to list mxr AD's private repositories

441
00:22:39.799 --> 00:22:42.880
<v Speaker 2>on GitHub this time, and there they found a repo

442
00:22:43.000 --> 00:22:45.279
<v Speaker 2>named cookbook mextrads jenkins.

443
00:22:44.880 --> 00:22:48.839
<v Speaker 1>G cookbook often means CHEF right, the configuration.

444
00:22:48.319 --> 00:22:52.319
<v Speaker 2>Management tool that's the strong hint. Yes, CHEF uses recipes

445
00:22:52.319 --> 00:22:56.000
<v Speaker 2>collected in cookbooks to configure servers. They then discovered that

446
00:22:56.039 --> 00:23:01.519
<v Speaker 2>certain AWSAPI calls specifically describe instances which are often overlooked

447
00:23:01.519 --> 00:23:05.880
<v Speaker 2>by security teams because they seem informational, could sometimes expose

448
00:23:05.960 --> 00:23:09.480
<v Speaker 2>the user data scripts on running EC two instances. Remember

449
00:23:09.519 --> 00:23:10.240
<v Speaker 2>those boot up.

450
00:23:10.119 --> 00:23:12.599
<v Speaker 1>Scripts, the ones that sometimes contained secrets yep.

451
00:23:12.440 --> 00:23:15.279
<v Speaker 2>And these scripts, maybe used for initial bootstrapping of a

452
00:23:15.319 --> 00:23:18.480
<v Speaker 2>CHEF managed server, could sometimes contain CHEF private keys.

453
00:23:18.720 --> 00:23:21.119
<v Speaker 1>Oh wow, so the key needed to authenticate to the

454
00:23:21.200 --> 00:23:23.759
<v Speaker 1>CHEF server was just sitting in the user data of

455
00:23:23.799 --> 00:23:24.480
<v Speaker 1>a running.

456
00:23:24.240 --> 00:23:28.720
<v Speaker 2>Instance in this scenario, Yes, a major oversight. This allowed

457
00:23:28.720 --> 00:23:31.680
<v Speaker 2>the attacker to register a new malicious machine with the

458
00:23:31.759 --> 00:23:35.519
<v Speaker 2>CHEF server, pretending to be a legitimate node. Then, using

459
00:23:35.519 --> 00:23:38.759
<v Speaker 2>the Knife tool Chef's command line interface, they could list

460
00:23:38.880 --> 00:23:42.200
<v Speaker 2>all the CHEF cookbooks the server managed, including that crucial

461
00:23:42.279 --> 00:23:45.480
<v Speaker 2>Jenkins CI one they saw on GitHub. They could now

462
00:23:45.519 --> 00:23:49.799
<v Speaker 2>see exactly how Jenkins was configured and potentially find vulnerabilities

463
00:23:49.880 --> 00:23:52.759
<v Speaker 2>or hard coded secrets within the chef recipes themselves.

464
00:23:53.039 --> 00:23:56.279
<v Speaker 1>Incredible. It's like a chain reaction of compromises, each step

465
00:23:56.359 --> 00:23:59.960
<v Speaker 1>enabling the next. What about serveralist functions like abus LAMB

466
00:24:00.079 --> 00:24:01.880
<v Speaker 1>Are they vulnerable in similar ways?

467
00:24:01.960 --> 00:24:02.319
<v Speaker 3>They are?

468
00:24:02.640 --> 00:24:06.480
<v Speaker 2>Lambda functions, as the book describes them, are essentially glorified crontabs,

469
00:24:07.000 --> 00:24:10.079
<v Speaker 2>small pieces of code that run on demand, triggered by events,

470
00:24:10.160 --> 00:24:12.000
<v Speaker 2>without you needing to manage a full server.

471
00:24:12.640 --> 00:24:15.559
<v Speaker 1>Very popular, and presumably they also need permissions to do

472
00:24:15.640 --> 00:24:16.640
<v Speaker 1>things they do.

473
00:24:16.880 --> 00:24:19.079
<v Speaker 2>They run with an assigned I and M role, just

474
00:24:19.119 --> 00:24:22.559
<v Speaker 2>like EC two instances. The attackers found a function called

475
00:24:22.640 --> 00:24:26.519
<v Speaker 2>lambda di pasinc. Its job was to process mxr AD's

476
00:24:26.599 --> 00:24:29.200
<v Speaker 2>logs and send them over to a gretch Politico S

477
00:24:29.279 --> 00:24:33.519
<v Speaker 2>three bucket, crossing that organizational boundary again. Now, a developer,

478
00:24:33.559 --> 00:24:37.039
<v Speaker 2>maybe Kevin mentioned hypothetically, might have had his personal access

479
00:24:37.119 --> 00:24:40.440
<v Speaker 2>denied to that gretch Politico bucket. But the attacker realized

480
00:24:40.480 --> 00:24:41.279
<v Speaker 2>something crucial.

481
00:24:41.440 --> 00:24:45.000
<v Speaker 1>Let me guess the lambda function's role had permission.

482
00:24:45.079 --> 00:24:48.440
<v Speaker 2>You got it, the lambda's role the identity assigned to

483
00:24:48.480 --> 00:24:51.599
<v Speaker 2>the function itself could access that foreign GP bucket the

484
00:24:51.640 --> 00:24:54.400
<v Speaker 2>function needed it to do its job. This meant that

485
00:24:54.400 --> 00:24:57.440
<v Speaker 2>the attacker could simply choose to register a new Lambda,

486
00:24:57.599 --> 00:25:00.240
<v Speaker 2>assign it this new role, the one with cross account access,

487
00:25:00.359 --> 00:25:02.000
<v Speaker 2>and execute whatever code we like.

488
00:25:02.279 --> 00:25:04.920
<v Speaker 1>So they could essentially hijack the lamb as permissions to

489
00:25:05.000 --> 00:25:07.680
<v Speaker 1>run their own code with access to the other companies

490
00:25:07.720 --> 00:25:08.519
<v Speaker 1>as three bucket.

491
00:25:08.640 --> 00:25:11.519
<v Speaker 2>Precisely taking over the lambda function meant taking over its

492
00:25:11.559 --> 00:25:13.839
<v Speaker 2>privileges another powerful vector.

493
00:25:14.000 --> 00:25:17.200
<v Speaker 1>Okay, this is dizzying in such a highly volatile cloud

494
00:25:17.279 --> 00:25:21.359
<v Speaker 1>environment where applications and servers are constantly changing, maybe even

495
00:25:21.400 --> 00:25:26.119
<v Speaker 1>automatically destroyed and recreated. How do you maintain persistence after

496
00:25:26.160 --> 00:25:28.799
<v Speaker 1>gaining this kind of access. It seems like it would

497
00:25:28.839 --> 00:25:31.920
<v Speaker 1>be incredibly difficult to stay hidden and keep your foothold.

498
00:25:32.039 --> 00:25:35.640
<v Speaker 2>That's a major challenge for attackers. The book emphasizes the

499
00:25:35.680 --> 00:25:39.720
<v Speaker 2>strategy of deploying multiple backdoors with different properties. Don't rely

500
00:25:39.839 --> 00:25:40.200
<v Speaker 2>on just.

501
00:25:40.240 --> 00:25:43.079
<v Speaker 1>One, diversify your persistence methods exactly.

502
00:25:43.319 --> 00:25:46.359
<v Speaker 2>One effective method described is a stable back door using

503
00:25:46.400 --> 00:25:50.359
<v Speaker 2>a tiny Alpine Docker image. Very lightweight, this container is

504
00:25:50.400 --> 00:25:53.920
<v Speaker 2>designed to simply regularly beacon back home check in with

505
00:25:53.960 --> 00:25:56.799
<v Speaker 2>the attacker C two server for commands and be cleverly

506
00:25:56.880 --> 00:25:58.039
<v Speaker 2>hidden in plain sight.

507
00:25:58.240 --> 00:25:58.920
<v Speaker 1>How do you hide it?

508
00:25:59.200 --> 00:25:59.920
<v Speaker 3>Maybe by naming it.

509
00:26:00.039 --> 00:26:03.319
<v Speaker 2>It's something innocuous, something that looks like a legitimate system

510
00:26:03.359 --> 00:26:08.359
<v Speaker 2>component like Amazon today plug in essentials, something as sissiedmin

511
00:26:08.680 --> 00:26:11.920
<v Speaker 2>might glance over. And because Kubernetes is designed to bring

512
00:26:11.960 --> 00:26:15.079
<v Speaker 2>destroyed pods back to life based on its deployment configuration,

513
00:26:15.640 --> 00:26:18.880
<v Speaker 2>if the backdoor container is part of that configuration, ensures

514
00:26:18.920 --> 00:26:23.160
<v Speaker 2>continuous access even if the original compromised container is terminated

515
00:26:23.319 --> 00:26:25.160
<v Speaker 2>or the node restarts.

516
00:26:24.759 --> 00:26:28.000
<v Speaker 1>UH using the orchestrator's self healing feature against itself.

517
00:26:28.200 --> 00:26:31.359
<v Speaker 2>Clever very and for even more stealth. Another back door

518
00:26:31.480 --> 00:26:34.119
<v Speaker 2>might involve a simple crown job hidden on a less

519
00:26:34.200 --> 00:26:37.440
<v Speaker 2>volatile system, or perhaps an even more subtle Docker container

520
00:26:37.480 --> 00:26:39.920
<v Speaker 2>that does very little, just waits for a specific trigger

521
00:26:40.440 --> 00:26:41.720
<v Speaker 2>layers of persistence.

522
00:26:42.000 --> 00:26:45.720
<v Speaker 1>Okay, so persistence achieved. The deep dive then moves to

523
00:26:45.799 --> 00:26:50.119
<v Speaker 1>a completely new target environment within gretsch Politico, a Spark cluster.

524
00:26:50.559 --> 00:26:53.759
<v Speaker 1>What makes Spark such an interesting or perhaps uncharted target

525
00:26:53.759 --> 00:26:54.279
<v Speaker 1>for a hacker.

526
00:26:54.599 --> 00:26:58.119
<v Speaker 2>Well, Spark is a hugely popular framework for big data

527
00:26:58.119 --> 00:27:02.960
<v Speaker 2>processing think large scale analytics, machine learning, but at the

528
00:27:03.000 --> 00:27:05.240
<v Speaker 2>time the book was written. There are apparently almost no

529
00:27:05.400 --> 00:27:09.519
<v Speaker 2>public hacking write ups or tools specifically targeting Spark clusters, so.

530
00:27:09.480 --> 00:27:13.599
<v Speaker 1>It was uncharted waters for security researchers and attackers.

531
00:27:13.319 --> 00:27:16.759
<v Speaker 2>Largely yes, which makes it interesting. The attacker first had

532
00:27:16.799 --> 00:27:20.240
<v Speaker 2>to learn how Spark clusters actually work, understanding the roles

533
00:27:20.240 --> 00:27:23.359
<v Speaker 2>of the master node, the worker nodes where calculations happen,

534
00:27:23.680 --> 00:27:26.440
<v Speaker 2>and the driver program that coordinates it all. Then they

535
00:27:26.440 --> 00:27:30.400
<v Speaker 2>figured out something really clutter by creating a malicious Spark application,

536
00:27:30.960 --> 00:27:34.279
<v Speaker 2>a program submitted to the cluster for processing that included

537
00:27:34.319 --> 00:27:37.920
<v Speaker 2>a subprocess pope and call hidden inside a standard Spark

538
00:27:37.960 --> 00:27:39.720
<v Speaker 2>transformation like a math function.

539
00:27:40.039 --> 00:27:44.119
<v Speaker 1>Wait, you can embed OS commands inside a data transformation.

540
00:27:43.640 --> 00:27:46.319
<v Speaker 2>Apparently so in the setup. This allowed them to execute

541
00:27:46.440 --> 00:27:49.359
<v Speaker 2>arbitrary commands on the Spark worker nodes whenever that part

542
00:27:49.359 --> 00:27:52.480
<v Speaker 2>of the Spark job ran crucially without needing any direct

543
00:27:52.480 --> 00:27:54.400
<v Speaker 2>logging credentials for those worker nodes.

544
00:27:54.480 --> 00:27:57.720
<v Speaker 1>Wow, using the Big data engine itself to run commands remotely.

545
00:27:57.960 --> 00:28:02.359
<v Speaker 2>Yeah, leveraging the system's own distribute computation functionality against itself.

546
00:28:02.519 --> 00:28:03.000
<v Speaker 3>Very neat.

547
00:28:03.279 --> 00:28:06.920
<v Speaker 1>And what was the ultimate prize unearthed within this compromise

548
00:28:07.359 --> 00:28:09.200
<v Speaker 1>Spark cluster? What did they find There.

549
00:28:09.079 --> 00:28:11.960
<v Speaker 2>They discovered that Gretsch Politico was using a tool called

550
00:28:12.240 --> 00:28:15.240
<v Speaker 2>S three S to mount an S three bucket named

551
00:28:15.319 --> 00:28:19.480
<v Speaker 2>gretch Notebooks locally onto their Spark cluster nodes. Like attaching

552
00:28:19.519 --> 00:28:21.319
<v Speaker 2>a cloud drive directly to the system.

553
00:28:21.519 --> 00:28:25.000
<v Speaker 1>Gretch Notebooks sounds like data science territory exactly.

554
00:28:25.359 --> 00:28:28.599
<v Speaker 2>This bucket was full of dot IPMD files. That's the

555
00:28:28.599 --> 00:28:31.000
<v Speaker 2>file extension for Jupiter notebooks.

556
00:28:30.720 --> 00:28:33.359
<v Speaker 1>The interactive coding environments data scientists love.

557
00:28:33.480 --> 00:28:34.240
<v Speaker 3>The very same.

558
00:28:34.640 --> 00:28:38.200
<v Speaker 2>And inside this bucket, nested in a directory called exports twenty,

559
00:28:38.279 --> 00:28:42.880
<v Speaker 2>they found plainold dot CSV files COMMA separated value file.

560
00:28:42.759 --> 00:28:45.960
<v Speaker 1>Ah raw data exports. So what exactly was contained in

561
00:28:45.960 --> 00:28:47.359
<v Speaker 1>those CSV files?

562
00:28:47.559 --> 00:28:50.079
<v Speaker 2>The mother load pretty close A list of clients, all right,

563
00:28:50.119 --> 00:28:52.279
<v Speaker 2>as the book puts it, and not just current customers,

564
00:28:52.319 --> 00:28:56.160
<v Speaker 2>but perspective ones too, complete with incredibly detailed information. We're

565
00:28:56.160 --> 00:29:01.559
<v Speaker 2>talking annual revenue, last contact date, initial contact, country, account manager,

566
00:29:01.720 --> 00:29:03.079
<v Speaker 2>zip code service purchased.

567
00:29:03.319 --> 00:29:07.200
<v Speaker 1>Good grief. It's highly sensitive business intelligence just sitting in

568
00:29:07.279 --> 00:29:09.319
<v Speaker 1>csvs in an S three bucket mounted to.

569
00:29:09.319 --> 00:29:12.039
<v Speaker 2>Spark YEP A gold mine of strategic data.

570
00:29:12.400 --> 00:29:16.400
<v Speaker 1>Okay, Beyond these individual files and databases scattered across different services,

571
00:29:17.000 --> 00:29:19.759
<v Speaker 1>was there a single junction, like a central hub where

572
00:29:19.799 --> 00:29:22.839
<v Speaker 1>all of Gretch Politico's most valuable data might converge.

573
00:29:22.960 --> 00:29:25.720
<v Speaker 2>Yes, and this is where it gets truly deeply unsettling.

574
00:29:26.160 --> 00:29:31.200
<v Speaker 2>By exploiting an im list policies permission, they gained somewhere along.

575
00:29:30.960 --> 00:29:33.440
<v Speaker 1>The way that lets you list all the permission policies

576
00:29:33.440 --> 00:29:34.480
<v Speaker 1>in the AWS account.

577
00:29:34.519 --> 00:29:34.920
<v Speaker 3>Correct.

578
00:29:35.039 --> 00:29:38.200
<v Speaker 2>They were scanning through policies looking for excessive permissions, and

579
00:29:38.279 --> 00:29:42.240
<v Speaker 2>they discovered one named run deck monopolicy. Run Deck is

580
00:29:42.279 --> 00:29:46.559
<v Speaker 2>another automation tool. This IAM policy granted close to full

581
00:29:46.680 --> 00:29:51.640
<v Speaker 2>admin privileges over AWS, almost god mode within the AWS account. Oops,

582
00:29:51.680 --> 00:29:57.200
<v Speaker 2>big oops, including qrickly Redshift permissions full control over Amazon.

583
00:29:56.839 --> 00:30:01.279
<v Speaker 1>Redshift Redshift, being aws's cloud data warehouse service right designed

584
00:30:01.279 --> 00:30:02.319
<v Speaker 1>for massive analytics.

585
00:30:02.359 --> 00:30:05.799
<v Speaker 2>Precisely, this permission led them directly to several Redshift clusters,

586
00:30:05.960 --> 00:30:10.160
<v Speaker 2>including ones ominously named BI likely for business intelligence and finance.

587
00:30:10.480 --> 00:30:15.359
<v Speaker 1>Oh boy, what kind of sensitive, perhaps even chilling data

588
00:30:15.839 --> 00:30:19.240
<v Speaker 1>was exposed in these central Redshift data warehouses?

589
00:30:19.640 --> 00:30:22.440
<v Speaker 2>Well, As the hacker narrator notes, nothing beats a good

590
00:30:22.440 --> 00:30:25.759
<v Speaker 2>old fashioned sequel database where we can query enjoining data

591
00:30:25.799 --> 00:30:30.240
<v Speaker 2>to our hearts content. This Redshift cluster, particularly the buy one,

592
00:30:30.599 --> 00:30:33.279
<v Speaker 2>was indeed the junction of almost every data input poured

593
00:30:33.319 --> 00:30:36.039
<v Speaker 2>into gretch Politico's infrastructure. Everything ended up here.

594
00:30:36.079 --> 00:30:36.759
<v Speaker 1>So what do they find.

595
00:30:36.920 --> 00:30:41.079
<v Speaker 2>They found full online activity logs of individuals, websites, visited,

596
00:30:41.160 --> 00:30:44.279
<v Speaker 2>ads clicked. They found links to social media profiles. They

597
00:30:44.279 --> 00:30:47.960
<v Speaker 2>found incredibly granular data segments used to profile people with

598
00:30:48.079 --> 00:30:51.079
<v Speaker 2>names like politics, Lane left, or health chronicle pain, and

599
00:30:51.240 --> 00:30:55.480
<v Speaker 2>even look alike segments profiles of people who were statistically

600
00:30:55.519 --> 00:30:59.400
<v Speaker 2>similar to existing customers or targets. The book details the

601
00:30:59.440 --> 00:31:03.640
<v Speaker 2>profile of one specific individual, Francistima, as an example. It

602
00:31:03.680 --> 00:31:07.000
<v Speaker 2>included his device type, his last known location derived from

603
00:31:07.039 --> 00:31:10.880
<v Speaker 2>mobile data, a link to his Facebook profile, his inferred interests,

604
00:31:11.279 --> 00:31:16.000
<v Speaker 2>and even a calculated character map enumerting his level of influence, impulse,

605
00:31:16.039 --> 00:31:19.279
<v Speaker 2>and ad interaction how likely he was to click, buy,

606
00:31:19.400 --> 00:31:20.839
<v Speaker 2>or share based on his profile.

607
00:31:20.960 --> 00:31:24.200
<v Speaker 1>That level of detail is well, it's the core product

608
00:31:24.200 --> 00:31:26.759
<v Speaker 1>of a company like that, but seeing it laid bare

609
00:31:26.920 --> 00:31:31.359
<v Speaker 1>is quite something, incredibly detailed and yes, frankly chilling.

610
00:31:31.640 --> 00:31:34.559
<v Speaker 2>It really shows the sheer scope and granularity of data

611
00:31:34.559 --> 00:31:36.759
<v Speaker 2>collection and analysis happening in these systems.

612
00:31:36.839 --> 00:31:39.440
<v Speaker 1>Okay, they've got the core data, the business intelligence, the

613
00:31:39.440 --> 00:31:42.799
<v Speaker 1>customer profiles. What was the absolute final step in this

614
00:31:42.880 --> 00:31:45.799
<v Speaker 1>deep dive, the final piece of the puzzle for the attackers.

615
00:31:45.559 --> 00:31:49.519
<v Speaker 2>Hacking company emails, getting into the internal communications.

616
00:31:48.839 --> 00:31:52.119
<v Speaker 1>The crown jewels for corporate espionage. Often they manage that.

617
00:31:52.480 --> 00:31:56.599
<v Speaker 2>Again, leveraging previous fines, they went back to Gethub, searching

618
00:31:56.680 --> 00:32:01.839
<v Speaker 2>specifically for gretch politico repositories related to IT or GAPS

619
00:32:02.039 --> 00:32:06.119
<v Speaker 2>short for Google Apps now Google Workspace. They found a

620
00:32:06.160 --> 00:32:09.920
<v Speaker 2>private repository named it gress suite apps looked like code

621
00:32:10.000 --> 00:32:13.480
<v Speaker 2>for internal tools managing their Google Workspace setup.

622
00:32:13.240 --> 00:32:16.759
<v Speaker 1>Automating user creation, maybe group management, that kind of thing exactly.

623
00:32:17.240 --> 00:32:19.720
<v Speaker 2>While no direct passwords were found in the code, this time,

624
00:32:19.799 --> 00:32:23.119
<v Speaker 2>they identified that this internal application used a Google Service

625
00:32:23.160 --> 00:32:27.240
<v Speaker 2>account to perform its administrative actions. And where was the

626
00:32:27.319 --> 00:32:31.599
<v Speaker 2>key for this powerful service account stored in AWS Secrets Manager,

627
00:32:32.039 --> 00:32:35.720
<v Speaker 2>another AWS service specifically for storing secrets securely.

628
00:32:36.079 --> 00:32:38.960
<v Speaker 1>Ah But they already had broad AWS access by this

629
00:32:39.000 --> 00:32:41.759
<v Speaker 1>point right, including possibly access to Secrets Manager.

630
00:32:41.839 --> 00:32:45.720
<v Speaker 2>Precisely, the run deck monopolicy likely gave them the necessary permission, So.

631
00:32:45.640 --> 00:32:48.160
<v Speaker 1>Once they had that Google Service account key, they.

632
00:32:48.000 --> 00:32:51.519
<v Speaker 2>Retrieved the key file from AWS Secrets Manager. Now, this key,

633
00:32:51.680 --> 00:32:55.000
<v Speaker 2>when combined with a critical Google workspace setting called domain

634
00:32:55.119 --> 00:32:56.920
<v Speaker 2>wide delegation privileges.

635
00:32:57.079 --> 00:32:57.720
<v Speaker 1>What was it that too?

636
00:32:57.920 --> 00:33:01.359
<v Speaker 2>It's a very powerful setting. It allows a service account

637
00:33:01.400 --> 00:33:03.839
<v Speaker 2>to act on behalf of any user within the entire

638
00:33:03.880 --> 00:33:07.720
<v Speaker 2>Google Workspace domain if authorized by an admin. So the

639
00:33:07.759 --> 00:33:11.599
<v Speaker 2>attackers use the service account key enabled domain wide delegation

640
00:33:11.920 --> 00:33:15.319
<v Speaker 2>and then told it to impersonate a known super admin

641
00:33:15.400 --> 00:33:19.599
<v Speaker 2>email address Adminute at gretchpolitico dot com so.

642
00:33:19.519 --> 00:33:21.880
<v Speaker 1>They could act as the itadmin programmatically.

643
00:33:22.039 --> 00:33:25.880
<v Speaker 2>Yes, this allowed them to use Google's APIs to programmatically

644
00:33:25.880 --> 00:33:29.880
<v Speaker 2>create brand new users in Gretch Politico's corporate directory. They

645
00:33:29.880 --> 00:33:33.759
<v Speaker 2>effectively created a new user Henniel at gretchpolitico dot com,

646
00:33:33.759 --> 00:33:36.759
<v Speaker 2>completely out of finair, potentially with high privileges.

647
00:33:36.279 --> 00:33:40.039
<v Speaker 1>Giving themselves a legitimate looking account inside the company's Google workspace.

648
00:33:40.240 --> 00:33:40.799
<v Speaker 3>Exactly.

649
00:33:41.200 --> 00:33:45.720
<v Speaker 2>This achieved admin access to GP's corporate directory and by extension,

650
00:33:45.759 --> 00:33:49.519
<v Speaker 2>potentially full access to all company Gmail inboxes and Google

651
00:33:49.599 --> 00:33:53.279
<v Speaker 2>Drive files, depending on the exact permissions granted. The book

652
00:33:53.319 --> 00:33:56.240
<v Speaker 2>even concludes by sharing a redacted snippet purported to be

653
00:33:56.279 --> 00:33:59.640
<v Speaker 2>from the CEO's emails revealing sensitive internal discussions about political

654
00:33:59.640 --> 00:34:03.119
<v Speaker 2>stratgy like going after his public image and potentially making

655
00:34:03.200 --> 00:34:03.799
<v Speaker 2>up a story.

656
00:34:04.200 --> 00:34:08.679
<v Speaker 1>Wow, just wow. What an absolutely incredible and frankly terrifying

657
00:34:08.800 --> 00:34:11.719
<v Speaker 1>journey we've just traced. We've seen how attackers no longer

658
00:34:11.840 --> 00:34:15.599
<v Speaker 1>just target individual machines, but the very fabric the control

659
00:34:15.639 --> 00:34:20.800
<v Speaker 1>plane of cloud infrastructure. From meticulously setting up anonymous operations,

660
00:34:21.119 --> 00:34:26.599
<v Speaker 1>conducting incredibly deep reconnaissance, to exploiting subtle, nuanced misconfigurations and

661
00:34:26.679 --> 00:34:30.239
<v Speaker 1>complex services like S three and Kubernetes. Yeah, all the

662
00:34:30.239 --> 00:34:33.480
<v Speaker 1>way to stealing vast amounts of highly personalized data and

663
00:34:33.519 --> 00:34:37.000
<v Speaker 1>gaining complete control over sensitive company emails. It's the whole

664
00:34:37.039 --> 00:34:38.480
<v Speaker 1>new ballgame, it really is.

665
00:34:38.880 --> 00:34:41.400
<v Speaker 2>What this deep dog highlights so powerfully, I think is

666
00:34:41.440 --> 00:34:44.920
<v Speaker 2>that the broad adoption and maybe the generalization of cloud

667
00:34:44.920 --> 00:34:49.239
<v Speaker 2>computing is a truly disruptive event in cybersecurity, a paradigm shift.

668
00:34:49.519 --> 00:34:53.119
<v Speaker 2>The focus has shifted dramatically away from individual machines towards

669
00:34:53.159 --> 00:34:56.880
<v Speaker 2>the underlying infrastructure, the APIs, the orchestration layers, and away

670
00:34:56.880 --> 00:35:00.559
<v Speaker 2>from traditional network perimeters towards identity, API, call and service

671
00:35:00.559 --> 00:35:02.800
<v Speaker 2>accounts as the new boundaries to defend.

672
00:35:02.960 --> 00:35:06.280
<v Speaker 1>The old castles and moats model just doesn't apply cleanly anymore,

673
00:35:06.519 --> 00:35:06.880
<v Speaker 1>not in.

674
00:35:06.840 --> 00:35:07.320
<v Speaker 3>The same way.

675
00:35:07.440 --> 00:35:10.440
<v Speaker 2>No, the old tricks, as we discussed are rapidly becoming

676
00:35:10.480 --> 00:35:13.880
<v Speaker 2>obsolete or at least less effective on their own, and new,

677
00:35:14.239 --> 00:35:18.440
<v Speaker 2>far more sophisticated multi stage techniques targeting the cloud specific

678
00:35:18.559 --> 00:35:20.880
<v Speaker 2>architecture are emerging as the norm.

679
00:35:21.119 --> 00:35:23.840
<v Speaker 1>It's such a powerful reminder that security in the cloud

680
00:35:23.920 --> 00:35:27.039
<v Speaker 1>isn't just about firewalls and antivirus anymore, is it. It's

681
00:35:27.039 --> 00:35:31.239
<v Speaker 1>about deeply understanding how every single component, every automation tool

682
00:35:31.280 --> 00:35:34.440
<v Speaker 1>like Jenkins or Chef, every LAMB to function, and every

683
00:35:34.440 --> 00:35:38.480
<v Speaker 1>single configuration choice interacts creates a potential loophole. It's about

684
00:35:38.480 --> 00:35:42.079
<v Speaker 1>the interconnectedness, the layers upon layers of permissions, and the

685
00:35:42.119 --> 00:35:46.239
<v Speaker 1>sheer speed of continuous deployment. It's incredibly complex.

686
00:35:46.360 --> 00:35:48.440
<v Speaker 2>It is complex, and for you, the learner listening in

687
00:35:48.480 --> 00:35:51.760
<v Speaker 2>this offers a truly unique perspective. I hope it demonstrates

688
00:35:51.760 --> 00:35:54.360
<v Speaker 2>that knowledge is most valuable when it's not just theoretical,

689
00:35:54.599 --> 00:35:58.239
<v Speaker 2>but understood in context and applied. It hopefully encourages critical

690
00:35:58.280 --> 00:36:01.320
<v Speaker 2>thinking about the complex digital world that surrounds us all,

691
00:36:01.719 --> 00:36:05.079
<v Speaker 2>a world that is becoming increasingly abstract and reliant on

692
00:36:05.119 --> 00:36:07.360
<v Speaker 2>these vast, intricate cloud systems.

693
00:36:07.559 --> 00:36:09.079
<v Speaker 1>So what does this all mean for you? As you

694
00:36:09.159 --> 00:36:13.119
<v Speaker 1>navigate this world, a world increasingly reliant on the cloud

695
00:36:13.360 --> 00:36:17.440
<v Speaker 1>for everything from work to entertainment to social connection. It

696
00:36:17.519 --> 00:36:20.679
<v Speaker 1>means that understanding the attacker's mindset, that ghost minds that

697
00:36:20.760 --> 00:36:24.400
<v Speaker 1>we explored is no longer just for the security professionals

698
00:36:24.400 --> 00:36:27.639
<v Speaker 1>in the trenches. It's becoming essential for anyone who interacts

699
00:36:27.639 --> 00:36:31.679
<v Speaker 1>with technology, build software, or relies on digital services, And

700
00:36:31.719 --> 00:36:34.800
<v Speaker 1>it really raises a profound, perhaps unsettling question for all

701
00:36:34.840 --> 00:36:37.440
<v Speaker 1>of us. Are the systems we rely on every day

702
00:36:37.440 --> 00:36:41.119
<v Speaker 1>truly as secure as we believe, or are there hidden cracks,

703
00:36:41.440 --> 00:36:45.039
<v Speaker 1>subtle misconfigurations waiting just beneath the surface, ready to be

704
00:36:45.079 --> 00:36:48.159
<v Speaker 1>exploited by a subtle touch, a forgotten permission, or a

705
00:36:48.199 --> 00:36:51.800
<v Speaker 1>perfectly aimed API request. Something for you to consider as

706
00:36:51.840 --> 00:36:53.039
<v Speaker 1>you go about your digital day.