fwd:cloudsec Europe 2025

While achieving perfect cloud configuration is a laudable goal, it's often a Sisyphean task. So why has the industry predominantly defined Cloud Security success through the narrow lens of posture perfection?
Drawing from Daniel Kahneman's Nobel Prize-winning work, we’ll explore how 'System 1' (fast, intuitive thinking) makes 'posture perfect' feel right, yet traps us on a hamster wheel, consuming resources and distracting from addressing cloud environments holistically. We'll examine why shifting to 'System 2' (slow, systematic thinking) is so challenging.
To further understand why the industry is fixated on configuration perfection, we’ll look at how it's reinforced: examining the role of misleading metrics that bolster our cognitive biases (as highlighted by Kahneman), and how vendor offerings can prioritize easily measured 'endorphin hits' over genuine risk reduction.
The session concludes with strategies for codifying slow and effortful thinking into reusable frameworks, short-cuting the effort of systematic thinking to move the Cloud Security industry beyond configuration management. We’ll learn to be skeptical of any single-pronged approach, utilize well-established frameworks, and distribute the responsibility for security in the cloud across the Security Organization.

Throughout the past year, we’ve observed a coordinated and extensive effort by threat actors to exploit the free tier offerings of cloud providers. This presentation provides an in-depth analysis of the TTPs (tactics, techniques, and procedures) observed in the wild, emphasizing how adversaries systematically exploit free-tier resources, especially those with GPU or ML capabilities, for profit.

We’ll walk through the end-to-end attack lifecycle, from automated cloud account generation using browser extensions and iMacros scripts to validation, infrastructure deployment, and resale on underground marketplaces. We’ll also discuss the broader monetization ecosystem, highlighting how these actors integrate with e-commerce platforms to scale their operations.

The session will include real-world indicators, case study elements, and tooling details to help defenders recognize and disrupt similar activities in their own environments. Attendees will leave with a clearer understanding of the underground economy built around cloud abuse—and actionable insights to defend against it.

Microsoft claims "Azure Arc is a bridge that extends the Azure platform to help you build applications and services with the flexibility to run across datacenters, at the edge, and in multicloud environments." While Azure Arc is not installed by default, Microsoft is pushing the service heavily via numerous channels. Vulnerabilities in products which aim to integrate on-premise and cloud infrastructure could open the doors for lateral movement between the two, and increase the blast radius of a given breach. While Azure Arc makes it easier to use the power of Azure within on-premise infrastructure, it also makes life easier for threat actors. So, what if we find ourselves with a foothold on a server with Azure Arc Installed?

In this talk I will cover my experiences investigating the Azure Arc Agent. Under the right circumstances, exploiting Azure Arc would allow pivoting from an on-premise server to the cloud. This presentation will consist of a high-level introduction of Azure Arc, its configuration, the research path and other observations. We will look at a chain of misconfigurations used to hijack a server enrolled in one tenant to be temporarily enrolled in another, attacker-controlled tenant to escalate privileges on the local host. The talk will highlight as to why security teams, cloud architects and system administrators should pay attention to their Azure Arc configuration and implement potential detection capabilities for these exploits.

While cloud environments are now foundational to modern business, much of what is published about cloud threats remains theoretical, vague, or lacking the rigor found in traditional cyber threat intelligence (CTI) reporting. This talk offers a frank assessment of the current state of cloud threats, grounded in open-source reporting from H1 2025 across a dozen sources – from major vendors to independent researchers and niche security firms.

We’ll unpack the key attack techniques actually observed in the wild this year, contrast them with the narratives often emphasized in public reporting, and highlight both the gaps that leave defenders without a clear threat model and the progress that has been made – from improved detection logic to standout examples of threat reporting that meaningfully guide defenders.

By surfacing what’s working, we can better understand how to scale those practices across the industry, while also identifying patterns of reporting or analysis that should be improved or avoided. We’ll also explore why these gaps persist, ranging from marketing-driven narratives and limited telemetry to the overly broad use of the term “cloud” and the chronic underreporting of incidents.

Drawing on real-world experience from within the threat intelligence community, this talk proposes actionable improvements: a more structured language for cloud-specific threats, practices borrowed from traditional CTI, and a call for greater transparency and nuance in how we talk about adversary behavior in the cloud.

Detection engineering in the cloud is often hobbled by poor telemetry documentation and vague, static log-to-MITRE mappings. In this talk, we will share Cloudots - a research system that shifts this paradigm by empirically constructing and maintaining a technical knowledge layer over cloud telemetry.

Cloudots runs autonomous AI agents to simulate adversarial scenarios on AWS, Azure, and GCP. Our agents take high-level objectives like “exfiltrate data” or “achieve persistence via IAM abuse,” and break them down into low-level API call graphs through goal-oriented planning and domain specific introspection. Each simulation executes within sandbox cloud accounts, utilizing actual APIs (no mocks) gathering full telemetry, timing behavior, and resource transitions. Afterwards, the system observes which telemetries are actually being triggered and are relevant to detect the attack.

The result is a structured, queryable knowledgebase that maps specific log entries (CloudTrail, VPC Flow Logs, GCP Audit Logs, etc.) to MITRE tactics and techniques, with context on signal fidelity, timing, and trigger conditions. In addition to that, we wrapped this knowledgebase with an MCP and then built a chat interface so analysts can ask cloud security questions in natural language, and the results are relevant and backed by the Cloudots knowledgebase.

In this session, we’ll share architecture lessons, failure modes, signal insights across platforms, and practical use cases like coverage validation and detection prioritization. We are hoping to make the audience and cloud security community rethink how we can leverage AI to empower cloud defenders, because attackers are already using it to their advantage.

As a consumer of releases of open-source tools hosted on GitHub (you are one if you e.g. use terraform to deploy your cloud infrastructure), have you ever wondered if a release may include malicious code? And as a maintainer of such releases, have you ever wondered "How might I sneak some malicious code into my GitHub releases"?

I have done both, since as I am not only a maintainer of an (openly) malicious terraform provider, but also a red teamer with a focus on cloud and CI/CD, and thus stealth. So I sat down and explored how a malicious insider could manipulate their releases without ever touching the application code directly. I wanted to find ways to do that with only minimal changes to the build pipeline that is defined in a GitHub Action that do not obviously look suspicious.

Over time I identified three "classes" of attacks, all targeting my own build pipelines that were creating releases. During the talk I will walk you through all three of them and show five examples on how do execute them stealthily to create inconspicuous releases on GitHub. By showing the attacks I hope to spark some questions about the security of your own cloud infrastructure deployment pipelines that rely on third-party releases (like e.g. terraform providers). The good news for defenders: for (almost) all of the attack vectors I am able to point out ideas on detection and thus mitigation if you want to take a closer look at your own supply chain.

In today's technology economy, people frequently move jobs before getting to experience the long-term consequences (both good and bad) of the decisions they made. In contrast, I spent over a decade at my previous company both building out their AWS footprint as well as building internal software for business users on top of that AWS footprint. This gave me perspectives on both sides of the fence -- both wanting to ensure our AWS account fleet was well managed and secure while also needing to deliver value to the business using it. In this talk, I'll offer some reflections from both perspectives about the good and the bad of decisions I made as our account fleet grew from a single AWS lab account into hundreds of AWS accounts supporting different business units.

In this talk, we unveil attack techniques and vulnerabilities —SyncJacking and SoftMatching Abuse—that exploit inherent weaknesses in Microsoft Entra Connect’s synchronization mechanisms to hijack or impersonate cloud identities in hybrid environments. These techniques abuse architectural trust assumptions between Active Directory and Microsoft Entra ID (formerly Azure AD), enabling attackers with limited access to gain unauthorized control over cloud accounts.

SyncJacking, a vulnerability in the Hard Matching process, allows an attacker to forcibly associate a cloud-only identity with an on-premises account under their control—without modifying source anchors or triggering alerts. This stealthy takeover method was confirmed as a valid security issue by Microsoft’s MSRC, which is actively working on a fix.

SoftMatching Abuse targets the second half of the Entra Connect synchronization model. By exploiting overlooked weaknesses in the Soft Matching process, attackers can maliciously link accounts, revive orphaned identities, and persist across tenants with minimal footprint.

This session will feature live demonstrations and practical tooling to showcase how both vulnerabilities can be leveraged end-to-end—from reconnaissance to exploitation and privilege escalation. Attendees will gain both red team insights and defensive strategies for securing hybrid identity synchronization.

Storage access is one of the most critical signals in cloud environments, especially as organizations shift more sensitive workloads to S3, Blob, and GCS buckets. It seems simple: log who accessed what and when, and you’re good to go. But once you start digging into the actual DataEvents across AWS, Azure, and GCP, the reality gets messy fast.

Each cloud tells a different story. AWS provides deep operational detail, Azure logs vary wildly based on the type of token used, and GCP favors identity over object context. These differences aren’t just cosmetic, they shape how you investigate incidents, detect threats, and even reason about risk. For example, in Azure, the main threat scenario is leaked credentials (e.g., storage‐account keys or SAS tokens), whereas in AWS and GCP, the emphasis shifts to detecting activity that stems from compromised user or role identities. Then there's the scale. Storage activity generates an overwhelming amount of logs, and parsing real signals from routine access isn't trivial. Building efficient detections for that? Even harder.

In this talk, we’ll walk through the real-world challenges of working with storage data logs across cloud providers, the inconsistencies, the blind spots, and the assumptions that break at scale. We’ll share how we tackled these problems and aggregated the logs to build a scalable, signal-driven detection approach that cuts through the noise and surfaces what matters most.

Azure’s Role-Based Access Control (RBAC) model simplifies identity and permissions management by offering predefined, built-in roles. However, even seemingly trusted built-in roles can introduce unexpected risks.

In this talk, we’ll examine multiple over-privileged Azure built-in roles that grant excessive permissions beyond their intended scope, which enable attackers to enumerate assets, map attack paths, leak exposed secrets, and access critical configurations. Additionally, we’ll discuss a newly discovered Azure API vulnerability that allows attackers to leak the key for the Azure VPN service. We’ll dive into blackbox vulnerability research in Azure, and demonstrate how combining these issues can lead to cloud infrastructure breaches and unauthorized access to on-premise networks via the corporate VPN, posing serious consequences for organizations.

The session concludes with actionable strategies to fortify identity security, ensuring that security teams maintain robust control over their cloud assets by mitigating the often-overlooked risks, and stay ahead of the next major identity-driven attack.

The National Archives is the official archive and publisher for the UK Government. Our records include physical records such as the Domesday Book and Magna Carta, along with digital records from UK Government departments, Enquiries, and other public bodies, held both on premise and in public cloud.

It's vitally important to protect our digital records from accidental deletion and the increasing threat of ransomware. We therefore initiated a programme to implement immutable cloud backups using the AWS Backup service within a central, segregated AWS account.

In this talk, we'll share our learnings from this programme of work, including:
- why AWS Backup compliance mode vault locks are not always truly immutable
- which KMS key types should be selected to support backup and restore to a central vault
- the importance of Logically Air Gapped (LAG) vaults
- how each AWS service has implemented backups differently
- which widely used AWS database option doesn't support centralised backup
- cost considerations for setting up backup plans

We soon learnt that it's not just a case of "Turn on AWS Backup". To deploy a centralised solution, we needed to:
- configure centralised AWS Backup vaults and vault policies
- deploy components to workload accounts, including Backup vaults, EventBridge, IAM roles
- select the appropriate vault type depending on AWS resource type

We decided to implement our solution as an open-source, public Terraform Module which deploys immutable AWS Backups across an AWS Organization, to handle this complexity, and simplify onboarding new accounts and resources to be backed up.

You'll come away with an increased understanding of AWS Backup, an appreciation of its complexity and limitations, and the opportunity to greatly simplify deployment of truly immutable backups across your AWS accounts, using our public Terraform module.

Cloud Service Providers (CSPs) have grown, established and been widely adopted with time. This growth has had its own ramifications, consequences, and a significant influence on how modern systems are built. However, due to the speed at which these services are released for public use, security practices are often left behind. We will discuss how two aligned bad security practices lead to multiple scenarios where systems dependent on cloud resources can be compromised, ranging from dangling cloud resource takeovers, to supply chain attacks. From the perspective of the infamous shared responsibility model of security, bad security practices are not only related to end users but also are associated with CSPs themselves, leading to security implications for both ends.

This talk describes and details how, on the CSPs side, the usage of Universal DNS Zones and cloud credentials used in URL parameters turn out to be security nightmares. Universal DNS Zones refer to the design decision of CSPs of using common DNS zones for all customers without any distinction on who owns the resource. This leads to a set of security issues, that can be abused to perform cloud resource hijacking. The case for cloud credentials used in URL parameters focuses on Azure SAS token abuse scenarios. Even though these bad security practices are not a novel discovery, our investigation reveals new non-published scenarios covering a wide range of possible attacks.

The most likely way your organization will get breached is via static credentials. An AWS API key, a GitHub PAT, a GCP API Key... all of these are risks. Datadog's State of Cloud Security for years now has called this out. What is the best way to prevent the leak or loss of static credentials? Never have any to lose.

This talk will cover the technical aspects of deploying JIT access to critical resources, eliminating all IAM Users, SCPs to apply, etc. That is the easy part! But if you want to have the same fame and success (or more!) I have experienced (it won't be hard!), you will need the rest of this talk: how to get an entire organization to buy in to a more complicated way of accessing the things they need to do their job. This is the hardest part of a JIT deployment, and one no vendor can completely solve, especially due to "fun" edges which exist within each cloud's permission models.

We will discuss approvals and audits, break-glass policies and access policies, verification and secure deployment, incidents and heartbreaks. Come and learn from my mistakes, go and make some new ones, and most importantly— eliminate static credentials. The less access you have, the better.

Some research is a slow burn; but mine is often a frantic scramble to keep up with threat actors or CloudSec Twitter. This talk uses the tj-actions/changed-files incident to expose the raw reality of rapid response research in cloud security. Using the incident as our backdrop, I'll walk you through the nitty-gritty of how a leading cloud security research team investigates urgent supply chain attacks. You'll get actionable takeaways on leveraging external data (okay … Twitter and Hacker News), the critical role of community, and the behind the scenes collaboration involved in publishing authoritative analysis. Expect a few frantic Slack screenshots and a stark look at how the research sausage is made.

With NIS2 and DORA hitting on top of GDPR and... everything else, compliance is, once again, high on the pain cycle. And while we have a plethora of security frameworks, they are all... lacking for cloud and many are poor fits for Europe. In this session we'll show how to build your interlocking compliance hierarchy for cloud, cover which frameworks work best, and how to practically use them at cloud scale.

Security tooling and configuration has evolved over the years to protect data in cloud. But what if that tooling isn't telling us the truth?

Ever wondered how many organisations (securely) use NetworkPolicy in Kubernetes to protect and monitor their Tier 0 assets? Are these policies applied holistically? Do they use Calico, Cilium or any other add-on?
What is the potential impact if an attacker lands in a compromised Pod? This talk presents some insights to the above questions highlighting the weaknesses organizations tend to have related to data exfiltration, lateral movement in cloud-native/K8s environments. Misconfigurations discussed in the talk are taken from real-world K8s security assessments conducted as part of several assumed breach scenarios against large-scale production clusters used by enterprises and banks.

Securing Cloud K8s environments is not straightforward since they tend to have complex architectures and using various custom networking components such as a Hub, Route Tables, NSGs among many others. Additionally, one needs to monitor for various protocols (HTTP, DNS, SMB). There is almost always a tradeoff between usability and security in such environments. Is this due to technical debt or due to the complex nature of cloud environments? This talk also explores a pragmatic approach to applying network-related policies in the Cloud.

You will leave with some insights on an attacker's perspective on weak networking controls, practical steps to harden your cloud infrastructure, along with a set of tools. This session includes a release of an open-source tool and vulnerable labs designed to help you understand and replicate these misconfigurations. This talk is tailored for cloud security engineers, platform teams, and anyone responsible for securing containerized workloads across public or hybrid environments.

Public cloud providers routinely update service configurations, sometimes subtly altering security postures without providing organizations with the potential security implications. In this talk, we’ll walk through the real-world discovery of a major architectural flaw in AWS’s ALB authentication system, later dubbed “ALBeast,” which exposed thousands of organizations due to undocumented behavior rather than insecure code. This event served as a wake-up call, prompting us to launch awssecuritychanges.com, an open-source initiative dedicated to tracking and analyzing silent, security-impacting changes in AWS documentation and service behavior. We’ll show how we built this resource, the surprising patterns it has uncovered since, and how security practitioners can use it to proactively detect and respond to risks that often hide in plain sight. You’ll walk away with a sharper lens on the hidden risks in the cloud shared responsibility model and practical guidance on how to protect your organization using predictive threat intelligence.

A few years ago, I stumbled across something odd in AWS: by combining VPC endpoints with customizable internal IP ranges, an attacker with stolen credentials could make API calls that show up in the victim’s logs with whatever source IP they wanted. No packet trickery - just using AWS as designed.

Recently, I revisited this idea and tried to pull off the same thing in Azure and GCP. Along the way, I learned a lot, found a bug in cross-tenant issuer validation, and came away with a much clearer picture of how each cloud handles internal control-plane API calls made using identities from other tenants.

In this talk, I’ll walk through:

• How the technique works in principle: combining within-VPC cloud API access and flexible control over internal IPs.
• How the ability to use identities from one tenant to call the cloud control plane in another (not cross-tenant resource access!) works differently in each cloud - and how that affects the technique.
• What this means for real-world abuse potential: in AWS it’s feasible but detectable, in Azure it’s mostly a no-op, and in GCP... 🤦
• And finally, how to detect it: which log fields to look at, and how to distinguish this behavior from legitimate activity.

If you join, expect a technically detailed walkthrough of what happened when I tried to force-fit the same theoretically portable idea into three clouds with very different architectures - and the lessons learned.

Data warehouses and data lakes have become the latest in a series of software categories designed to ingest, mangle, and make sense of the vast amounts of data produced by your average enterprise. Snowflake is currently one of the leading commercial solutions in this space, a SaaS (software-as-a-service) data platform used by many of the Fortune 500 with an annual revenue in the billions of dollars. Many organisations pour vast amounts of sensitive data into these systems, turning them into a crown jewel in the eyes of many attackers.

This talk will present the results of research and development work done into both attacking and defending large, production Snowflake deployments across a number of different organisations. A range of TTPs will be presented, demonstrating various ways an attacker could move to compromise a Snowflake instance. This will be accompanied by mitigations and detection strategies, enabling defenders to better harden and monitor their Snowflake usage. Finally, a new open-source tool will be released, enabling defenders to easily simulate the discussed TTPs against their Snowflake instances in order to generate telemetry and validate their detections.

What attendees will take away:

• The most likely TTPs to be executed against Snowflake, and how offensive and defensive experts can design security exercises
• The relevant security controls to harden or detect, where possible, against the discussed TTPs
• The telemetry and log sources available for detection engineering and monitoring Snowflake

According to AWS, approximately 66% of AWS security incidents begin with leaked access keys. Threat actors consistently search the internet for exposed credentials, rapidly exploiting any keys they discover. However, defenders can turn this very behavior into an advantage through honey tokens, deliberately exposed AWS access keys designed specifically to trigger alerts upon use.

While honey tokens can be incredibly useful for detecting attacker activity in your environment, not all honey tokens are built the same way. Some can even be trivial to bypass. In this session, we'll cover the nuances of AWS honey tokens in depth. We’ll discuss different types of honey tokens, how they work, potential detection evasion opportunities, and we’ll even share an open source tool to help you deploy resilient, evasion-proof honey tokens in your own environments.

Additionally, this session will dive into the internals of the AWS API, covering how some honey tokens can even alert when used with undocumented APIs, non-production endpoints, and more. Attendees will learn advanced strategies for detecting sophisticated threat actors.

Whether you’re just beginning to explore deception technology or you're a seasoned practitioner, this talk will cover the key things to know and help you stay one step ahead of threat actors.

Most of the cloud security world is built around a shared set of assumptions — assumptions shaped by AWS, Azure, and GCP. But what happens when a cloud provider challenges those assumptions at a foundational level?

Oracle Cloud Infrastructure (OCI) takes a fundamentally different approach to identity, access management, organizational structure, and policy enforcement. As more enterprises adopt multi-cloud strategies, it’s critical to understand how these differences can affect security design.

In this talk, we’ll explore how OCI’s tenancy + compartment model, human-readable policy syntax, and explicit access scoping contrast with other clouds — and why these differences matter. Rather than framing OCI as an outlier, this session highlights its intentional design — and how it offers both advantages and friction points for cloud security teams. Whether you're deep in other clouds or just OCI-curious, this talk offers a new perspective on how cloud architecture shapes the way we think about access and control.

Serverless is supposed to be safe. Functions are ephemeral, stateless, and isolated—until they're not.

In this talk, we reveal a novel persistence technique in AWS Lambda that leverages the trusted Extensions API. By injecting malicious extensions into Lambda Layers—often reused across multiple accounts—we show how attackers can silently persist inside seemingly ephemeral functions, exfiltrate secrets, and bypass runtime logging and application logic.

This is not a bug in IAM or the runtime. It’s a consequence of trust: many organizations adopt community or third-party Lambda Layers for monitoring, tracing, or instrumentation. If even one of those Layers is poisoned, it opens a stealthy path for persistent access.

We’ll walk through how these "Loiterers" survive beyond invocations, how they silently phone home, and how their behavior evades traditional detections. We’ll also release LambdaScope, a toolkit for defenders to uncover hidden extension activity via forensic signatures and dependency graph analysis.