Table of contents
- What is a cloud breach without malware
- The concept of living off the cloud
- The role of identities in the cloud
- Tokens and session hijacking
- Misconfigurations: the real weak point
- Cloud API abuse
- Persistence without malware
- Lateral movement in the cloud
- Logging and detection: why these attacks are difficult to detect
- Advanced defense strategies
- Token rotation and credential management
- Micro-segmentation and context-aware access
- Automation and incident response
- Real case: compromise of a Microsoft 365 tenant
In recent years, cloud security has radically transformed the entire cyber security landscape.. Until not long ago, the concept of a cyber attack was mainly associated with the presence of malware, viruses, or obvious exploits. Today, however, the scenario is completely different. Increasingly, attackers are able to compromise cloud infrastructures without installing any malicious software, relying exclusively on misconfigurations, access tokens, and legitimate APIs.
This type of attack is commonly referred to as living off the cloud, an evolution of the living off the land concept already known in on-premise systems. The idea is simple yet extremely effective: using tools and functionalities already present in the target environment to move laterally, maintain persistence, and access data.
In this article, we will analyze in depth what a cloud breach without malware really means, how a tenant is compromised, which techniques are most commonly used by attackers, and, above all, how to defend effectively. We will do so through concrete examples, realistic scenarios, and even code, to truly understand the logic behind these advanced attacks.
What is a cloud breach without malware
When we talk about a cloud breach, we refer to the compromise of a cloud environment, such as a Microsoft 365 tenant, AWS, or Google Cloud. Traditionally, one might imagine an attack involving malware, exploits, or software vulnerabilities. However, in the modern model, none of this is often required.
A malware-free attack is based on three fundamental pillars:
- misconfigurations
- compromised credentials
- API abuse
This means that the attacker does not need to break into the system, but simply use it more effectively than its legitimate owner.
Imagine an environment where a user has excessive privileges, or an application has access to more resources than necessary. In these cases, an attacker can gain access and move undetected, without ever generating behavior that appears anomalous in a traditional sense.
The concept of living off the cloud
The living off the cloud paradigm represents one of the most sophisticated evolutions in offensive security. The attacker does not introduce external elements but instead exploits the native functionalities of the cloud provider.
This approach offers several advantages:
- reduces the detection surface
- avoids the use of suspicious files
- leverages tools considered trustworthy
In practice, if an attacker uses the official APIs of Azure or AWS, the generated traffic will be indistinguishable from legitimate activity, unless analyzed with very advanced techniques.
Example
The use of Microsoft Graph APIs to access emails, files, and identities. There is no malware and no exploit, only perfectly valid API calls.
The role of identities in the cloud
In modern cloud environments, the true security perimeter is no longer the network, but identity. This means that compromising an account is effectively equivalent to compromising the entire environment.
Identities can be exploited in several ways:
- direct access with stolen credentials
- use of OAuth tokens
- abuse of service principals
One of the most critical aspects is that many cloud systems use long-lived tokens, which allow persistent access without the need to re-enter credentials.
Here is an example of an API request using an OAuth token:
curl -X GET https://graph.microsoft.com/v1.0/me/messages \
-H “Authorization: Bearer ACCESS_TOKEN”
If an attacker manages to obtain this token, they can access email without needing the password.
Tokens and session hijacking
Tokens represent one of the most vulnerable elements in cloud environments. Unlike passwords, they are often not protected by multi-factor authentication and can be reused.
A typical attack involves:
- phishing or token theft
- using the token for API access
- privilege escalation
In many cases, the token is stored in the browser or in local applications. If an attacker manages to intercept it, they can impersonate the user.
Example of using an AWS token:
aws s3 ls –access-key ACCESS_KEY \
–secret-key SECRET_KEY \
–session-token SESSION_TOKEN
This command allows direct access to resources without additional authentication.
Misconfigurations: the real weak point
One of the most common factors in cloud breaches without malware is the presence of misconfigurations. These may include:
- public buckets
- overly permissive IAM roles
- exposed APIs
Example
An S3 bucket configured as public can expose sensitive data without any technical breach.
Here is an example of a misconfigured policy:
{
“Effect”: “Allow”,
“Principal”: “*”,
“Action”: “s3:GetObject”,
“Resource”: “arn:aws:s3:::example-bucket/*”
}
This configuration allows anyone to read the files in the bucket.
Cloud API abuse
APIs are the core of the cloud. Everything flows through them: user management, data access, and service configuration.
An attacker can use APIs to:
- enumerate resources
- create new users
- modify configurations
Example using Azure CLI:
az ad user list –output table
This command returns the list of users, which is useful for identifying privileged targets.
Persistence without malware
One of the most dangerous aspects is the ability to maintain access over time without installing anything.
Techniques include:
- creating new users
- adding API keys
- registering OAuth applications
Example
az ad app create –display-name “backup-access”
This application can be used to access data even after the compromised user has been removed.
Lateral movement in the cloud
In cloud environments, lateral movement occurs primarily through identities and roles.
An attacker may:
- assume IAM roles
- exploit trust relationships
- access cross-account resources
aws sts assume-role \
–role-arn arn:aws:iam::123456789012:role/Admin \
–role-session-name attack-session
This allows the attacker to obtain elevated privileges.
Logging and detection: why these attacks are difficult to detect
One of the main challenges of living off the cloud attacks is the difficulty of detection. Unlike traditional attacks, which often introduce external elements such as malware, suspicious scripts, or exploits, in this case everything happens using tools that are perfectly legitimate and expected by the system. This makes it extremely difficult to distinguish between normal activity and malicious activity.
Activities appear legitimate:
- access via official APIs
- use of valid credentials
- no suspicious files
For this reason, security must evolve toward:
- behavioral analysis
- identity monitoring
- event correlation
The key point is that, in the cloud, the attack surface almost completely overlaps with the operational surface. Everything an administrator can do, an attacker can also do if they gain access. There is no longer a clear distinction between legitimate and illegitimate behavior based on the tools used, because the tools are the same.
Another element that complicates detection is the standardization of cloud operations. APIs are designed to be used in an automated and large-scale manner. This means that even potentially dangerous operations, such as creating users or modifying privileges, can occur hundreds of times per day in complex environments. In this context, identifying a single malicious action becomes like finding a needle in a haystack.
Example
It can help clarify this concept. Suppose an attacker uses APIs to list all available resources in a tenant:aws ec2 describe-instances
This operation is identical to one performed by an administrator during normal management activities. Without proper context, it is impossible to distinguish between the two.
Another critical factor is the lack of visibility into intent. Logging systems record what was done, but not why it was done. This means that even sequences of seemingly harmless actions can hide a structured attack. For example:
- account access
- file access
- creation of a new application
Individually, these operations are normal. But when executed in sequence and in an anomalous context, they may indicate a compromise.
A frequently underestimated issue is detection latency. Many security systems analyze logs in batch mode or with significant delays. In a cloud attack, however, everything happens very quickly: an attacker can gain access, establish persistence, and begin data exfiltration within minutes. If detection arrives too late, the damage has already been done.
Moreover, more sophisticated attackers adopt techniques to further reduce the likelihood of detection. These include:
- performing low-frequency actions to avoid anomalous spikes
- operating during working hours consistent with the compromised user
- accessing from IP addresses that are similar or geographically plausible
These strategies make it even more difficult to identify suspicious behavior using static rules.
Another fundamental issue is log fragmentation. In many cloud environments, data is distributed across different systems:
- authentication logs
- API logs
- application logs
- network logs
If these data sources are not centralized and correlated, it becomes nearly impossible to reconstruct a complete attack chain. An isolated event is almost never sufficient to generate a meaningful alert.
To address these challenges, it is necessary to adopt an approach based on advanced telemetry and contextualization. It is not enough to know that an action was performed, you must know who performed it, when, from where, and in what sequence relative to other actions.
For example, an advanced system might detect that:
- a user logs in from a new location
- a few minutes later creates a new API key
- subsequently accesses large volumes of data
This sequence, when analyzed as a whole, represents a clear indicator of compromise.
Finally, it is important to emphasize that the difficulty of detection is not only a technical issue but also an organizational one. Many companies have not yet developed the necessary skills to effectively analyze cloud logs. Without a well-trained team and appropriate tools, even the best technologies risk being ineffective.
In conclusion, living off the cloud attacks are difficult to detect because they do not violate system rules, they exploit them intelligently. For this reason, defense must shift from an approach based on signatures and static indicators to a dynamic model based on behavior, context, and correlation. Only in this way is it possible to identify threats that, at first glance, appear indistinguishable from normal operations.
Advanced defense strategies
Defending against cloud breach without malware attacks requires a profound shift in mindset compared to traditional security. It is no longer about blocking malicious files or detecting obvious threats, but about understanding and rigorously governing the legitimate use of cloud resources. Living off the cloud attacks exploit exactly what should be allowed: valid access, official APIs, and seemingly correct configurations.
For this reason, defense strategies must focus on three fundamental pillars: least privilege, token management, and continuous monitoring, while also being integrated into a broader architecture based on identity, context, and behavior.
Least privilege principle: beyond theory
The least privilege principle is often mentioned, but rarely implemented correctly. In a complex cloud environment, it means ensuring that every identity user, service, or application has access only to the resources strictly necessary and only for the time strictly required.
The real problem is that many cloud environments grow rapidly and accumulate privileges over time. A user who initially needed administrative access may no longer require it, yet still retains those permissions. This creates a massive attack surface.
An advanced approach includes:
- Just-In-Time (JIT) access
elevated privileges are granted only temporarily - Just-Enough-Access (JEA)
access is limited to specific operations - Role segregation (advanced RBAC)
Example of a more restrictive AWS policy compared to full access:
{
“Effect”: “Allow”,
“Action”: [
“s3:GetObject”
],
“Resource”: “arn:aws:s3:::company-data/reports/*”
}
Here, access is limited to reading a specific folder, avoiding unnecessary exposure.
Another example in Azure (limited role assignment):
az role assignment create \
–assignee user@example.com \
–role “Reader” \
–scope /subscriptions/xxxx/resourceGroups/prod-rg
In this case, the user can only read resources within a specific group, with no ability to modify them.
Token rotation and credential management
In the context of malware-free attacks, tokens represent the most critical element. Unlike passwords, they are often not managed with the same level of attention and can remain valid for long periods.
An attacker who obtains an OAuth token or an API key can access resources without being detected, especially if API traffic is considered legitimate.
To mitigate this risk, it is essential to:
- implement short-lived tokens
- use controlled refresh tokens
- automatically revoke unused tokens
- adopt Managed Identity wherever possible
Example in AWS: generating temporary credentials using STS:
aws sts get-session-token –duration-seconds 3600
This command limits the token’s validity to one hour, drastically reducing the attack window.
Example of token revocation in Azure:
az account revoke-session –user user@example.com
Another advanced approach is the use of a secrets manager, avoiding manual key handling entirely:
aws secretsmanager get-secret-value –secret-id my-secret
In this way, credentials are never hardcoded into the code.
Continuous monitoring and behavioral detection
Continuous monitoring is probably the most important element in defending against living off the cloud attacks. Since the attacker’s actions are often indistinguishable from legitimate ones, it is necessary to analyze behavior, not just individual events.
An advanced detection system must be able to identify:
- logins from anomalous locations
- unusual API usage
- sudden privilege escalation
- suspicious creation of new identities
Example: query on AWS CloudTrail logs to detect anomalous activity:
{
“eventName”: [“CreateUser”, “AttachRolePolicy”],
“sourceIPAddress”: “0.0.0.0/0”
}
Or in Azure using Kusto Query Language (KQL):
SigninLogs
| where Location != “Italy”
| where ResultType == 0
| project UserPrincipalName, IPAddress, Location, TimeGenerated
This query identifies successful logins from unusual locations.
Another useful example is detecting the creation of suspicious OAuth applications:
AuditLogs
| where OperationName == “Add service principal”
| project TargetResources, InitiatedBy, TimeGenerated
Micro-segmentation and context-aware access
A natural evolution of the least privilege principle is micro-segmentation, which further restricts access based on context:
- IP address
- device
- time
- risk level
The policy you mentioned is a classic example of IP-based access control:
{
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"IpAddress": {
"aws:SourceIp": "192.168.1.0/24"
}
}
}This policy denies any access if the request does not originate from a specific network. It is effective, but not sufficient on its own.
A more advanced approach combines multiple conditions:
{
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"NotIpAddress": {
"aws:SourceIp": "192.168.1.0/24"
},
"Bool": {
"aws:MultiFactorAuthPresent": "false"
}
}
}Here, access is denied if:
- the IP is not authorized
- MFA is not present
Automation and incident response
An often underestimated aspect is automated response. In a cloud attack, speed is everything. If an attacker creates a token or a new identity, every minute counts.
It is essential to implement:
- automated playbooks (SOAR)
- immediate revocation of suspicious privileges
- resource isolation
Example: automatic revocation of a suspicious IAM access key:
aws iam update-access-key \
–access-key-id ABC123 \
–status Inactive
Or deletion of a compromised user:
aws iam delete-user –user-name compromised-user
Toward identity-driven security
All these strategies converge toward an identity-driven security model, in which:
- every access is verified
- every action is tracked
- every anomaly is analyzed
There is no longer a “trusted internal” and a “dangerous external.” There is only a continuous flow of requests that must be validated in real time.
Operational conclusion
Protecting a cloud environment from malware-free attacks means accepting a fundamental truth: you can no longer trust appearances. A valid access is not necessarily legitimate.
For this reason, an effective strategy must combine:
- strict privilege control
- dynamic credential management
- advanced behavioral monitoring
- automated response
Only in this way is it possible to counter attacks that leave no obvious traces, yet can completely compromise a tenant using only what is already available.
Zero Trust and cloud security
The Zero Trust model is essential to counter these types of attacks.
The key principles are:
- always verify
- never trust
- continuously monitor
This means that every access must be authenticated and authorized, regardless of its origin.
Real case: compromise of a Microsoft 365 tenant
Let’s imagine a real-world scenario:
- phishing → credential theft
- login → token generation
- OAuth app creation
- persistent access to data
No malware, no exploit, just intelligent use of cloud functionalities.
The future of cloud attacks
Cloud attacks will become increasingly invisible. The use of AI and automation will allow attackers to:
- analyze configurations
- exploit weaknesses
- move rapidly
One of the biggest challenges in modern cyber security
The concept of cloud breach without malware represents one of the most important challenges in modern cyber security. Living off the cloud attacks demonstrate that there is no need to break a system to compromise it, just understand it better than its owner.
For this reason, security must evolve. It is no longer enough to protect the network or install antivirus software. A new approach is required, based on identities, configurations, and continuous monitoring.
Questions and answers
- What is a cloud breach without malware?
It is the compromise of a cloud environment without the use of malicious software. - What does living off the cloud mean?
It means exploiting legitimate tools and APIs of the cloud to carry out attacks. - Are tokens dangerous?
Yes, because they can be reused without authentication. - Can APIs be used for attacks?
Yes, if abused they can enable unauthorized access. - What is a tenant?
It is an isolated environment within a cloud service. - How can these attacks be prevented?
Through identity control and continuous monitoring. - Is malware still used?
Yes, but increasingly less in advanced cloud environments. - What is Zero Trust?
A model that does not trust any access by default. - Are AWS and Azure vulnerable?
Not directly, the real issue lies in misconfigurations. - What is the main risk?
Undetected and persistent access to data.
