Living-off-the-Cloud Attacks: How Attackers Abuse Trusted Cloud Services

Google Cloud’s H1 2026 Threat Horizons Report documents a technique it calls “living off the cloud” (LOTC) — attackers compromising cloud infrastructure from an already-compromised endpoint by abusing legitimate, trusted cloud services and APIs, rather than deploying detectable custom malware.

What is LOTC?

LOTC is the cloud-era version of a well-established idea: instead of bringing your own tools (which can be detected, flagged, and fingerprinted), use what’s already there and already trusted. In a cloud context, that means using legitimate APIs, built-in cloud services, and existing identity/trust relationships to move, operate, and exfiltrate data — activity that, to most monitoring systems, looks like normal cloud usage rather than an attack.

How it differs from LOTL

Living-off-the-land (LOTL) is the operating-system-level version of this idea — attackers using built-in OS utilities (PowerShell, legitimate admin tools) instead of custom malware, to blend into normal system activity. LOTC applies the identical principle one layer up, at the cloud-infrastructure level: abusing the trust relationships and legitimate services that connect an endpoint to cloud resources, rather than the resources themselves.

Why trusted services are dangerous in this context

The core problem is structural, not a flaw in any specific service: cloud environments are built around interconnected trust — an identity provider trusts a device, a CI/CD pipeline trusts a cloud platform, a personal account sometimes has a connection path into a corporate one. Each of these trust relationships exists for legitimate operational reasons. LOTC attacks don’t break them; they ride them.

Real documented patterns

Google Cloud’s 2026 reporting describes a specific, real example: threat actors (attributed to North Korean groups) bypassed traditional network perimeter defenses entirely by exploiting a personal-to-corporate connection — using social engineering to establish or abuse a link between an individual’s personal accounts/devices and their corporate access — which let them pivot directly into the organization’s cloud environment and ultimately compromise a Kubernetes cluster to steal cryptocurrency, without ever needing to breach a traditional network boundary at all.

Other documented abuse patterns in the same category:

• Cloud storage abuse — using legitimate cloud storage services as a staging or exfiltration point, since traffic to well-known storage providers rarely triggers the scrutiny a connection to an unknown external server would.
• Identity provider abuse — exploiting trust relationships between identity systems to pivot across environments that otherwise appear properly segmented.
• SaaS abuse — using the legitimate automation and integration features of SaaS platforms themselves as the mechanism for lateral movement or data access, rather than attacking the platform’s security directly.
• Cloud API abuse — operating entirely through documented, legitimate API calls, which blend into normal application traffic far more effectively than any custom tooling could.

Why detection is genuinely harder here

There’s frequently no malicious file for traditional detection tooling to flag — the “attack” is a sequence of individually legitimate API calls and service interactions, using credentials and trust relationships that are themselves real and properly provisioned. Effective detection depends on recognizing patterns of activity that are anomalous in context (unusual timing, unusual scope, unusual sequencing) rather than any single flagged action — a fundamentally harder detection problem than signature-based malware identification.

Defensive controls

• Logging with enough context to establish a real behavioral baseline — not just “did this action happen,” but “is this action consistent with how this identity/service normally behaves.”
• Threat hunting, proactively, rather than relying purely on automated alerting — LOTC activity is specifically designed to avoid tripping conventional alerts, which means some of it is only found by someone actively looking.
• Scrutiny of personal-to-corporate connection points specifically, given the documented Kubernetes-compromise pattern above started exactly there — this is a genuinely underexamined boundary in many organizations’ threat models.
• Cloud lateral movement detection, tuned to the specific trust relationships your environment actually has (CI/CD-to-cloud, identity-provider-to-service, storage-to-compute) rather than generic anomaly detection alone.
• Defensive controls scoped to trust relationships, not just assets — reviewing why each trust relationship exists and whether it’s still necessary is often more revealing than reviewing the assets at either end of it.

Key takeaways

Living-off-the-cloud attacks succeed precisely because they don’t look like attacks — they’re built from the same legitimate services, APIs, and trust relationships that make cloud environments useful in the first place. Google Cloud’s documented 2026 case (personal-to-corporate pivot into a Kubernetes compromise) shows this isn’t theoretical. Defending against it requires threat hunting and behavioral baselining layered on top of traditional controls, not a replacement for them — and specific attention to the trust boundaries, like personal device connections, that conventional network perimeter thinking tends to overlook.

Shahid Security’s Cyber Threat Intelligence engagements include cloud-specific threat modeling and trust-relationship review, going beyond standard perimeter-focused assessments.

Do you know every trust relationship your cloud environment currently has, and why each one exists? Book a free consultation if that’s not a confident yes.

---

Sources: Google Cloud Threat Horizons Report, H1 2026.