Beyond the Perimeter: Inside the Cloud Threat Landscape

Welcome to this deep dive.

Today, our mission is to decode a really fascinating

and, well, frankly, a pretty sobering document.

It's the 2025 Cloud threat hunting

in defense landscape report.

Yeah, it's quite the read.

It really is.

This was put together by Recorded Futures Insight Group,

and we've got this massive stack of their research

right here in front of us.

And our goal for you today is to help you understand

exactly how cyber criminals are revolving,

because they are really moving away

from traditional brute force hacking.

Right.

Instead, they're doing something much more insidious there,

weaponizing the Clouds, very own features against us.

But before we jump into all that,

a huge thank you to our sponsors right at the top.

This deep dive is brought to you by www.suzomarketplace.com

and www.breach.com we literally couldn't do this without them.

Absolutely.

And, you know, it's great to be diving into this with you today.

Honestly, this report is absolute critical

for anyone operating in a modern digital environment.

But to really understand what's happening,

we have to kind of set the stage for you.

The world of cloud computing is, at this point,

highly mature in terms of adoption.

I mean, practically every organization is using it.

But, and this is the critical gap the report highlights,

we are still surprisingly early in figuring out

how to secure it properly.

Like the security is lagging way behind the adoption.

Exactly.

Organizations are just rushing to put their core systems

and sensitive data online.

But they often lack the in-house expertise

to architect these incredibly complex environments securely.

So this massive gap between widespread adoption

and secure implementation has essentially created

a highly lucrative playground for threat actors.

Okay, let's unpack this.

Starting with what the report calls the front door,

which is exploitation and misconfiguration.

And what really jumps out at me from the sources

is how internet exposed services

are just sitting there like low hanging fruit.

We're talking about things like VPN portals,

application delivery controllers, monitoring dashboards

that you might even use in your own day-to-day work.

Yeah, and to understand why this is happening,

you have to look at how a modern cloud environment is built,

as organizations bolt on more and more third-party technologies

to the perimeter of their cloud

just to make things work smoothly.

Their attack surface naturally grows.

It's rarely a fundamental flaw

in the core cloud infrastructure itself.

Like AWS or Azure aren't just broken.

It's almost always about vulnerable parameters

and simple configuration drift.

Imagine a company spitting up a quick monitoring dashboard

for a temporary project.

And they just forget about it.

Exactly.

They forget to patch it a month later

or they leave the default settings on.

And suddenly, that forgotten dashboard

is the wide open window the attacker uses to get into the house.

The report specifically highlights a vulnerability in Grafana,

which is a super popular monitoring dashboard.

I know a lot of our listeners

probably have Grafana dashboards up on their screens right now.

The specific vulnerability is CVE 2021 43798.

That's actually a pretty old vulnerability at this point,

but attackers are apparently still having a field day with it.

They absolutely are.

This specific Grafana flaw

allows for what's called path traversal.

Think of it like a hotel guest

who realizes their room key accidentally unlocks the doors

to the restricted staff areas and the manager's office.

It essentially lets attackers read arbitrary files

on the server that they should never have access to.

But what's truly alarming here is the methodology.

Thread actors aren't just targeting

one specific company at a time anymore.

They're integrating these older,

resurgent vulnerabilities into automated scanning frameworks.

Wait, let me pause you there.

When you say automated scanning frameworks,

you mean they're just casting a giant net?

Precisely.

They scan massive swaths of public cloud IP space.

Just indiscriminately looking

for unpatched instances of Grafana.

Once their automated scanner finds one,

they immediately steal the credential material

from those restricted files

and use it to pivot deeper into the underlying cloud workloads.

It's just a numbers game.

Exactly.

A numbers game and it's highly effective.

That is remarkably insidious.

But as clever as that automated scanning is,

it doesn't even compare to this other attack

that report details.

It's called the WHOAMI attack.

Oh, this one is fascinating.

You sort of really caught my attention

because it targets AWS environments.

And it essentially uses human psychology

and infrastructure automation against the victim.

So basically attackers craft malicious Amazon machine images

or AMIs.

Right.

And for those listening who might not

build cloud servers every day and AMIs,

basically the cookie cutter template

used to create a virtual server in the cloud.

Attackers embed these templates with backdoors

or data exploration mechanisms.

But here's the trick.

They give them names that look completely legitimate.

Like a Ubuntu focal 20.04 AMD 64 server

with a wild card at the end.

And that naming convention is the crux of the trap.

This attacks specifically targets infrastructure

as co-tools, like Terraform or even just simple

automated deployment scripts.

Many developers write their scripts

to simply ask the cloud provider for the latest version

of an Ubuntu image.

Just grab the newest one.

Right.

But if they don't explicitly verify

the owner ID of that image to make sure

it actually came from canonical,

the makers of Ubuntu the automation tool

will blindly pull the attackers newly published,

identically named AMI.

Because it technically registers

as the most recent version.

So if I'm understanding this correctly,

it's like setting up a recurring delivery

for your groceries.

But a thief registers a fake grocery store

with the exact same name updates their inventory

one second before your order processes

and your automated system just buys from them instead.

That is a perfect analogy.

The victim's own automated systems literally

install the attackers back door directly

into their pristine infrastructure.

They do the heavy lifting for the threat actor.

It's the ultimate Trojan horse built by the victim's own

automated systems.

It just goes to show how easy it is to develop

architectural blind spots in the cloud.

Which, by the way, is exactly why our sponsor,

www.sizomarketplace.com is such a great resource

for security teams trying to navigate these complexities

right now.

Because once these attackers slip past those blind

spots at the front door, their strategy completely changes.

Here's where it gets really interesting.

Once the attackers are inside, they

aren't just breaking into steel data anymore.

They are setting up shop.

They're using the victim's own cloud infrastructure

to host malware, run command and control operations,

and launch attacks on other targets.

What's fascinating here is the massive shift

we're seeing in 2025 regarding artificial intelligence.

According to the Insect Group report,

threat actors are now explicitly targeting cloud-based,

large language models, or LLMs and machine learning

services.

And why are they doing that?

The reasoning is brilliant in a very dark way.

If an attacker uses a compromised cloud

account to send malicious traffic,

and they route that traffic through a popular AI service,

becomes incredibly difficult for traditional security

products to detect.

Because it just looks like normal traffic.

Exactly.

The traffic was perfectly benign because interacting

with cloud-based LLMs through APIs

is exactly what normal, legitimate employees

are doing all day long now.

It blends right in.

It's the perfect camouflage.

The report outlines an attack called Operation Salmon

Slalom that illustrates this perfectly.

This was a multi-stage cyber attack targeting

industrial organizations.

We're talking manufacturing, telecommunications,

energy sectors all across the Asia-Pacific region.

The attackers delivered a backdoor called Fatalad,

but they didn't use sketchy servers hidden on the dark web

to host their payloads and command configurations.

Instead, they used UDOW Cloud Notes, which

is a completely legitimate note-taking app,

and 10 cents MyQ Cloud Content Delivery Network.

Essentially hidden plain sight.

Right.

Their malicious network traffic just

blended seamlessly into the everyday regular business

operations of the region.

If a security analyst is looking at the network logs,

seeing traffic going to a popular note-taking app

or a massive content delivery network

doesn't set off any alarm bells.

It's a remarkable evolution in operational security

for threat actors.

By abusing legitimate, high-reputation cloud services,

they completely bypass reputation-based filtering

and traditional network firewalls.

But to execute these sophisticated abuses,

they first need the right level of access, which

brings us to the next major finding in the report.

The critical role of identity.

Passers simply aren't enough anymore.

The report emphasizes that attackers

are now hunting for tokens, API keys,

and multi-factor authentication codes.

They don't just want to password.

They want the keys to the kingdom.

If we connect this to the bigger picture,

we see that modern corporate environments

are rarely just on-premise in a physical office,

or purely in the cloud.

They are hybrid.

You have local networks talking to cloud servers constantly.

Right.

They're interconnected.

Yes.

And threat actors systematically pivot

through these hybrid identity structures.

They might start by compromising a standard,

directory synchronized account on a local workstation,

maybe through a phishing email.

And then they ride that trusted identity

straight up into the cloud environment.

From there, they target non-human identities,

like service principles or executive accounts

to gain tenant-wide administrative control.

The human element in this is what really stands out to me.

Take the scattered spider group, for example.

The report breaks down an intrusion

they executed against a logistics firm.

They didn't just brute force a server.

They researched the chief financial officer online.

Social engineering edits finest.

Totally.

They found the CFO's date of birth

and bits of their social security number

publicly available through various day brokers.

They used that personal data to trick the company's portal

and bypass the initial verification.

And this is where the persistence comes in.

When the multifactor authentication eventually blocked them,

they didn't just give up and move on.

No, they persistently targeted the IT help desk.

They use social engineering, pretending to be the CFO,

to get the help desk to reset things.

They attacked the privileged password vaults

to force their way in.

They use social engineering to hijack the identity itself

rather than trying to crack the cryptography.

And that's a localized targeted example.

But when you look at the DPRK Bybit Heist,

detailed in the report, you see how devastating

stolen cloud identities can be at a massive scale.

North Korean threat actors managed to steal 400,000 Ethereum.

That's just wild.

The methodology is incredibly sophisticated.

They first compromised a developer

for a company called Safe Wallet.

From that single developer's machine,

they gained authenticated access to Safe Wallet's AWS

environment.

They then navigated to the S3 storage bucket.

And for those unfamiliar,

an S3 bucket is essentially just a cloud folder

where you store files.

In this case, it hosted the statically build

next.js front end of the wallet application.

So they found the folder holding the actual visual code

for the website interface.

Exactly.

They downloaded the actual code for that front end interface,

the part the user interacts with.

They modified that code to alter the destination addresses

for cryptocurrency transfers, and then re-uploaded the modified

code back to the cloud bucket.

This is the part that is just so clever in a terrible way.

The back end cryptography, the actual blockchain

signature securing the Ethereum, they all

look totally fine to the security systems.

But the user interface, the literal screen

that the financial approvers at Bybit

were looking at when they hit approve,

was silently lying to them.

It showed the correct address on the screen,

but the code underneath was routing the money to North Korea.

The interface was hijacked using stolen cloud keys.

Precisely.

They didn't break the blockchain cryptography,

which is mathematically near impossible.

They bypassed it entirely by compromising

the cloud environment that served the interface.

It highlights how valid credentials allow attackers

to masquerade as trusted entities.

And once they have that trusted status,

the damage they can do is catastrophic.

Which is exactly why understanding

these advanced identity-based threats is so vital.

And why we always recommend checking out our sponsor,

www.breach.com to help stay ahead of these exact scenarios

and keep your identity secure.

Because the way threat actors use this access

is changing rapidly, especially when it comes to extortion.

So what does this all mean for the future of ransomware?

The report outlines a pretty stark evolution here.

We're seeing threat actors actively abandoning

traditional ransomware malware binaries.

In the past, attackers had to drop a piece of malicious software

onto a server to encrypt the files.

That malware could be detected by anti-virus software

or endpoint detection systems.

Now they're adopting a strategy called living off the land.

I've heard that phrase before.

How does it apply to the cloud specifically?

Think of it like a burglar who doesn't bother bringing

a crowbar or their own lock picks to rob your house.

Instead, they just use the security systems master control

panel that you left unlocked on the kitchen counter.

Because these attackers have already

compromised an administrative cloud identity,

they don't need to deploy malware.

They just use the cloud provider's own built-in application

programming interfaces, the APIs, and the native management

consoles.

They use the cloud against itself.

Exactly right.

They use legitimate administrative commands

to change the encryption settings on storage buckets,

locking the organization out of its own data.

They rotate or destroy the cryptographic key material,

making the data unreadable.

And they mass-delete the organization's cloud backups.

The cloud's own management tools, the very things

designed to keep the data safe and organized,

are becoming the weapons used to hold the data hostage.

It requires no custom malware, making it

incredibly difficult to detect until the damage is already

done.

It's extortion by administration.

You're just doing administrative tasks,

but with malicious intent.

And as if that isn't difficult enough to defend against,

the INSIC Group Report introduces a threat vector

that they ranked as a five the highest possible score,

severe for cost of impact.

It's called third party compromise.

To me, this is the most concerning part

of the entire report.

It's when the attack doesn't come from a phishing email

or an open port on your own network,

but straight through a vendor you already inherently trust.

This raises an important question for every organization

and, honestly, for anyone listening right now.

How do you verify the behavior of systems you inherently

trust?

When an organization integrates a software

as a service platform, an identity provider,

or a continuous integration and continuous deployment

pipeline, a CI-CD pipeline, they grant that third party

deep permissions into their own cloud tenant.

If an attacker compromises that third party vendor,

the attacker inherently inherits all of those permissions

across every single one of the vendor's customers.

The scale of that is what's so daunting.

You compromise one vendor.

You get access to 1,000 companies.

The report uses the Oracle E business suite

attacks by the Klope ransomware group

as a prime example of this.

Klope exploited a zero-day vulnerability

inside the Oracle EBS platform.

Because of that one flaw at the vendor level,

massive companies like Schneider Electric and Logitech

suffered severe data breaches and the kicker.

Their own internal networks were perfectly secure.

They'd be nothing wrong on their end.

Exactly.

The breach happened entirely within the trusted Oracle

vendor platform, and the attackers just reached right

through that trusted connection to steal the data.

It is the digital equivalent of an attacker stealing

the master key from the security guard company,

rather than trying to pick the lock on your individual front

door.

And it goes even deeper into the supply chain

than just saws applications.

The report highlights instances of package abuse,

where attackers poison the actual code libraries

that developers use to build their software.

Yes, the malicious NPM packages on GitHub.

This was fascinating.

There was an attacker, a threat actor,

uploaded a package that looked like a standard,

helpful development tool.

But hidden inside, it had opus-cated scripts

designed to check its environment.

It literally looked around to see,

am I running inside GitHub Actions?

Which is a popular CI-CD automation tool.

It's environmentally aware.

Exactly.

If it realized it was just being tested

on a developer's local laptop, it did nothing.

But if it realized it was inside an automated built pipeline,

it immediately stole AES encryption keys and built job tokens

and silently exfiltrated them to a custom domain

controlled by the attacker.

Any developer who downloaded that package inadvertently

handed over the keys to their entire deployment process.

The real risk here is that the malicious activity

arrives pre-trusted.

It comes in through standard integrations

and automated deployments.

Your systems assume it's supposed to be there.

It makes distinguishing a catastrophic breach

from a legitimate vendor update incredibly difficult,

without incredibly robust monitoring

and strict boundary controls.

OK, I know this can feel completely overwhelming

to you listening right now.

It feels like the attackers are everywhere.

In the fake server images, in the trusted apps,

in the AI models we use every day.

So let's bring it back down to Earth for a minute.

Based on the report, how can organizations actually

defend their cloud environments

against this level of sophistication?

What's the practical takeaway for the listener?

While the threats are highly advanced,

the mitigation still rely on rigorous security fundamentals,

applied specifically to the cloud context.

First, you must maintain a strict, continuously updated

inventory of all public facing services.

You cannot protect what you don't know as exposed.

If you have an old Drafana dashboard out there,

you need to know about it today.

Makes sense.

Second, restrict any direct internet exposure

of administrative interfaces.

They shouldn't just be sitting on the public web.

They should always be hidden behind a VPN,

or ideally a zero-trust network access architecture,

where you have to prove your identity and device health

before you even see the login screen.

Basically, close the front door and pull the blinds.

Exactly, make them invisible to the automated scanners.

Third, when it comes to the supply chain

and those malicious packages we discussed,

you have to harden your CICD pipelines.

This means strictly enforcing multifactor authentication

for administrators and requiring cryptographic signing

for all build artifacts so you can verify their provenance.

You need to know exactly who wrote the code

and that it hasn't been tampered with.

Right.

Finally, and perhaps most importantly,

given the third-party risks we discussed,

you must require formal, rigorous approval processes

for any new third-party cloud applications.

You have to ensure they're only granted

the absolute principle of least privilege.

Don't give an app tenant-wide access to your entire cloud

if it only needs to read one specific database.

Limit the access to limit the damage.

It's about reducing the blast radius

if something does go wrong.

Well, that brings us to the end of today's mission.

Thank you for joining us on this deep dive

into the 2025 cloud threat hunting and defense landscape.

It's a highly complex world out there,

but understanding the playbook of these threat actors

is the first step in beating them.

One final, massive thank you to our sponsors,

www.scizomarketplace.com and www.breach.com

for making this deep dive possible.

We appreciate their support and your time listening today.

If threat actors are moving away

from deploying recognizable malware,

and instead simply living off the land

by using our own native cloud APIs

and trusted third-party integrations against us,

at what point does perfectly legitimate administrative behavior

become indistinguishable from a catastrophic breach?

As we secure the perimeter,

will the future of cybersecurity rely less

on blocking bad software

and entirely on mathematically profiling human intent?