CLOUDBURST: Cloud-Layer Observations Using Beacons for Unified Real-time Surveillance and Threat Attribution
arXiv:2605.12976v1 [cs.CR] 13 May 2026
A Formal Taxonomy and Measurement Framework for Cloud-Native Post-Exfiltration Attribution Abraham Itzhak Weinberg AI-WEINBERG, AI Experts, Tel Aviv, Israel [email protected] Abstract Modern cloud-native environments present a fundamentally different exfiltration threat surface than traditional filebased scenarios. Attackers targeting AWS, GCP, Azure, and OCI steal S3 presigned URLs, container images, Kubernetes secrets, Terraform state modules, and IAM role tokens – artefacts that existing honeytoken and beacon frameworks do not address. We present CLOUDBURST, the first formal taxonomy and measurement framework for cloud-native passive beacons, comprising six vector classes across four major cloud providers. We introduce the Cloud Attribution Score (CAS), a four-component metric that explicitly models ephemeral infrastructure penalty (Ep ), IAM coverage depth (Ic ), and multi-cloud correlation bonus (Mb ) – dimensions absent from all prior attribution quality metrics. Experiments across 21 deployed beacons, 205 simulated callbacks, and three attacker sophistication levels yield four principal findings. First, IAM Canary Roles achieve the highest CAS (mean 0.450) and Detection Resistance (DR = 0.873), making them the most deployable vector. Second, S3 Presigned URLs achieve the highest detection resistance (DR = 0.890), surviving all three cloud-native scanner models (AWS Macie, Checkov/tfsec, Prisma Cloud/Wiz). Third, ephemeral infrastructure churn degrades CAS from ≈ 0.79 at deployment to ≈ 0.18–0.22 at 48 hours for all vectors (p < 0.001), establishing the first quantitative model of attribution decay in containerised environments. Fourth, Serverless Function Triggers exhibit the worst detection resistance (DR = 0.611) due to their explicit outbound HTTP callback pattern, motivating covert callback channel design as future work. No significant CAS difference is observed across cloud providers (H = 1.99, p = 0.57), confirming that CLOUDBURST is provider-agnostic in its effectiveness.
Keywords: cloud security, post-exfiltration attribution, honeytoken, beacon infrastructure, ephemeral containers, Kubernetes, IAM, multi-cloud, deception technology.
1
Introduction
The threat model for cyber exfiltration has shifted fundamentally. In the era of cloud-native infrastructure, attackers do not steal files from file servers, they steal cloud credentials that grant access to entire data estates, container images that embed backdoors into supply chains, Kubernetes secrets that unlock production databases, and Terraform modules that propagate malicious infrastructure across every environment that imports them. Yet the academic literature on post-exfiltration attribution remains almost entirely focused on file-based and mobile scenarios [7, 11, 13]. The Passive hack-back framework [13] formalised beacon callback telemetry for documents and credentials but did not address the unique properties of cloud-native environments: ephemeral pod lifecycles, IAM (Identity and Access Management) role assumption chains, multi-cloud credential formats, and the presence of cloud-native secret-scanning pipelines (AWS Macie, Checkov, Prisma Cloud) that can detect naive beacon implementations. We identify three properties that make cloud-native attribution qualitatively different from file-based attribution. Infrastructure ephemerality. In a Kubernetes cluster with horizontal pod autoscaling, the container that triggered a beacon callback may no longer exist by the time attribution analysis begins. The standard assumption that “the machine that fired the beacon is still running” does not hold in cloud-native environments. This requires explicit temporal modelling of attribution quality decay. 1
IAM complexity. Cloud API calls carry rich identity context – assumed role ARNs (Amazon Resource Names), service account emails, managed identity client IDs – that provides attribution telemetry far richer than an IP address. However, this telemetry requires CloudTrail/Audit Log to be enabled and requires careful interpretation of role assumption chains that may obscure the originating principal. Multi-provider normalisation. An attacker may use stolen AWS credentials from an Azure-hosted attack platform routed through a GCP (Google Cloud Platform) exit node. Attribution systems must normalise telemetry across provider-specific formats. CLOUDBURST addresses all three properties through a formal taxonomy of six beacon vector classes, a fourcomponent Cloud Attribution Score (CAS), and an empirical evaluation across four cloud providers and three attacker sophistication levels. Contributions 1. The first formal taxonomy of cloud-native beacon vector classes with quantified threat properties. 2. The Cloud Attribution Score (CAS) – a metric that explicitly models ephemeral penalty, IAM coverage, and multi-cloud correlation. 3. An ephemeral decay model quantifying how containerised infrastructure churn degrades attribution quality. 4. Empirical evaluation across AWS, GCP, Azure, and OCI with three scanner models (Macie, Checkov, Prisma Cloud). 5. A provider-agnostic deployment recommendation framework derived from the CAS × DR trade-off analysis.
2
Related Work
This section reviews prior work in deception-based security, cloud-native monitoring, and IAM abuse detection, with a focus on techniques relevant to post-exfiltration attribution in cloud environments. We highlight how existing approaches primarily address detection, telemetry, or static deception, while lacking mechanisms for longitudinal attribution across cloud providers. We then position CLOUDBURST relative to these strands, emphasizing its focus on formal attribution quality and cloud-native deployment dynamics. 2.1
Honeytoken and Beacon Systems Spitzner [11] introduced the honeytoken primitive; Juels and Rivest [7] formalised honeywords for password database protection. Canarytokens [3] industrialised deployable tracking URLs and document beacons. The Passive hack-back framework [13] established formal metrics (β, α, σ) for beacon-based attribution. PHANTOM [15] addressed the semantic quality of generated honeytokens. ARCANE [14] proposed longitudinal cross-campaign attribution using Bayesian fingerprint accumulation. CLOUDBURST extends this lineage to the cloud-native domain, which none of these works address. 2.2
Cloud Security Monitoring Cloud-native security monitoring is an active field. CloudTrail analysis for insider threat detection was studied by [10]; Kubernetes audit log anomaly detection by [4]; and container image scanning by [6, 9, 12]. These works focus on detecting attacks in progress; CLOUDBURST focuses on attributing attackers post-exfiltration, a complementary but distinct objective. 2.3
Cloud-Native Deception Yu et al. [16] proposed HoneyFactory, a container-based honeypot deployment framework. Beltran-Lopez et al. [2] surveyed deception technology taxonomies including cloud-hosted honeypots. Neither work addresses the specific challenge of post-exfiltration attribution in cloud-native environments, nor does either formalise the ephemeral decay problem. 2.4
IAM and Credential Abuse IAM misconfiguration is the leading cause of cloud data breaches [5]. Canary IAM roles have been proposed as a detection primitive in practitioner literature [1], but to our knowledge CLOUDBURST presents the first formal CAS-based evaluation of their attribution quality across providers.
2
3
Formal Framework
This section introduces a formal model for quantifying attribution quality in cloud-native beacon systems. We define the CAS as a unified metric that captures callback fidelity, IAM visibility, infrastructure ephemerality, and cross-cloud correlation effects. The framework is designed to model the degradation of attribution signals under real-world cloud conditions, particularly in environments with high churn, autoscaling, and multi-provider deployments. 3.1 Cloud Attribution Score Definition 1 (Cloud Attribution Score). Let c denote a beacon callback event. The Cloud Attribution Score of c is: CAS(c) = w1 Cf (1 − Ep ) + w2 Ic + w3 (1 − Ep )Ic + w4 Mb (1) where: • Cf ∈ [0, 1]: callback fidelity – information quality per callback (degraded by TOR, VPN, IP rotation) • Ep ∈ [0, 1]: ephemeral penalty – attribution quality loss due to infrastructure churn • Ic ∈ [0, 1]: IAM coverage – fraction of IAM context captured by CloudTrail/Audit Log • Mb ∈ [0, 1]: multi-cloud bonus – correlation gain from cross-provider infrastructure evidence P • (w1 , w2 , w3 , w4 ) = (0.35, 0.25, 0.25, 0.15), wi = 1 The interaction term w3 (1 − Ep )Ic captures the joint penalty: ephemeral infrastructure renders IAM coverage less useful because the IAM principal that triggered the beacon may no longer exist. Definition 2 (Ephemeral Decay). The ephemeral penalty at time t hours after deployment is: (2)
Ep (t, r, s) = 1 − e−δ(t+2r+3s)
where r is the number of pod restarts, s is the number of autoscaling events, and δ > 0 is a base decay rate. The coefficients 2r and 3s reflect that restarts and scale events cause proportionally more attribution loss than simple clock time. Definition 3 (IAM Attribution Coverage). The IAM coverage of a callback event is: n a , 0.80 + 0.10 · 1[k>1] + 0.10 · 1cross-account Ic = min 10
(3)
where na is the number of logged API actions, k is the number of distinct IAM principals observed, and 1cross-account indicates a cross-account role assumption (which reveals additional infrastructure). CAS example values for our six vector classes are presented in Table 1. Table 1: CAS Component Examples by Scenario Scenario
Cf
Ep
Ic
Mb
CAS
S3 presigned (naive) S3 presigned (APT - Advanced Persistent Threat) IAM canary (direct) K8s (high churn) Terraform (cached) Serverless (cold)
0.92 0.55 0.98 0.70 0.50 0.60
0.05 0.10 0.02 0.65 0.30 0.55
0.70 0.45 0.95 0.55 0.40 0.65
0.40 0.20 0.60 0.35 0.50 0.45
0.707 0.417 0.896 0.324 0.367 0.398
3.2
Ephemeral Decay Examples The ephemeral decay model (Definition 2) gives Ep = 0.049 for a fresh pod (1h, no restarts), rising to Ep = 0.528 for moderate churn (8h, 2 restarts, 1 scale event) and Ep = 0.884 for high churn (24h, 5 restarts, 3 scale events). These values directly inform beacon placement strategy: vectors with high inherent ephemeral risk (Kubernetes secrets, serverless functions) require more aggressive callback accumulation to achieve reliable CAS before infrastructure churn degrades it. 3
4
Beacon Vector Taxonomy
CLOUDBURST defines six cloud-native beacon vector classes (Figure 1), each with distinct threat properties, provider support, and optimal deployment conditions.
Figure 1: Radar profiles of the six CLOUDBURST beacon vector classes. Each axis encodes a key deployment property: Stealth (how well disguised), Ephemeral Risk (inverted – higher is safer), IAM Complexity, Multi-Cloud support, and TTD Efficiency (inverse of callbacks to detect). IAM Canary Roles (gold) show the most balanced profile. Kubernetes Secrets (red) exhibit low multi-cloud coverage and high ephemeral risk. S3 Presigned URLs (blue) have the best combination of low ephemeral risk and high multi-cloud support. S3 Presigned URLs / Cloud Storage Signed URLs. Time-limited signed URLs embedded in exfiltrated documents or credential bundles. The beacon fires when the attacker downloads the “stolen” data object. Provider equivalents: GCS signed URLs (GCP), Azure Blob SAS URLs (Azure). Ephemeral risk is low (Ep = 0.10) because signed URLs persist even after bucket deletion until their expiry timestamp. Watermarked Container Images. OCI-compatible container images with an embedded health-check layer that calls back to the attribution endpoint on each pod scheduling. Risk: images may be cached at pull-through registries, causing the callback to be missed. Medium ephemeral risk (Ep = 0.45) due to cache bypass scenarios. Canary IAM Roles / Service Accounts. Dormant IAM roles (AWS), service accounts (GCP), or managed identities (Azure) with no legitimate invocation path. Any API call generates a CloudTrail or Audit Log entry containing the full principal ARN, source IP, user-agent, region, and action. This provides the richest attribution telemetry of any vector class and has the lowest ephemeral risk (Ep = 0.05) because IAM roles are persistent. Poisoned Terraform Modules. Terraform registry modules with embedded HTTP data sources that fire on every terraform plan or apply. The callback captures the CI/CD pipeline context: executor IP, Terraform version, provider configuration. Medium ephemeral risk (Ep = 0.30) due to CI pipeline caching. Kubernetes Secret Beacons. Kubernetes secrets with embedded annotation callbacks triggered by Falco admission webhook or audit log. The callback captures pod name, namespace, service account, and node IP. 4
Highest ephemeral risk (Ep = 0.65) due to pod restart and redeployment patterns. Serverless Function Triggers. Lambda/Cloud Functions deployed as “dead code” with no legitimate invocation path. Any invocation – including test events – fires an attribution callback with request context. Medium-high ephemeral risk (Ep = 0.55) due to cold-start delays that may cause attribution callbacks to be dropped.
5
Experimental Setup
This section describes the experimental environment used to evaluate CLOUDBURST, including beacon deployment across cloud providers, attacker behaviour simulation, and the scanner models used for detection benchmarking. The setup is designed to reflect realistic multi-cloud infrastructures and adversarial conditions, enabling controlled measurement of attribution quality, detection resistance, and cross-vector performance under varying operational and threat scenarios. 5.1
Beacon Deployment We generate 21 cloud-native beacon instances: the six vector classes deployed across their applicable provider set (S3 presigned: AWS/GCP/Azure; Container: all four; IAM canary: all four; Terraform: all four; K8s secret (Kubernetes Secret): AWS/GCP/Azure; Serverless: AWS/GCP/Azure), yielding 21 total beacons. Each beacon contains provider-specific organisational context derived from the “payflow.io” FinTech profile: real-format IAM ARNs, signed URL structures, and service names consistent with a payment infrastructure stack. 5.2
Attacker Simulation Three attacker sophistication levels are modelled (Table 2), differing in routing behaviour (TOR/VPN/residential proxy usage), infrastructure rotation rate, dwell time before using stolen credentials, and cloud SDK sophistication. Table 2: Attacker Profile Parameters Parameter
Naive
Advanced
APT
TOR usage VPN usage Residential proxy Infra rotation rate Dwell time (mean h) SDK sophistication
15% 30% 5% 5% 2.0 curl
45% 40% 20% 25% 8.0 boto3
70% 25% 50% 65% 72.0 native SDK
5.3
Scanner Models Three cloud-native scanner models are evaluated: S1 – AWS Macie / GCP DLP (Data Loss Prevention) (λ1 = 0.40): ML-based sensitive data classification. Flags known credential patterns (AKIA key IDs, private key headers) and obvious beacon markers. S2 – Checkov / tfsec (λ2 = 0.30): IaC (Infrastructure as Code)-focused static analysis. Most effective against Terraform modules with external HTTP data sources and Kubernetes secrets with unusual annotations. S3 – Prisma Cloud / Wiz (λ3 = 0.30): CNAPP (Cloud Native Application Protection Platform) runtime scanner. Detects anomalous outbound connections from cloud functions and containers. Most effective against Serverless and Container vectors. P3 Combined detection probability: Pd = j=1 λj Pd,j (c); detection resistance: DR = 1 − Pd .
6
Results
This section presents the empirical evaluation of CLOUDBURST across all beacon vector classes, attacker profiles, and cloud providers. We report results in terms of CAS, detection resistance, attribution speed, and ephemeral decay dynamics. Together, these metrics quantify how beacon design, attacker sophistication, and infrastructure volatility interact to shape attribution quality in cloud-native environments.
5
6.1
CAS by Vector and Attacker Level Figure 2 and Table 3 present the primary results. IAM Canary Roles achieve the highest mean CAS (0.450 ± 0.11), followed by Poisoned Terraform modules (0.398) and S3 Presigned URLs (0.383). Serverless Function Triggers score lowest (0.318) due to high ephemeral penalty from cold-start latency.
Figure 2: Cloud Attribution Score (CAS) by beacon vector and attacker sophistication level (±SD). IAM Canary Roles consistently outperform other vectors across all three attacker levels. Naive attackers yield slightly higher CAS than APT attackers due to lower evasion, but the ANOVA test finds no statistically significant attacker-level effect (F = 1.52, p = 0.23), suggesting that CLOUDBURST’s attribution quality is evasion-resistant within the observed CAS range.
Table 3: Main Results by Beacon Vector Vector
CAS
DR
CTD-N
CTD-A
Canary IAM Role Poisoned Terraform S3 Presigned URL Container Image K8s Secret Serverless Trigger
0.450 0.398 0.383 0.325 0.328 0.318
0.873 0.768 0.890 0.736 0.741 0.611
4.0 3.8 3.3 2.8 4.7 3.7
3.5 3.8 2.7 3.0 2.7 1.7
Overall
0.373
0.773
–
–
CTD-N/A = Callbacks to Detect (Naive/APT). DR = Detection Resistance
Notably, CAS does not differ significantly by attacker level (F = 1.52, p = 0.23, Table 5). This is an important positive finding: CLOUDBURST’s attribution quality is largely evasion-resistant because the primary CAS driver is IAM coverage – a provider-side telemetry property that attackers cannot suppress without disabling CloudTrail, which is itself an alertable action. 6.2
Detection Resistance (DR) Figure 3 shows detection probability by scanner and vector. S3 Presigned URLs achieve the highest DR (0.890) because their URL format does not contain patterns that regex or IaC scanners flag, and their outbound access pattern is indistinguishable from legitimate data retrieval. Serverless Function Triggers score the lowest DR (0.611), primarily due to the S3 (Prisma Cloud/Wiz) scanner detecting the explicit urllib.request.urlopen callback in the function body.
6
Figure 3: Detection probability Pd by cloud-native scanner and beacon vector. IAM Canary Roles achieve nearzero detection probability across all three scanners (they appear as legitimate over-provisioned roles). Serverless triggers score highest on S3 (CNAPP scanner) due to their explicit outbound HTTP callback. Boxplot whiskers show 1.5×IQR; outliers are plotted individually. 6.3
Attribution Speed Figure 4 shows callbacks required to reach attribution confidence P (H|E) ≥ 0.85. Kubernetes Secrets require the fewest callbacks for APT attackers (median 2.7), because APT actors who actually use a K8s secret generate rich IAM context. S3 Presigned URLs are fastest for naive attackers (median 3.3) due to high callback fidelity.
Figure 4: Mean callbacks required to reach attribution confidence P (H|E) ≥ 0.85, by beacon vector and attacker sophistication. All values fall below the practical threshold of 5 callbacks per attacker-vector pair. Serverless triggers are fastest for APT actors (median 1.7) because each serverless invocation carries full request context including caller identity.
7
6.4
Ephemeral Decay Figure 5 is the paper’s most novel empirical result. CAS degrades from approximately 0.79 at t = 0 to 0.18– 0.22 at t = 48 hours across all vectors (p < 0.001 for all six, Table 4). The Canary IAM Role curve degrades most slowly (highest residual CAS at t = 48: 0.220) because IAM roles are persistent and their CloudTrail logs survive pod restarts. Kubernetes Secrets degrade fastest (residual 0.176) because pod restart events create false-positive callback signals that dilute attribution quality.
Figure 5: CAS degradation under ephemeral infrastructure churn over 48 hours. All vectors start at CAS ≈ 0.79 and decay toward ≈ 0.18–0.22. The dotted line at 0.85 is the high-confidence attribution threshold. Shaded regions show ±1 SD across n = 50 simulations per time point. Canary IAM Roles (gold) decay most slowly; Kubernetes Secrets (red) fastest.
Table 4: CAS Degradation at t = 48h Vector
CAS0
CAS48
∆
p
S3 Presigned URL Container Image Canary IAM Role Terraform Module K8s Secret Serverless Trigger
0.788 0.790 0.790 0.795 0.794 0.792
0.215 0.185 0.220 0.197 0.176 0.181
−0.574 −0.604 −0.569 −0.598 −0.618 −0.610
< 0.001 < 0.001 < 0.001 < 0.001 < 0.001 < 0.001
6.5
Multi-Cloud Analysis Figure 6 shows CAS by vector and provider. IAM Canary Roles achieve the highest CAS across all four providers (AWS: 0.490; Azure: 0.496; GCP: 0.409; OCI: 0.405), confirming that this vector class is the strongest regardless of cloud provider.
8
Figure 6: Cloud Attribution Score heatmap across beacon vector and cloud provider. Warmer colours indicate higher CAS. IAM Canary Roles (top row) are consistently the strongest vector. Kubernetes Secrets are absent for OCI (not yet supported in the simulation) and show lowest CAS on AWS (0.24), reflecting AWS’s more complex RBAC interaction with Falco. The Kruskal-Wallis test finds no significant provider effect on CAS (H = 1.99, p = 0.574, not significant), confirming that CLOUDBURST’s effectiveness is provider-agnostic – a key practical property for multi-cloud deployments. Figure 7 shows the overlapping CAS distributions across providers.
9
Figure 7: CAS distribution by cloud provider. The four distributions overlap substantially and do not differ significantly (Kruskal-Wallis p = 0.574). This confirms that CLOUDBURST’s performance is provider-agnostic and can be deployed uniformly across a multi-cloud estate without provider-specific tuning. 6.6
CAS vs Attribution Posterior Figure 8 plots CAS against the final Bayesian attribution posterior P (H|E) across all beacon-attacker combinations. The positive correlation (r ≈ 0.73) confirms that CAS is a valid proxy for attribution outcome. However, no data points reach the ideal zone (CAS ≥ 0.70, P (H|E) ≥ 0.85), indicating that the current feature set does not provide sufficient discriminative power for high-confidence attribution at N = 10 candidate actors. The maximum observed posterior is ≈ 0.52 (IAM canary, advanced attacker), requiring additional signal classes to reach operational attribution confidence.
10
Figure 8: CAS vs final attribution posterior P (H|E) by attacker level. The positive correlation validates CAS as a meaningful proxy for attribution quality. No points reach the ideal zone (shaded), establishing the CAS threshold required for high-confidence attribution as a quantified open challenge. The maximum observed posterior (≈ 0.52, upper right) is achieved by the IAM Canary vector against APT actors.
Table 5: Statistical Tests – Attacker Level Effects Metric
F
p
Sig.
CAS Posterior CTD
1.524 0.891 1.304
0.226 0.416 0.279
ns ns ns
ns = not significant (p > 0.05).
7
Discussion
This section interprets the experimental results in terms of their implications for cloud-native attribution systems. We focus on the operational meaning of CAS dynamics, the practical trade-offs between beacon vector classes, and the structural limitations revealed by attacker behaviour and infrastructure ephemerality. We then situate CLOUDBURST within the broader deception and attribution pipeline and outline key constraints and future integration opportunities. 7.1
The Ephemeral Decay Finding The most important result is Figure 5: CAS decays from ≈ 0.79 to ≈ 0.18 within 48 hours for all vectors. This has a direct operational implication: cloud-native beacons must be designed to fire quickly or not at all. A beacon that requires 10 callbacks before attribution is actionable is useless in a Kubernetes cluster with a 6-hour pod lifetime. This motivates two design principles for future cloud attribution systems: (1) first-callback attribution – each individual callback must carry enough telemetry to provide at least partial attribution, rather than requiring 11
accumulation; (2) persistent anchor design – at least one beacon vector in every deployment should be from the persistent category (IAM canary, S3 presigned URL) to maintain attributability across infrastructure cycles. 7.2
IAM Canary Roles as the Recommended Vector The IAM Canary Role emerges from our analysis as the recommended primary deployment vector on all four criteria: highest CAS (0.450), second-highest DR (0.873), lowest ephemeral risk (Ep = 0.05), and provideragnostic support. The cost is highest IAM complexity (0.70), requiring careful permission scoping to prevent the canary from becoming a genuine privilege escalation vector. 7.3
The High-Confidence Attribution Gap No CLOUDBURST configuration achieved attribution posterior P (H|E) ≥ 0.85 in our experiments. This is the honest null result, and it is informative: it establishes the specific CAS threshold (CAS ≥ 0.70, not achieved in any observed scenario) required to close the gap. The CAS ceiling in our experiments (≈ 0.55 for IAM canary, advanced attacker) is driven by TOR usage and residential proxy routing that degrades Cf , combined with ephemeral penalties that suppress Ic . Three supplementary signals would close this gap: (1) cloud infrastructure graph – correlating the attacker’s exit IP with known cloud provider IP ranges provides implicit actor fingerprinting; (2) victim sector targeting – attackers who use an IAM canary in a FinTech environment but whose exit IP geolocates to a known APT origin region; (3) temporal clustering – the 72-hour APT dwell time is itself a behavioral fingerprint correlatable with ARCANE’s longitudinal model [14]. 7.4
Integration with Passive hack-back and ARCANE CLOUDBURST is designed as the cloud layer of a complete post-exfiltration attribution stack. The three papers form a pipeline: Passive hack-back [13] establishes the beacon deployment and callback reception infrastructure; PHANTOM [15] ensures beacon tokens are contextually convincing; CLOUDBURST provides the cloud-native vector taxonomy and CAS scoring; and ARCANE [14] accumulates callbacks longitudinally across campaigns to achieve high-confidence attribution where single-campaign analysis cannot. 7.5
Limitations Simulation validity. Our attacker simulator is calibrated against published APT behavioural profiles [5, 8] but is not a real deployment. Empirical validation with actual Passive hack-back callbacks is planned as follow-on work. Scanner models. We model three scanner types at a behavioural level; real deployments of Macie, Checkov, and Prisma Cloud may differ in specific rule sets and ML model versions. IAM role assumption chains. Our IAM coverage model does not fully capture multi-hop role assumption chains, which can obscure the originating principal through multiple sts:AssumeRole calls.
8
Deployment Recommendations
Based on the CAS × DR analysis, we recommend the following deployment priority for cloud-native beacon infrastructure: Tier 1 – Deploy universally: IAM Canary Roles (highest CAS, low ephemeral risk) and S3 Presigned URLs (highest DR, simple deployment).These should be present in every cloud account. Tier 2 – Deploy with caching awareness: Poisoned Terraform modules (second-highest CAS) and Container Image beacons (broadest provider coverage). Require CI/CD pipeline configuration to prevent callback suppression by caching. Tier 3 – Deploy with runtime monitoring: Kubernetes Secret beacons (require Falco/admission webhook) and Serverless triggers (highest ephemeral risk, lowest DR). Deploy only when Tier 1 and 2 are already in place.
9
Conclusion
We presented CLOUDBURST, the first formal taxonomy and measurement framework for cloud-native passive beacon infrastructure. The six-vector taxonomy covers the complete attack surface of modern cloud environments: object storage, container registries, IAM identity planes, infrastructure-as-code, container orchestration, and serverless compute. The Cloud Attribution Score (CAS) provides the first metric that explicitly models the three properties unique to cloud attribution: ephemeral infrastructure decay, IAM coverage depth, and multi-cloud correlation. Empirical 12
results across 21 beacons and 205 callbacks establish IAM Canary Roles as the superior primary vector (CAS = 0.450, DR = 0.873) and S3 Presigned URLs as the most evasion-resistant (DR = 0.890). All vectors show significant CAS decay over 48 hours (p < 0.001), establishing the ephemeral decay problem as a measurable, tractable engineering challenge. The absence of high-confidence attribution (P (H|E) ≥ 0.85 in zero configurations) is reported as an honest characterisation result. It quantifies the CAS threshold required for operational attribution and identifies the three supplementary signals – cloud infrastructure graphs, sector targeting, and temporal clustering – needed to close the gap. Combined with Passive hack-back, PHANTOM, and ARCANE, CLOUDBURST completes a four-paper research programme on post-exfiltration attribution and establishes a foundation for operational attribution in cloud security environments.
References [1] Nirmal Kavindu Athukorale, Chua Jing Yi, Loh Zi Xin, Alysha Yasmine, Choo Jia Qi, Dang Zi Yu, Jason Soo Jia Wei, Filbert Hady, Lim Shi Zhe, Chua Chong Eu, et al. Evaluating advanced cybersecurity technologies for cloud environments, 2025. [2] Pedro Beltrán-López, Manuel Gil Pérez, and Pantaleone Nespoli. Cyber deception: Taxonomy, state of the art, frameworks, trends, and open challenges. IEEE Communications Surveys & Tutorials, 2025. [3] NC Brintha, Vikrant Vijaybhai Joliya, G Bhuvnesh, and S Malini. Securing your network with honeypot, canerytokens and docker on aws. In 2023 International Conference on Computational Intelligence and Sustainable Engineering Solutions (CISES), pages 683–687. IEEE, 2023. [4] Loris Degioanni and Leonardo Grasso. Practical Cloud Native Security with Falco. " O’Reilly Media, Inc.", 2022. [5] C David Hylender, Philippe Langlois, Alex Pinto, and Suzanne Widup. Verizon 2024 data breach investigations report. The Verizon DBIR Team. Available online: https://www. verizon. com/business/resources/Tf18/reports/2024-dbir-data-breach-investigations-report. pdf (accessed on 20 November 2024), 2024. [6] Omar Javed and Salman Toor. Understanding the quality of container security vulnerability detection tools. arXiv preprint arXiv:2101.03844, 2021. [7] Ari Juels and Ronald L Rivest. Honeywords: Making password-cracking detectable. In Proceedings of the 2013 ACM SIGSAC conference on Computer & communications security, pages 145–160, 2013. [8] Jurgen Kutscher. M-trends 2022: Cyber security metrics, insights and guidance from the frontlines, April 2022. Threat Intelligence Report. [9] Veera Laurikainen. Securing container-based environments with anchore, 2022. [10] Andrew P Moore, Samuel J Perl, Jennifer Cowley, Matthew L Collins, Tracy M Cassidy, Nathan VanHoudnos, Palma Buttles, Daniel Bauer, Allison Parshall, Jeff Savinda, et al. The critical role of positive incentives for reducing insider threats, 2016. [11] Lance Spitzner. Honeypots: Catching the insider threat. In 19th Annual Computer Security Applications Conference, 2003. Proceedings., pages 170–179. IEEE, 2003. [12] Himanshu Tiwari. Enhancing container security through automated vulnerability scanning and remediation with trivy. Insights2Techinfo, Oct, 2023. [13] Abraham Itzhak Weinberg. Passive hack-back strategies for cyber attribution: Covert vectors in denied environment. arXiv preprint arXiv:2508.16637, 2025. [14] Abraham Itzhak Weinberg. Arcane: Cross-campaign attacker re-identification via passive beacon telemetry–a bayesian network framework for longitudinal cyber attribution. arXiv preprint arXiv:2604.24644, 2026.
13
[15] Abraham Itzhak Weinberg. Phantom: Polymorphic honeytoken adaptation with narrative-tailored organisational mimicry. arXiv preprint arXiv:2605.02992, 2026. [16] Tianxiang Yu, Yang Xin, and Chunyong Zhang. Honeyfactory: Container-based comprehensive cyber deception honeynet architecture. Electronics, 13(2):361, 2024.
14