Bit of a Close Talker: A Practical Guide to Serverless Cloud Co-Location Attacks

Bit of a Close Talker: A Practical Guide to Serverless Cloud Co-Location Attacks

Speakers: Wei Shao

Conference: NDSS Symposium

YouTube: https://www.youtube.com/watch?v=e8rs9V-nm78

Overview

This research transforms serverless cloud co-location attacks from trial-and-error guesswork into a systematic, repeatable methodology. By developing a three-phase probing strategy that fingerprints scheduler behavior without any privileged access, the researchers demonstrate how an attacker can reverse-engineer the placement logic of serverless platforms and then exploit those features to reliably achieve co-location with a target victim's functions.

The approach was validated against four representative schedulers in simulation, on a CloudLab cluster, and most critically, on Microsoft Azure Functions in production. On Azure, the researchers achieved co-location in all trials, covering approximately 230 machines with 64 attack functions at a total cost of less than $25. The paper also proposes a mitigation scheduler called DoubleDip that uses greedy self-isolation to dramatically reduce co-location probability without sacrificing serverless elasticity or warm-start performance.

Background

▶ Watch: Introduction: the co-location prerequisite for cloud attacks (0:00)

Serverless cloud platforms like AWS Lambda, Microsoft Azure Functions, and Google Cloud Run allow developers to run code without managing infrastructure, paying only for consumed resources. Under the abstraction, however, functions from different tenants can be placed on the same physical machines, sharing CPU caches and other micro-architectural resources -- opening the door to side-channel attacks.

Any cross-tenant attack in serverless environments requires a four-step pipeline: (0) scheduler fingerprinting, (1) attack function submission, (2) instance fingerprinting to verify co-location, and (3) launching the actual attack. Most prior research focused on steps 2 and 3 -- the side-channel attack itself -- while treating steps 0 and 1 as assumptions. However, in modern data centers with massive scale and complex schedulers, achieving co-location is non-trivial. This work shifts focus to the prerequisite problem: can an attacker systematically achieve co-location, and can this process be driven by observable scheduler behavior rather than blind luck?

Key Findings

▶ Watch: Five exploitable scheduler features identified (4:00)

Five exploitable scheduler features can be inferred from placement traces. The three-phase probing strategy identifies: (1) invocation locality -- whether functions tend to stay on the same machine, (2) autoscaling behavior -- whether new machines appear under load, (3) cold-start determinism -- whether cold starts lead to predictable placement, (4) account-level isolation -- whether the scheduler groups functions by user account, and (5) configuration-based locality -- whether functions with similar dependencies are clustered together.

Configuration matching achieves near-100% co-location success. When configuration-based locality exists and the attacker knows the victim's configuration (e.g., package dependencies), method M3-1 achieves success rates approaching 100% rapidly. This is dramatically more effective than scatter-based approaches.

Attack methods have limited transferability. Strategies derived from one scheduler's features do not work well on mismatched schedulers -- four out of nine cross-scheduler test curves remained at zero success rate. This confirms that fingerprinting is necessary; generic attacks are insufficient.

Azure Functions co-location achieved in all trials for under $25. On Microsoft Azure Functions, fingerprinting revealed invocation locality, autoscaling behavior, and application-level infrastructure sharing, but no account-level isolation. Using 64 attack functions with burst invocations, the researchers achieved co-location with approximately 1.8 victim hosts per trial.

Microsoft does not classify this as a vulnerability. After responsible disclosure, Microsoft responded that since no real attack (data exfiltration via side channel) was demonstrated in conjunction with the co-location, they do not classify the finding as a vulnerability.

Technical Deep Dive

▶ Watch: Four attack methods: scatter vs targeted co-location (8:00)

The three-phase probing strategy works as follows:

Phase 1 -- Single Function Flow: The attacker repeatedly invokes a single function and observes placement behavior. If the function consistently lands on the same machine, invocation locality (Feature 1) is present. If new machines appear as invocation intensity increases, autoscaling behavior (Feature 2) is present.

Phase 2 -- Duplicate Function Comparison: The attacker creates a duplicate of the Phase 1 function and alternates invocations between original and duplicate. By comparing placement, the attacker infers whether cold-start placement is deterministic (Feature 3) and whether the scheduler isolates by account (Feature 4).

Phase 3 -- Configuration Variation: The attacker varies function configuration parameters (e.g., package dependencies, runtime settings). If functions with similar configurations cluster together, configuration-based locality (Feature 5) is present.

Each discovered feature maps directly to an attack strategy. M1 (Multi-function scatter) deploys many functions to increase server coverage when invocation locality limits a single function's reach. M2 (Autoscaling exploitation) generates invocation bursts to force instance spreading across machines. M3-2 (Configuration scatter) varies configurations to spread across clusters. M3-1 (Configuration matching) precisely matches the victim's configuration for targeted placement.

The DoubleDip mitigation scheduler uses a greedy algorithm: first, place functions on hosts already serving the same user (maximizing self-isolation); if no such host is available, choose the host with the fewest distinct users (minimizing cross-tenant mixing). This dramatically reduces co-location probability while maintaining warm-start ratios comparable to existing schedulers.

Demo / Proof of Concept

▶ Watch: Evaluation on Azure Functions: co-location in all trials for under $25 (10:00)

The researchers conducted a full end-to-end validation on Microsoft Azure Functions. Using the three-phase probing strategy with 10-second invocation intervals over 10-minute sessions, they fingerprinted Azure's scheduler behavior, identifying invocation locality, autoscaling, and application-level sharing. They then deployed 64 attack functions under a single attacker account with burst invocations to maximize coverage. The result: co-location achieved in every trial, covering approximately 230 machines and co-locating with an average of 1.8 victim hosts, all for a total cost of less than $25.

The co-location was verified using fingerprinting techniques from prior work (not side-channel based). The researchers also validated their attack strategies in a custom simulator (accepted to CCGrid 2026 and planned for open-source release) and on a multi-node CloudLab cluster.

Defensive Implications

▶ Watch: Q&A: Microsoft's response and verification methodology (16:00)

The primary defensive contribution is the DoubleDip scheduler, which provides self-isolation without requiring expensive dedicated hosts. By preferring hosts already serving the same user and minimizing user diversity on shared hosts, DoubleDip dramatically reduces the co-location attack success rate while retaining warm-start performance comparable to existing schedulers.

For cloud providers, the implications are significant: current serverless schedulers are leaking exploitable placement information through entirely unprivileged observations. The five-feature fingerprinting framework gives providers a concrete checklist of what their schedulers should not reveal. Specifically, providers should evaluate whether their placement logic exposes invocation locality, deterministic cold-start behavior, or configuration-based clustering that attackers can exploit.

For organizations using serverless platforms, this research highlights that serverless does not equal isolated. Functions processing sensitive data should not assume they are protected from co-tenant side-channel attacks. Microsoft's response -- declining to classify this as a vulnerability because no actual data exfiltration was demonstrated -- should not provide false comfort, as the side-channel attacks themselves are well-established in the literature.

Organizations should consider: using dedicated/isolated compute options for sensitive workloads, monitoring for anomalous function deployment patterns, and ensuring that function configurations (package dependencies, runtimes) for sensitive workloads are not easily guessable.

Key Takeaways

• Serverless scheduler behavior can be fingerprinted through five features observable without any privileged access, turning co-location from trial-and-error into a systematic process
• Configuration-based locality, when present, enables near-100% co-location success rates by matching the victim's function configuration
• Microsoft Azure Functions was successfully attacked in all trials using 64 functions and burst invocations, at a cost of less than $25
• Attack strategies have limited transferability across different scheduler types, making fingerprinting a necessary prerequisite
• The DoubleDip scheduler provides effective self-isolation through greedy placement that minimizes cross-tenant mixing without sacrificing elasticity
• Microsoft does not classify co-location capability alone as a vulnerability, requiring demonstrated data exfiltration

About the Speaker(s)

Wei Shao is a second-year PhD student at UC Davis. His research focuses on cloud security, specifically the intersection of serverless computing, scheduling algorithms, and cross-tenant attack surfaces. The simulator developed for this research was accepted to CCGrid 2026 and is planned for open-source release.