Speaker 1: Welcome to the deep dive. We take a stack of
Speaker 1: information and extract those surprising nuggets of knowledge. Today we're
Speaker 1: plunging into a truly fascinating and frankly a bit in
Speaker 1: settling area that has entirely redefined cybersecurity, hacking the cloud.
Speaker 1: Our mission for this deep dive really is to understand
Speaker 1: just how profoundly the landscape of digital intrusion has shifted.
Speaker 1: We're going to sort of shed the old mental models
Speaker 1: of traditional network attacks and instead explore what it truly
Speaker 1: means to hack like a ghost in our modern cloud
Speaker 1: powered world. We're drawing our insights from Sparkflow's compelling work
Speaker 1: how to Hack like a Ghost Breaching the Cloud.
Speaker 2: And what's truly fascinating here, I think, is how the
Speaker 2: very architecture of cloud computing, and also principles like DevOps
Speaker 2: you know, which are designed for efficiency for speed, they
Speaker 2: also kind of inadvertently create entirely new classes.
Speaker 1: Of vulnerability right new ways.
Speaker 2: In exactly, we'll discover how attackers can manipulate core infrastructure
Speaker 2: elements from well virtually anywhere on Earth, which is a
Speaker 2: stark contrast to the old days of simply mischie hopping
Speaker 2: within a physical network a huge change.
Speaker 1: So what does this cutting edge knowledge mean for you
Speaker 1: listening in? Maybe you're prepping for a crucial meeting, or
Speaker 1: just catching up on the field, or maybe you're just
Speaker 1: driven by pure curiosity. Well, you're about to get a
Speaker 1: unique shortcut to being well informed on the bleeding edge
Speaker 1: of cybersecurity. We're going to trace a hacker's sophisticated journey
Speaker 1: from setting up completely anonymous operations to taking over critical
Speaker 1: cloud infrastructure and ultimately even accessing deeply personal data and
Speaker 1: company emails. Okay, so let's unpack this. The book argues
Speaker 1: that the entire zeitgeist, the spirit of the times, is
Speaker 1: changing in cybersecurity. Why can't attackers just use their traditional
Speaker 1: bag of tricks, you know, like a classic sequel injection
Speaker 1: attack against these sprawling modern cloud companies.
Speaker 2: Well, if we zoom out and connect this to the
Speaker 2: bigger picture, it's really about a fundamental architectural shift. Think
Speaker 2: about it. Companies aren't typically spinning up physical windows domain
Speaker 2: controllers in their server rooms anymore, not usually.
Speaker 1: Right, it's all cloud consoles now exactly.
Speaker 2: Instead, they're launching databases, dock or containers, even entire identity
Speaker 2: systems like active directory with literally one click in a
Speaker 2: cloud environment, and this fundamentally alters the attacker's ultimate goal.
Speaker 1: It's huge.
Speaker 2: It's no longer just about taking control of individual machines.
Speaker 2: That's almost secondary. Sometimes it's about gaining control over the
Speaker 2: entire infrastructure itself, the control plane.
Speaker 1: In DevOps too, you mentioned it's more than just a buzzword,
Speaker 1: isn't it. It feels like it changes everything.
Speaker 3: Oh, absolutely exactly.
Speaker 2: DevOps principles things like infrastructure as code, where.
Speaker 1: The whole setup is basically a script precisely.
Speaker 2: That and containerization mean companies are in this state of
Speaker 2: constant change. They're deploying new code, new applications at lightning speed.
Speaker 2: The old it mantra you know, if it's working, don't
Speaker 2: change it, that's completely out the window.
Speaker 1: Okay, So constant change, more opportunities for.
Speaker 2: Mistakes, that's part of it. This rapid evolution means that
Speaker 2: vulnerabilities that might have been mind or may be overlooked
Speaker 2: in a classic setup, they can acquire what the source
Speaker 2: calls lethal potential in the cloud. Your traditional hacker intuition,
Speaker 2: which might have served you well in the past, well,
Speaker 2: it definitely benefits from some small adjustments.
Speaker 3: Let's say to stay effective.
Speaker 1: Got a doubt, Okay, So before any actual hacking begins,
Speaker 1: the book emphasizes a crucial first step, becoming a ghost.
Speaker 1: This means focusing heavily on operational security OPSEC and building
Speaker 1: an anonymous, efficient hacking infrastructure. Why is this initial set
Speaker 1: up so incredibly vital, especially for real world attackers, not
Speaker 1: just you know testers.
Speaker 2: Yeah, this raises a really important question about anonymity. It's
Speaker 2: critical Unlike professional red teamers or penetration testers who often
Speaker 2: have a clear scope, maybe even do.
Speaker 1: Over the permission basically.
Speaker 2: Right, real hackers, though, they're betting their actual freedom on
Speaker 2: their ability to remain completely anonymous. And the source makes
Speaker 2: it crystal clear. Even popular VPN services will always always
Speaker 2: keep some form of logs, always, despite the marketing, despite
Speaker 2: the marketing, and even privacy networks like tour aren't a
Speaker 2: magical shield. They have limitations. You have to pay, As
Speaker 2: the book says, as much attention to your physical trail
Speaker 2: as you do to your Internet fingerprint. Leave no trace anywhere,
Speaker 2: so walk.
Speaker 1: Us through it. What does this anonymous setup actually look
Speaker 1: like in practice? The book gets pretty specific.
Speaker 2: It's all about layers, layers of obfuscation. First, an attacker
Speaker 2: would likely use an ephemeral operating system, something like TAILS
Speaker 2: loaded onto a USB.
Speaker 1: Drive fhmeral meaning temporary exactly.
Speaker 2: This OS is designed to flush everything away on every reboot.
Speaker 2: Nothing sticks, and it forces all Internet connections through tour,
Speaker 2: making it incredibly difficult to trace back.
Speaker 1: Okay, step one.
Speaker 2: Then what From there? They connect to a series of
Speaker 2: bouncing servers. These are virtual hosts like vms, set up
Speaker 2: anonymously in different locations, maybe different providers. Crucially, these bouncing
Speaker 2: servers never directly interact with the target.
Speaker 3: That's key.
Speaker 1: You're like middleman.
Speaker 2: Exactly, secure staging grounds. They host management tools like Terraform,
Speaker 2: Docker stuff to build the next layer. The actual attack infrastructure,
Speaker 2: the servers doing the real work, is even more fleeting,
Speaker 2: used for only a few days maybe, and completely unique
Speaker 2: to each operation, then destroyed.
Speaker 1: Wow. This level of automation using tools like Docker and Terraform,
Speaker 1: it all sounds like adopting a DevOps mindset for the
Speaker 1: hacking process itself.
Speaker 2: That's spot on it really is. It's about embracing efficiency.
Speaker 2: By automating the setup, it becomes much easier to spring
Speaker 2: fully configured attacking servers into existence, pop them up, tear
Speaker 2: them down, and that significantly reduces the gens of making
Speaker 2: critical mistakes when you're operating under pressure.
Speaker 1: Makes sense, fewer manual steps, fewer errors, right.
Speaker 2: The book gives examples of how an attacker can use
Speaker 2: simple commands like Docker, pul potion stuff to grab a
Speaker 2: pre built hacking tool, or terraform apply to automatically deploy
Speaker 2: their command and control servers their C two.
Speaker 1: That's the hacker mission control right.
Speaker 2: Yeah, basically where they manage the compromise systems and Terraform
Speaker 2: sets it all up even with secure connections, TLS certificates
Speaker 2: the works.
Speaker 1: Okay, anonymous infrastructure meticulously set up. What's next reconnaissance. I
Speaker 1: assume our fictional targets in this deep dive are Gretch, Politico,
Speaker 1: a firm specializing in political campaigns, and its close partner
Speaker 1: ms r ADS. How do hackers even begin to dig
Speaker 1: into these targets in a vast cloud environment, Where do
Speaker 1: you start looking?
Speaker 3: Well?
Speaker 2: This phase is all about what the book calls healthy stocking.
Speaker 3: Huh.
Speaker 2: It means gathering every piece of public facing information imaginable,
Speaker 2: just scooping it all up. The source emphasizes searching platforms
Speaker 2: like SlideShare, loogle drives, script document cloud places where documents might.
Speaker 1: Leak publicly accessible files they forgot about or didn't secure
Speaker 1: properly exactly.
Speaker 2: They use specific targeted search engine terms like site dot dox,
Speaker 2: c stack, Google dot com, gretch, Politico to uncover these
Speaker 2: digital breadcrumbs.
Speaker 1: And beyond public document where else can they unearth valuable
Speaker 1: clues about their target? Seems like documents are just one piece,
Speaker 1: oh for sure.
Speaker 2: GitHub is an absolute gold mine, a potential gold mine anyway.
Speaker 2: While basic searches have their limits, The real trick the
Speaker 2: book suggests is to download entire public repositories related to
Speaker 2: the target and then unleash the full wrath of good
Speaker 2: old rep on them.
Speaker 1: Rep The command line search tool YEP a powerful.
Speaker 2: Tool that can quickly search through massive amounts of text
Speaker 2: for specific patterns. They'd be looking for sensitive strings like ossicritic,
Speaker 2: sess kei, or maybe begin private key, things that should
Speaker 2: never be.
Speaker 1: In public code credentials just sitting there.
Speaker 2: It happens more often than you'd think. They also script
Speaker 2: code snippets from public code sharing sites like just dot
Speaker 2: GitHub dot com and pastebin dot com. Sometimes developers paste
Speaker 2: things there for quick sharing or debugging and accidentally expose
Speaker 2: log file extracts or even database extracts hops.
Speaker 1: Wow. Okay, so after all this digital slew thing, this
Speaker 1: healthy stocking, what did the reconnaissance reveal about Gretch, Politico
Speaker 1: and mxr ADS.
Speaker 2: Well, the initial SUITEP showed their core service is building
Speaker 2: these detailed voter profiles and that they have this incredibly
Speaker 2: intertwined relationship with mxr ADS for the advertising side, very
Speaker 2: close partners.
Speaker 1: Which could be good for business but bad for security exactly.
Speaker 2: The book notes this intertwined connection, while profitable, could prove
Speaker 2: fatal to both companies if one gets compromised. They also
Speaker 2: identified numerous subdomains like Dashboard dot Gretchpolitico dot com using
Speaker 2: specialized tools like sublister R and fern Melder, and then
Speaker 2: they performed ENDMP scans on those domains to see what
Speaker 2: ports were open, what services were running.
Speaker 1: Building a map of their online presence.
Speaker 2: Right. This whole process ultimately provided over one hundred domains
Speaker 2: belonging to both organizations, which, as the book says, offers
Speaker 2: a significant luxury of choice for finding a way in
Speaker 2: lots of doors.
Speaker 1: To check one hundred domains with literally dozens maybe hundreds identified.
Speaker 1: How do you even begin to find the ulnerabilities? It
Speaker 1: sounds like trying to find a needle in a haystack
Speaker 1: the size of a continent. Overwhelming.
Speaker 3: It absolutely can feel that way.
Speaker 2: Yeah, but the book emphasizes, you know, the more you practice,
Speaker 2: the better you will get. Experience counts, and in a
Speaker 2: full cloud environment, there are shortcuts. A crucial one is
Speaker 2: to reveal the real domains behind public facing domains.
Speaker 1: How do you do that?
Speaker 2: By looking for cnam entries in DNS records instead of
Speaker 2: just the raw IP addresses. A CNME is basically like
Speaker 2: a nickname for a server. It lets multiple web adjustes
Speaker 2: point to the same underlying resource.
Speaker 1: Oh okay, so it reveals the actual service provider.
Speaker 3: Sometimes exactly.
Speaker 2: This simple step revealed that many msr ADS domains were
Speaker 2: actually hosted on AWS using common services like CloudFront for
Speaker 2: content delivery, S three for storage, and ELB for load balancing.
Speaker 2: Standard stuff, but crucially gretch Politico's own dashboard URL dashboard
Speaker 2: dot gretsch politico dot com even pointed to an mxr
Speaker 2: ADS domain.
Speaker 1: Directly confirmed how tightly length they are.
Speaker 2: Yeah, strong confirmation of those deep operational ties.
Speaker 1: And what was the big aha moment in this phase,
Speaker 1: the critical breakthrough that opened the first real door.
Speaker 2: The discovery of vulnerable S three buckets. S three aws'
Speaker 2: is simple storage service basically.
Speaker 1: Cloud file story right use for everything.
Speaker 2: Pretty much now default S three security has tightened up
Speaker 2: over time, thankfully, but the book explains that the four
Speaker 2: overlapping settings, things like access control lists ACLS, core S configurations,
Speaker 2: bucket policies, and IAM policies. It all makes S three
Speaker 2: security very.
Speaker 1: Convoluted, easy to mess up, them.
Speaker 2: Very easy to misconfigure, and for one domain misc dot
Speaker 2: mxrads dot com, while directory listing was denied, you couldn't
Speaker 2: just browse it using the awscli, the command line tool
Speaker 2: to run list objects h V two. While that surprisingly
Speaker 2: revealed over four hundred thousand files stored in the single.
Speaker 1: Bucket, whoa just sitting there accessible.
Speaker 2: Accessible if you knew the command to list them, including
Speaker 2: an empty index dot m HTML at the root, which
Speaker 2: is often assigned. Something's not quite right.
Speaker 1: Okay, four hundred thousand files is a lot, but maybe not.
Speaker 1: The keys to the kingdom was that the biggest find.
Speaker 2: No, not the biggest breakthrough, but certainly highlighted poor configuration hygiene.
Speaker 3: A warning sign.
Speaker 2: The truly critical vulnerability, the one that really crack things open,
Speaker 2: was a server side request forgery or SSRF, found on
Speaker 2: demo dot mxrads dot com.
Speaker 1: SSRF. Okay, remind me again what that lets an attacker do, right.
Speaker 2: SSRF is like tricking a server one that's sitting inside
Speaker 2: a supposedly secure network to make a request on your behalf.
Speaker 2: It makes requests to other internal systems that the server
Speaker 2: can reach, but you from the outside can't.
Speaker 1: Okay, So you're using the server as a proxy to
Speaker 1: hit internal stuff.
Speaker 3: Essentially, Yes.
Speaker 2: By manipulating a URL and the demo application using a
Speaker 2: tool like burke Suite, a standard web app testing toolkit,
Speaker 2: the attacker could force the application to make internal requests
Speaker 2: specifically to the AWS metadata API.
Speaker 1: Ah, that's special address HTTP dot one six nine point
Speaker 1: two five four point one six nine point two five
Speaker 1: four littles, that's the one. Here's where it gets really interesting.
Speaker 1: As you said, this isn't a normal web address. What
Speaker 1: kind of information does this mysterious metadata API actually reveal?
Speaker 2: Yeah, it's a special internal address unique to cloud environments
Speaker 2: like AWS instances. Those virtual computers can query it to
Speaker 2: get information about themselves. Like asking who am I, what.
Speaker 3: Can I do? It reveals a whole trove.
Speaker 2: Of metadata, the machine's host name, its internal IP address,
Speaker 2: firewall rules, basic identity cards.
Speaker 1: Stuff. Okay, useful but maybe not devastating.
Speaker 2: Ah. But the dirty secret, as the book puts it,
Speaker 2: is that it can also expose the user.
Speaker 1: Data script, the script that runs when the machine first boots.
Speaker 2: Up exactly, often used for setup configuration, and sometimes developers
Speaker 2: put sensitive stuff in there. For mxri ads demo server,
Speaker 2: this user data script contained crucial environment variables, including a
Speaker 2: reference to a secrets dot em V file and guess
Speaker 2: what was in.
Speaker 1: There, daz passwords jackpot.
Speaker 2: The script or the file it pointed to yielded many
Speaker 2: passwords to access Cassandra clusters, Cassandra being a popular Noseql database.
Speaker 1: Yeah, okay, direct database access and it gets better.
Speaker 2: It also revealed IAM role credentials for the machine.
Speaker 1: Itself, imm identity and access management. The permissions in the
Speaker 1: machine has within AWS.
Speaker 2: Correct and these role credentials are often not subject to
Speaker 2: the same IP restrictions as regular user credentials. They're incredibly
Speaker 2: valuable because they can potentially be used from anywhere, So.
Speaker 1: A seemingly simple SSRF vulnerability maybe in a forgotten demo
Speaker 1: app could spiral into gaining highly privileged credentials for other
Speaker 1: AWS services. That's quite a leap.
Speaker 2: Absolutely, It's a classic cloud escalation path. Even though the
Speaker 2: attacker was initially denied direct access to list all S
Speaker 2: three buckets using these credentials, the im role itself, the
Speaker 2: specific permissions assigned to that demo application was successfully used
Speaker 2: to list objects V two within a different important looking
Speaker 2: bucket mex rads DL, and that revealed hundreds of thousands
Speaker 2: of JR files and other binaries, probably application code libraries.
Speaker 1: It's like finding a key that doesn't open the front door,
Speaker 1: but opens a side door to the engineering lab.
Speaker 2: That's a good analogy. Yes, once you're inside, even limited
Speaker 2: permissions can often be leveraged to find more access.
Speaker 1: Okay. The book then describes another major vulnerability found on
Speaker 1: a different site Www. Dot surveysandstats dot com. What was
Speaker 1: that one?
Speaker 2: That was a server side template injection or SSTI vulnerability.
Speaker 1: SSTI sounds similar to SSRF, but different.
Speaker 2: Similar in that you're tricking the server, but the mechanism
Speaker 2: is different. Instead of making external requests, you're tricking the
Speaker 2: server into executing code you provide within its own templating engine.
Speaker 1: Templeting engine like for generating web.
Speaker 2: Pages exactly things like jinga two in Python or handlebars
Speaker 2: and JavaScript. They take data and put it into a template.
Speaker 2: By injecting a simple string like into a form field
Speaker 2: on the website and seeing the server respond with sixteen
Speaker 2: instead of the original string means.
Speaker 1: The server actually calculated eight times too it ran code.
Speaker 2: Bingo confirmed the vulnerability. This then allowed the attacker to
Speaker 2: use advanced features of the programming language Python, in this
Speaker 2: case things like introspection and reflection, essentially letting the code
Speaker 2: examine and modify itself to eventually call subprocess.
Speaker 1: Popin, which basically means.
Speaker 2: Arbitrary code execution on the server. Full control, They could
Speaker 2: make the server run almost any command they wanted.
Speaker 1: Game over for that server then, and what was the
Speaker 1: immediate juicy payoff from gaining that arbitrary code execution.
Speaker 2: Well, they immediately gained SEES simple Email Service credentials, aws's
Speaker 2: email service, useful.
Speaker 1: For sending spam maybe or something more.
Speaker 2: More importantly, it confirmed that survey sandstats dot com belonged
Speaker 2: to the same AWS account as mxr ads, tying the
Speaker 2: infrastructure together. Further, and even more critically, they found that
Speaker 2: while external Internet access was blocked on this particular server
Speaker 2: at common security measures, so they.
Speaker 1: Couldn't just download tools or send data out easily.
Speaker 2: Right, But they discovered they could smuggle in a request
Speaker 2: to a bucket in our own AWS account by exploiting
Speaker 2: something for an S three VPC N point configuration. It's
Speaker 2: a way for internal servers to talk to S three
Speaker 2: without going over the public Internet clever, so.
Speaker 1: They could use S three as a communication channel exactly.
Speaker 3: This was huge. It led to a reliable way to
Speaker 3: communicate with.
Speaker 2: The outside world from this otherwise sealed off survey app,
Speaker 2: and it enabled command execution through S three files. They'd
Speaker 2: upload a command file to their own bucket, the server
Speaker 2: would fetch and run it via the endpoint and send
Speaker 2: results back the same.
Speaker 1: Way, essentially creating an S three base back door. Wow,
Speaker 1: it's like finding a secret pneumatic tube system out of
Speaker 1: a locked room.
Speaker 2: Hey, yeah, something like that. A very effective stealthy channel.
Speaker 1: Okay, So with initial access established via SSRF and SSTI
Speaker 1: leading to code execution and a back door, the hacker
Speaker 1: discovers there inside a container, but not just any container
Speaker 1: one managed by a Kubernetes cluster. For those less familiar,
Speaker 1: what does Kubernetes fundamentally change about the hacking target compared
Speaker 1: to just compromising a single traditional server. Right.
Speaker 2: Kubernetes, or cube as it's often called, is described in
Speaker 2: the book as the ultimate container orchestrator. It's a game changer.
Speaker 2: Imagine hundreds, maybe thousands of software containers which are like lightweight,
Speaker 2: isolated virtual machines, all running different parts of applications. Kubernetes
Speaker 2: manages all of them. It starts them, stops them, connects them,
Speaker 2: scales them up or down automatically based on demand.
Speaker 1: So it's like the conductor of a huge orchestra of software.
Speaker 3: That's a great way to put it.
Speaker 2: The book explains its core components pods, which are groups
Speaker 2: of one or more containers that run together, services which
Speaker 2: handle internal load balancing and networking between pods, and crucially,
Speaker 2: the API server and the etcetera database. These maintain the
Speaker 2: cluster's desired state. Kubernetes is always trying to make reality
Speaker 2: match that desired state, so attacking it isn't like attacking
Speaker 2: one server. It's about understanding and manipulating this complex dynamic system.
Speaker 1: Okay, so find yourself inside one of these containers, maybe
Speaker 1: through web vulnerability like we just discussed, how do you
Speaker 1: break out or gain more control over the entire Kubernetes
Speaker 1: cluster itself. That sounds like a monumental leap.
Speaker 2: It is, but often, like with S three, it comes
Speaker 2: down to misconfigurations. Small oversights can have big impacts and cube.
Speaker 2: The first key discovering the book scenario was that the
Speaker 2: compromised container was running with a default service account.
Speaker 1: A service account being like an identity for the software.
Speaker 2: Itself exactly, and Kubernetes gives containers a token, a JWT
Speaker 2: JSON webtoken like a digital passport associated with the service account.
Speaker 2: It's usually mounted automatically inside the container at a specific
Speaker 2: filepath run secret Scubernetes dot Io service account token. By
Speaker 2: grabbing this token, the attacker could directly query the Kubernetes
Speaker 2: API server pretending to be that container.
Speaker 1: Okay, but what can a default account usually do? Isn't
Speaker 1: it lockdown?
Speaker 2: It should be, But here's the critical part. The book
Speaker 2: notes that if this default account was unwittingly granted extra
Speaker 2: privileges by an administrator, maybe for some forgotten reason, then
Speaker 2: all the other pods running with the same identity will
Speaker 2: automatically inherit these same privileges. Suddenly, that default account isn't
Speaker 2: so basic anymore.
Speaker 1: Uh, A shared identity with escalated permissions precisely, and in
Speaker 1: this case, it allowed the attacker to list hundreds of
Speaker 1: pods specifically in the prod name space, usually the live
Speaker 1: production environment.
Speaker 2: And even more, they could extract their full Yamel manifests.
Speaker 1: The configuration files for those pods.
Speaker 2: Yes, revealing things like environment variables, container images used, and
Speaker 2: even secret key ref pointers. These are references that tell
Speaker 2: Kubernetes where to find other secrets like database passwords or
Speaker 2: API keys and inject them into the pod.
Speaker 1: So looking at the POD's configuration reveals pointers to the
Speaker 1: actual secrets if.
Speaker 3: Configured that way.
Speaker 2: Yes, it's like finding a treasure map inside the container.
Speaker 1: This sounds like a massive win an insider's view of
Speaker 1: the entire production environment, potentially exposing very sensitive data. What
Speaker 1: kind of stuff was actually exposed through this elevated Kubernetes access.
Speaker 2: They literally discovered containers configured to load AWS credentials directly
Speaker 2: as secrets, very sensitive stuff by abusing those Kubernetes service
Speaker 2: account privileges. Using the token they found, they could ask
Speaker 2: the Cube API to retrieve secrets like dbcore password directly
Speaker 2: from the cluster's secret store.
Speaker 1: Wow, just ask Cube for the password.
Speaker 2: If the service account had permission, Yes, and this led
Speaker 2: directly to campaign database credentials for a mysucle database. This
Speaker 2: allowed them to infiltrate gretch Politico's core campaign database and
Speaker 2: pull pretty much everything detailed customer data, campaign budgets, conternal notes,
Speaker 2: and even links to the creatives. The actual campaign materials
Speaker 2: like videos and images which were hosted.
Speaker 1: On S three And could they access those S three
Speaker 1: files too?
Speaker 2: Yes, because the Kubernetes secrets also likely contained AWS keys,
Speaker 2: or maybe the service account itself had im permissions. They
Speaker 2: leveraged their new found I AM access to download these
Speaker 2: videos directly from S three, which, as the book points out,
Speaker 2: underscores a key cloud principle. A cloud provider does not
Speaker 2: care where you are. As long as you have the
Speaker 2: right credentials, you can download whatever you want.
Speaker 1: Location is irrelevant. Only credentials matter. Chilling very much So Okay,
Speaker 1: beyond databases and file storage, what other powerful tools did
Speaker 1: the hacker's target to achieve even deeper more systemic access
Speaker 1: within the organization's infrastructure.
Speaker 2: They pivoted to the infrastructure management tools, things like Jenkins.
Speaker 1: And chef AH, the CICD pipeline tools, continuous integration, continuous
Speaker 1: delivery exactly.
Speaker 2: These are absolutely central to modern development and deployment processes.
Speaker 2: Jenkins in particular is often described, maybe slightly dramatically, as
Speaker 2: the almighty god of any infrastructure.
Speaker 1: Why so powerful because.
Speaker 2: It often has permissions to do everything. It can compile code,
Speaker 2: run automated tests, deploy applications straight to production. It can
Speaker 2: even create new U Kubernetes resources, or spin up entirely
Speaker 2: new AWS machines. It's the engine driving the whole development
Speaker 2: life cycle. So if you compromise Jenkins, you potentially own everything.
Speaker 2: By identifying these Jenkins instances, the next logical step for
Speaker 2: the attacker was clear, pay in an infrastructure management tool,
Speaker 2: take control of the God machine.
Speaker 1: Right. How did they manage to gain access to these
Speaker 1: incredibly powerful automation tools. That sounds like it should be
Speaker 1: locked down.
Speaker 2: Tight It should be, But they got creative. They leveraged
Speaker 2: their existing GitHub token, the one they'd previously obtained via
Speaker 2: that Kubernetes secret.
Speaker 1: Ah reusing credentials found earlier.
Speaker 2: Exactly, they used it to list mxr AD's private repositories
Speaker 2: on GitHub this time, and there they found a repo
Speaker 2: named cookbook mextrads jenkins.
Speaker 1: G cookbook often means CHEF right, the configuration.
Speaker 2: Management tool that's the strong hint. Yes, CHEF uses recipes
Speaker 2: collected in cookbooks to configure servers. They then discovered that
Speaker 2: certain AWSAPI calls specifically describe instances which are often overlooked
Speaker 2: by security teams because they seem informational, could sometimes expose
Speaker 2: the user data scripts on running EC two instances. Remember
Speaker 2: those boot up.
Speaker 1: Scripts, the ones that sometimes contained secrets yep.
Speaker 2: And these scripts, maybe used for initial bootstrapping of a
Speaker 2: CHEF managed server, could sometimes contain CHEF private keys.
Speaker 1: Oh wow, so the key needed to authenticate to the
Speaker 1: CHEF server was just sitting in the user data of
Speaker 1: a running.
Speaker 2: Instance in this scenario, Yes, a major oversight. This allowed
Speaker 2: the attacker to register a new malicious machine with the
Speaker 2: CHEF server, pretending to be a legitimate node. Then, using
Speaker 2: the Knife tool Chef's command line interface, they could list
Speaker 2: all the CHEF cookbooks the server managed, including that crucial
Speaker 2: Jenkins CI one they saw on GitHub. They could now
Speaker 2: see exactly how Jenkins was configured and potentially find vulnerabilities
Speaker 2: or hard coded secrets within the chef recipes themselves.
Speaker 1: Incredible. It's like a chain reaction of compromises, each step
Speaker 1: enabling the next. What about serveralist functions like abus LAMB
Speaker 1: Are they vulnerable in similar ways?
Speaker 3: They are?
Speaker 2: Lambda functions, as the book describes them, are essentially glorified crontabs,
Speaker 2: small pieces of code that run on demand, triggered by events,
Speaker 2: without you needing to manage a full server.
Speaker 1: Very popular, and presumably they also need permissions to do
Speaker 1: things they do.
Speaker 2: They run with an assigned I and M role, just
Speaker 2: like EC two instances. The attackers found a function called
Speaker 2: lambda di pasinc. Its job was to process mxr AD's
Speaker 2: logs and send them over to a gretch Politico S
Speaker 2: three bucket, crossing that organizational boundary again. Now, a developer,
Speaker 2: maybe Kevin mentioned hypothetically, might have had his personal access
Speaker 2: denied to that gretch Politico bucket. But the attacker realized
Speaker 2: something crucial.
Speaker 1: Let me guess the lambda function's role had permission.
Speaker 2: You got it, the lambda's role the identity assigned to
Speaker 2: the function itself could access that foreign GP bucket the
Speaker 2: function needed it to do its job. This meant that
Speaker 2: the attacker could simply choose to register a new Lambda,
Speaker 2: assign it this new role, the one with cross account access,
Speaker 2: and execute whatever code we like.
Speaker 1: So they could essentially hijack the lamb as permissions to
Speaker 1: run their own code with access to the other companies
Speaker 1: as three bucket.
Speaker 2: Precisely taking over the lambda function meant taking over its
Speaker 2: privileges another powerful vector.
Speaker 1: Okay, this is dizzying in such a highly volatile cloud
Speaker 1: environment where applications and servers are constantly changing, maybe even
Speaker 1: automatically destroyed and recreated. How do you maintain persistence after
Speaker 1: gaining this kind of access. It seems like it would
Speaker 1: be incredibly difficult to stay hidden and keep your foothold.
Speaker 2: That's a major challenge for attackers. The book emphasizes the
Speaker 2: strategy of deploying multiple backdoors with different properties. Don't rely
Speaker 2: on just.
Speaker 1: One, diversify your persistence methods exactly.
Speaker 2: One effective method described is a stable back door using
Speaker 2: a tiny Alpine Docker image. Very lightweight, this container is
Speaker 2: designed to simply regularly beacon back home check in with
Speaker 2: the attacker C two server for commands and be cleverly
Speaker 2: hidden in plain sight.
Speaker 1: How do you hide it?
Speaker 3: Maybe by naming it.
Speaker 2: It's something innocuous, something that looks like a legitimate system
Speaker 2: component like Amazon today plug in essentials, something as sissiedmin
Speaker 2: might glance over. And because Kubernetes is designed to bring
Speaker 2: destroyed pods back to life based on its deployment configuration,
Speaker 2: if the backdoor container is part of that configuration, ensures
Speaker 2: continuous access even if the original compromised container is terminated
Speaker 2: or the node restarts.
Speaker 1: UH using the orchestrator's self healing feature against itself.
Speaker 2: Clever very and for even more stealth. Another back door
Speaker 2: might involve a simple crown job hidden on a less
Speaker 2: volatile system, or perhaps an even more subtle Docker container
Speaker 2: that does very little, just waits for a specific trigger
Speaker 2: layers of persistence.
Speaker 1: Okay, so persistence achieved. The deep dive then moves to
Speaker 1: a completely new target environment within gretsch Politico, a Spark cluster.
Speaker 1: What makes Spark such an interesting or perhaps uncharted target
Speaker 1: for a hacker.
Speaker 2: Well, Spark is a hugely popular framework for big data
Speaker 2: processing think large scale analytics, machine learning, but at the
Speaker 2: time the book was written. There are apparently almost no
Speaker 2: public hacking write ups or tools specifically targeting Spark clusters, so.
Speaker 1: It was uncharted waters for security researchers and attackers.
Speaker 2: Largely yes, which makes it interesting. The attacker first had
Speaker 2: to learn how Spark clusters actually work, understanding the roles
Speaker 2: of the master node, the worker nodes where calculations happen,
Speaker 2: and the driver program that coordinates it all. Then they
Speaker 2: figured out something really clutter by creating a malicious Spark application,
Speaker 2: a program submitted to the cluster for processing that included
Speaker 2: a subprocess pope and call hidden inside a standard Spark
Speaker 2: transformation like a math function.
Speaker 1: Wait, you can embed OS commands inside a data transformation.
Speaker 2: Apparently so in the setup. This allowed them to execute
Speaker 2: arbitrary commands on the Spark worker nodes whenever that part
Speaker 2: of the Spark job ran crucially without needing any direct
Speaker 2: logging credentials for those worker nodes.
Speaker 1: Wow, using the Big data engine itself to run commands remotely.
Speaker 2: Yeah, leveraging the system's own distribute computation functionality against itself.
Speaker 3: Very neat.
Speaker 1: And what was the ultimate prize unearthed within this compromise
Speaker 1: Spark cluster? What did they find There.
Speaker 2: They discovered that Gretsch Politico was using a tool called
Speaker 2: S three S to mount an S three bucket named
Speaker 2: gretch Notebooks locally onto their Spark cluster nodes. Like attaching
Speaker 2: a cloud drive directly to the system.
Speaker 1: Gretch Notebooks sounds like data science territory exactly.
Speaker 2: This bucket was full of dot IPMD files. That's the
Speaker 2: file extension for Jupiter notebooks.
Speaker 1: The interactive coding environments data scientists love.
Speaker 3: The very same.
Speaker 2: And inside this bucket, nested in a directory called exports twenty,
Speaker 2: they found plainold dot CSV files COMMA separated value file.
Speaker 1: Ah raw data exports. So what exactly was contained in
Speaker 1: those CSV files?
Speaker 2: The mother load pretty close A list of clients, all right,
Speaker 2: as the book puts it, and not just current customers,
Speaker 2: but perspective ones too, complete with incredibly detailed information. We're
Speaker 2: talking annual revenue, last contact date, initial contact, country, account manager,
Speaker 2: zip code service purchased.
Speaker 1: Good grief. It's highly sensitive business intelligence just sitting in
Speaker 1: csvs in an S three bucket mounted to.
Speaker 2: Spark YEP A gold mine of strategic data.
Speaker 1: Okay, Beyond these individual files and databases scattered across different services,
Speaker 1: was there a single junction, like a central hub where
Speaker 1: all of Gretch Politico's most valuable data might converge.
Speaker 2: Yes, and this is where it gets truly deeply unsettling.
Speaker 2: By exploiting an im list policies permission, they gained somewhere along.
Speaker 1: The way that lets you list all the permission policies
Speaker 1: in the AWS account.
Speaker 3: Correct.
Speaker 2: They were scanning through policies looking for excessive permissions, and
Speaker 2: they discovered one named run deck monopolicy. Run Deck is
Speaker 2: another automation tool. This IAM policy granted close to full
Speaker 2: admin privileges over AWS, almost god mode within the AWS account. Oops,
Speaker 2: big oops, including qrickly Redshift permissions full control over Amazon.
Speaker 1: Redshift Redshift, being aws's cloud data warehouse service right designed
Speaker 1: for massive analytics.
Speaker 2: Precisely, this permission led them directly to several Redshift clusters,
Speaker 2: including ones ominously named BI likely for business intelligence and finance.
Speaker 1: Oh boy, what kind of sensitive, perhaps even chilling data
Speaker 1: was exposed in these central Redshift data warehouses?
Speaker 2: Well, As the hacker narrator notes, nothing beats a good
Speaker 2: old fashioned sequel database where we can query enjoining data
Speaker 2: to our hearts content. This Redshift cluster, particularly the buy one,
Speaker 2: was indeed the junction of almost every data input poured
Speaker 2: into gretch Politico's infrastructure. Everything ended up here.
Speaker 1: So what do they find.
Speaker 2: They found full online activity logs of individuals, websites, visited,
Speaker 2: ads clicked. They found links to social media profiles. They
Speaker 2: found incredibly granular data segments used to profile people with
Speaker 2: names like politics, Lane left, or health chronicle pain, and
Speaker 2: even look alike segments profiles of people who were statistically
Speaker 2: similar to existing customers or targets. The book details the
Speaker 2: profile of one specific individual, Francistima, as an example. It
Speaker 2: included his device type, his last known location derived from
Speaker 2: mobile data, a link to his Facebook profile, his inferred interests,
Speaker 2: and even a calculated character map enumerting his level of influence, impulse,
Speaker 2: and ad interaction how likely he was to click, buy,
Speaker 2: or share based on his profile.
Speaker 1: That level of detail is well, it's the core product
Speaker 1: of a company like that, but seeing it laid bare
Speaker 1: is quite something, incredibly detailed and yes, frankly chilling.
Speaker 2: It really shows the sheer scope and granularity of data
Speaker 2: collection and analysis happening in these systems.
Speaker 1: Okay, they've got the core data, the business intelligence, the
Speaker 1: customer profiles. What was the absolute final step in this
Speaker 1: deep dive, the final piece of the puzzle for the attackers.
Speaker 2: Hacking company emails, getting into the internal communications.
Speaker 1: The crown jewels for corporate espionage. Often they manage that.
Speaker 2: Again, leveraging previous fines, they went back to Gethub, searching
Speaker 2: specifically for gretch politico repositories related to IT or GAPS
Speaker 2: short for Google Apps now Google Workspace. They found a
Speaker 2: private repository named it gress suite apps looked like code
Speaker 2: for internal tools managing their Google Workspace setup.
Speaker 1: Automating user creation, maybe group management, that kind of thing exactly.
Speaker 2: While no direct passwords were found in the code, this time,
Speaker 2: they identified that this internal application used a Google Service
Speaker 2: account to perform its administrative actions. And where was the
Speaker 2: key for this powerful service account stored in AWS Secrets Manager,
Speaker 2: another AWS service specifically for storing secrets securely.
Speaker 1: Ah But they already had broad AWS access by this
Speaker 1: point right, including possibly access to Secrets Manager.
Speaker 2: Precisely, the run deck monopolicy likely gave them the necessary permission, So.
Speaker 1: Once they had that Google Service account key, they.
Speaker 2: Retrieved the key file from AWS Secrets Manager. Now, this key,
Speaker 2: when combined with a critical Google workspace setting called domain
Speaker 2: wide delegation privileges.
Speaker 1: What was it that too?
Speaker 2: It's a very powerful setting. It allows a service account
Speaker 2: to act on behalf of any user within the entire
Speaker 2: Google Workspace domain if authorized by an admin. So the
Speaker 2: attackers use the service account key enabled domain wide delegation
Speaker 2: and then told it to impersonate a known super admin
Speaker 2: email address Adminute at gretchpolitico dot com so.
Speaker 1: They could act as the itadmin programmatically.
Speaker 2: Yes, this allowed them to use Google's APIs to programmatically
Speaker 2: create brand new users in Gretch Politico's corporate directory. They
Speaker 2: effectively created a new user Henniel at gretchpolitico dot com,
Speaker 2: completely out of finair, potentially with high privileges.
Speaker 1: Giving themselves a legitimate looking account inside the company's Google workspace.
Speaker 3: Exactly.
Speaker 2: This achieved admin access to GP's corporate directory and by extension,
Speaker 2: potentially full access to all company Gmail inboxes and Google
Speaker 2: Drive files, depending on the exact permissions granted. The book
Speaker 2: even concludes by sharing a redacted snippet purported to be
Speaker 2: from the CEO's emails revealing sensitive internal discussions about political
Speaker 2: stratgy like going after his public image and potentially making
Speaker 2: up a story.
Speaker 1: Wow, just wow. What an absolutely incredible and frankly terrifying
Speaker 1: journey we've just traced. We've seen how attackers no longer
Speaker 1: just target individual machines, but the very fabric the control
Speaker 1: plane of cloud infrastructure. From meticulously setting up anonymous operations,
Speaker 1: conducting incredibly deep reconnaissance, to exploiting subtle, nuanced misconfigurations and
Speaker 1: complex services like S three and Kubernetes. Yeah, all the
Speaker 1: way to stealing vast amounts of highly personalized data and
Speaker 1: gaining complete control over sensitive company emails. It's the whole
Speaker 1: new ballgame, it really is.
Speaker 2: What this deep dog highlights so powerfully, I think is
Speaker 2: that the broad adoption and maybe the generalization of cloud
Speaker 2: computing is a truly disruptive event in cybersecurity, a paradigm shift.
Speaker 2: The focus has shifted dramatically away from individual machines towards
Speaker 2: the underlying infrastructure, the APIs, the orchestration layers, and away
Speaker 2: from traditional network perimeters towards identity, API, call and service
Speaker 2: accounts as the new boundaries to defend.
Speaker 1: The old castles and moats model just doesn't apply cleanly anymore,
Speaker 1: not in.
Speaker 3: The same way.
Speaker 2: No, the old tricks, as we discussed are rapidly becoming
Speaker 2: obsolete or at least less effective on their own, and new,
Speaker 2: far more sophisticated multi stage techniques targeting the cloud specific
Speaker 2: architecture are emerging as the norm.
Speaker 1: It's such a powerful reminder that security in the cloud
Speaker 1: isn't just about firewalls and antivirus anymore, is it. It's
Speaker 1: about deeply understanding how every single component, every automation tool
Speaker 1: like Jenkins or Chef, every LAMB to function, and every
Speaker 1: single configuration choice interacts creates a potential loophole. It's about
Speaker 1: the interconnectedness, the layers upon layers of permissions, and the
Speaker 1: sheer speed of continuous deployment. It's incredibly complex.
Speaker 2: It is complex, and for you, the learner listening in
Speaker 2: this offers a truly unique perspective. I hope it demonstrates
Speaker 2: that knowledge is most valuable when it's not just theoretical,
Speaker 2: but understood in context and applied. It hopefully encourages critical
Speaker 2: thinking about the complex digital world that surrounds us all,
Speaker 2: a world that is becoming increasingly abstract and reliant on
Speaker 2: these vast, intricate cloud systems.
Speaker 1: So what does this all mean for you? As you
Speaker 1: navigate this world, a world increasingly reliant on the cloud
Speaker 1: for everything from work to entertainment to social connection. It
Speaker 1: means that understanding the attacker's mindset, that ghost minds that
Speaker 1: we explored is no longer just for the security professionals
Speaker 1: in the trenches. It's becoming essential for anyone who interacts
Speaker 1: with technology, build software, or relies on digital services, And
Speaker 1: it really raises a profound, perhaps unsettling question for all
Speaker 1: of us. Are the systems we rely on every day
Speaker 1: truly as secure as we believe, or are there hidden cracks,
Speaker 1: subtle misconfigurations waiting just beneath the surface, ready to be
Speaker 1: exploited by a subtle touch, a forgotten permission, or a
Speaker 1: perfectly aimed API request. Something for you to consider as
Speaker 1: you go about your digital day.