Cloud Security in 2025: How to Stop Living Off the Land (LOTL) Attacks

Cloud environments have become the new hotspot for “living off the land” (LOTL) attacks. We’ve seen examples ranging from APT10’s Operation Cloud Hopper to the SolarWinds identity abuse, Storm-0558’s forged tokens, and Volt Typhoon’s long-term access campaigns. These incidents prove that attackers can use malwareless and cloud-native tools to stay hidden for months, all while causing serious national security risks.

Unlike older attacks that relied on obvious malware or suspicious files, cloud-based LOTL exploits built-in features such as cloud APIs, automation scripts, or metadata services. Because these tools are part of everyday operations, it’s much harder to tell when they’re being abused since it appears like legitimate application behavior. This article highlights the tactics attackers use in cloud environments, real-world case studies, and how runtime protection from Oligo Cloud Application Detection & Response (CADR) can stop them.

Why the Cloud is the New Target

The cloud is attractive to attackers because of how it’s built. Short-lived services like containers and serverless functions don’t always have security tools monitoring them, leaving blind spots. Tools that are deployed within these ephemeral environments often create a lot of alerts, which often cannot distinguish malicious behavior from normal.

 Everyday cloud features like metadata services or automation scripts are essential for operations, but attackers can easily twist them for malicious purposes. And because logs just show “normal” use of cloud accounts or APIs, security teams often can’t tell the difference between a hacker and a legitimate user. Finally, container systems like Kubernetes expose powerful admin surfaces that, if misused, give attackers deep control.

What LOTL Looks Like in the Cloud

In the cloud, “living off the land” means attackers use the cloud’s own features against it. They might grab credentials by querying a cloud metadata service (such as "http://169.254.169.254/latest/meta-data/" on AWS), or persist inside the environment by creating serverless jobs or Kubernetes tasks. Instead of using malware, they use cloud-native SDKs and CLIs to explore, move around, and steal data. The challenge for defenders is that these same actions also happen in normal operations. Without context on which application or library triggered the action, it’s almost impossible to separate benign activity from malicious.

How LOTL Shifted to the Cloud

The shift happened quickly. In 2020, attackers behind the SolarWinds breach forged SAML tokens to sneak into Microsoft 365 and Azure environments without malware. Soon after, groups like TeamTNT and UNC2903 started stealing credentials from cloud metadata services and using them to blend in through cloud CLIs. By 2023, cloud-native operations were in full swing. SCARLETEEL exploited container workloads to break into AWS services like S3 and Lambda. UNC3886 abused virtualization appliances to stay hidden at a lower level of infrastructure. Meanwhile, Volt Typhoon infiltrated U.S. critical infrastructure by hiding traffic through compromised routers and attempted to move laterally to cloud environments. Together, these milestones show that LOTL is now an established tactic in the cloud.

How Attackers Operate in the Cloud

Attackers usually follow a pattern. They gain access by exploiting public-facing applications, leveraging vulnerabilities, stealing valid cloud accounts, or abusing OAuth applications. Once inside, they query metadata services to collect credentials or set up serverless and Kubernetes jobs to stay active. They move around by enumerating IAM roles, secrets, and endpoints, or by leveraging account role assumptions. They collect and exfiltrate data directly from storage services like S3 or Blob, often sending it to another cloud provider to blend in. To stay hidden, they disguise their traffic through legitimate SaaS platforms, abuse signed binaries, and even deliberately turn off defenses. These tactics mimic traditional attack stages but are harder to detect because they use legitimate services.

Real-World Examples

Several cases highlight how damaging living off the land (LOTL) attacks can be. 

Volt Typhoon‍

A PRC-linked group that embedded itself in U.S. critical infrastructure using minimal malware and extensive abuse of administrative tools. They also routed traffic through compromised routers (the KV-botnet) to mask their operations. This campaign shows how attackers exploit edge devices and hybrid cloud interfaces to stay hidden.

SCARLETEEL‍

Attackers gained entry through compromised container workloads, harvested AWS credentials from metadata services, and pivoted into services like S3, Lambda, and Fargate. The operation led to intellectual property theft, cryptomining, and costly resource abuse.

TeamTNT and UNC2903‍

These groups exploited exposed Kubernetes and Docker instances, as well as SSRF vulnerabilities, to reach metadata endpoints. They then stole credentials and used them with native cloud tools for discovery and persistence. They often deployed Kubernetes DaemonSets to gain widespread control.

SolarWinds Follow-On

‍After the infamous supply-chain breach, attackers forged SAML tokens to access Microsoft 365 and Azure environments. This was a purely identity-based LOTL attack, requiring no malware to succeed.

Storm-0558

‍By stealing a Microsoft signing key, this group was able to forge tokens and use standard cloud APIs to gain access to enterprise email accounts. Around 25 organizations were affected by this high-profile breach.

UNC3886

‍Exploiting zero-day flaws in Fortinet and VMware appliances, UNC3886 persisted beneath hypervisors and bridged on-premises systems with cloud environments. Their operations combined stealthy LOTL tactics with advanced espionage tradecraft.

Operation Cloud Hopper (APT10)

‍One of the earliest and largest examples of cloud-related LOTL, APT10 leveraged managed service providers to silently access customer cloud tenants. Using valid accounts and administrative tools, they stole intellectual property at a global scale.

Why Defenders Miss Cloud LOTL

Despite its rise, cloud LOTL attacks are still underestimated. Many of the features attackers abuse are so widely used that disabling them isn’t realistic. The ephemeral nature of cloud services adds to the problem: workloads and services that are short-lived can be missed by older security tools, leaving threats undetected by security teams.

Detection and Response That Works

Defending against cloud LOTL starts with collecting the right signals. That means not just cloud audit logs, but also details about role assumptions, token use, and OAuth app changes. Runtime telemetry, like system calls, file access, and network activity, must be tied to specific libraries or processes. Monitoring data access and unusual outbound traffic is equally important.

The key is to look for behavior that doesn’t fit the norm. If a JSON parser suddenly makes a network request, or a compression library tries to read AWS credentials, something is wrong. Abnormal use of cloud SDKs or Kubernetes commands can also be signs of compromise. If new OAuth apps appear with suspicious permissions or SAML trusts are altered unexpectedly, defenders should act quickly. Once suspicious behavior is found, organizations must revoke credentials, rotate keys, disable compromised roles, isolate workloads for forensic review, and block data transfers before they leave the environment.

How Oligo Security Helps

Oligo tackles these challenges by monitoring what software and infrastructure actually does at runtime. Instead of relying on signatures or static rules, Oligo enforces behavior baselines, reducing false alarms while stopping unknown threats.

With a lightweight sensor, Oligo monitors the complete context of your cloud applications, identifying which files, sockets, and system calls each library normally uses. This lets Oligo spot when a library behaves abnormally - even if there’s no known vulnerability or CVE. 

For example, Oligo would have blocked SCARLETEEL by preventing metadata access, S3 transfers, and network calls from untrusted libraries. It would have stopped TeamTNT from creating Kubernetes jobs. In attacks like Storm-0558 and the SolarWinds follow-on, Oligo would have limited damage by preventing unusual library access to sensitive APIs. Even stealthy campaigns like Volt Typhoon would stand out when processes attempted actions outside their normal runtime patterns. Because it works inside containers, VMs and other short-lived cloud workloads, Oligo brings protection exactly where traditional security tools often can’t because they lack deep application context.

Conclusion

Cloud LOTL attacks thrive because they use the same tools organizations depend on every day. Traditional defenses, focused on malware signatures or static log analysis, cannot reliably stop attackers who hide behind valid identities and cloud APIs. What’s needed is real-time visibility into how applications actually behave - and the ability to block malicious deviations before they cause harm.

Oligo Security provides this capability by enforcing least privilege at the library level and preventing abnormal behavior in real time. With this approach, organizations can take away the stealth advantage that makes cloud LOTL so dangerous, ensuring attackers can no longer blend in with legitimate activity.

Learn more about Oligo Cloud Application Detection & Response and how to detect LOTL attacks.