What Is Cloud Service Provider Abuse?

In late 2020, the actor tracked as APT29 did not breach its downstream victims by attacking their front doors. It went through their suppliers. By compromising a managed service provider and the cloud identities that provider used to administer customer tenants, the actor inherited legitimate, trusted access into many organizations at once. No exploit was needed against the victims themselves. The provider's access was the exploit. Microsoft and federal responders spent months mapping the forged tokens, the added cloud credentials, and the tenant-to-tenant pivots that followed.

That is cloud service provider abuse: turning the trust an organization places in its cloud provider, reseller, or managed service partner into an attack path. This guide covers what the term means, the common vectors attackers use, how a single trusted relationship becomes access to many tenants, and how a defender detects and limits it.

What is cloud service provider abuse?

Cloud service provider abuse is the use of a cloud provider's own capabilities, infrastructure, and trusted relationships to attack an organization, rather than attacking that organization directly. The attacker leverages something the target already trusts: the provider's administrative access, the provider's clean IP space and bandwidth, a reseller's tenant permissions, or the shared platform itself.

The defining trait is misplaced trust. A customer trusts its cloud service provider (CSP) to administer infrastructure. A provider trusts its support accounts to reach customer tenants. The platform trusts traffic that originates from inside its own network. Each of those trust relationships is legitimate and necessary, and each one is an attack surface when the entity on the trusted side is compromised or malicious.

This maps cleanly to MITRE ATT&CK T1199 Trusted Relationship: an adversary breaches or otherwise leverages an organization that has access to the intended victim, such as an IT services provider or managed service provider, and abuses that existing access. The cloud version is potent because one provider relationship often fans out to dozens or hundreds of customer tenants. Abuse of the platform's own resources, separately, is the second half of the term: a hijacked account is used to mine cryptocurrency, send spam, or run DDoS from infrastructure the platform considers trusted.

So the phrase covers two related ideas. Abuse of the trust chain (provider to customer, reseller to tenant) and abuse of the platform's resources (compute, bandwidth, reputation) once an account inside it is controlled. Both rely on legitimacy rather than a software flaw.

Common cloud attack vectors

Attackers abuse cloud providers through a small set of recurring vectors. Most start with a credential or a trust relationship rather than a vulnerability.

Compromised provider and reseller access. A managed service provider, cloud reseller, or IT services firm holds standing administrative access into its customers' tenants. Compromise the provider once and that access becomes the attacker's. This is the highest-leverage vector because it is one-to-many: the support account that lets a provider manage a hundred customers lets an attacker reach a hundred customers.

Phished and stolen cloud credentials. Phishing a console login or stealing a session token gives an attacker a valid identity in the platform. Without a second factor, a phished password is the whole barrier. Once inside, the attacker is just another authenticated user making API calls the control plane already trusts.

Brute force and credential stuffing. Exposed cloud login endpoints get hit with credential stuffing using passwords from prior breach dumps, and with dictionary or password-spray attacks against accounts that lack lockout and MFA. Cloud bandwidth makes the attempts cheap and fast.

Resource hijacking for mining, spam, and DDoS. Once an account is controlled, the platform's compute and bandwidth become a weapon. Attackers spin up expensive instances to mine cryptocurrency on the victim's bill, send spam and host phishing pages from the provider's reputable IP space, and launch DDoS traffic from hijacked accounts or abused free trials. The platform's reliability is exactly what makes it attractive.

OAuth and token abuse. Modern cloud access runs on tokens. An attacker who steals a session or refresh token, or tricks a user into granting a malicious app broad permissions, acts as that identity without the password and often without re-triggering MFA, because the factor was already satisfied when the token was issued.

Malicious insiders. A provider or customer employee with legitimate cloud access can abuse it directly, copying data or standing up unauthorized resources. The trust is real; the use is not.

How cloud service provider abuse works

A trusted-relationship attack follows a recognizable arc. The provider is the entry point, the cloud identity layer is the pivot, and the downstream tenants are the prize.

It starts with the provider, not the victim. The attacker compromises the service provider or reseller, often through phishing or stolen credentials, and lands on an account that already has access to customer environments.

From there the attacker uses the identity layer. They forge or steal tokens, add credentials to existing service principals, and grant themselves additional cloud roles so the access survives a password reset. In ATT&CK terms this is T1098 Account Manipulation, including T1098.001 Additional Cloud Credentials and T1098.003 Additional Cloud Roles. The goal is durable, legitimate-looking access.

Then they escalate and pivot. The attacker pursues privilege escalation toward global administrator, because a global admin in the provider's directory can reach the tenants that directory manages. With elevated rights, lateral movement shifts from the provider's own assets into one customer tenant after another, each pivot using access the platform treats as authorized. This is the vertical propagation that makes provider compromise so damaging: one foothold, many downstream victims.

APT29, tracked by MITRE as G0016, ran exactly this play during the 2020 to 2021 SolarWinds-related campaigns. The actor abused trusted relationships (T1199), forged authentication tokens and added cloud credentials and roles (T1098), and used valid cloud accounts (T1078.004) to move through Microsoft cloud environments after an initial on-premises or provider compromise. CISA documented the cloud portion in advisory AA21-008A.

The throughline is that every step uses legitimate mechanisms. There is no malware signature to catch. The provider's access, the added role, the valid token, and the tenant pivot are all things the platform is designed to allow. Only the context is wrong.

Cloud service provider abuse vectors, impacts, and controls

The vectors, what each one buys the attacker, and the control that closes it. None of the controls is exotic; the cost is in applying them across every provider relationship.

How to detect cloud service provider abuse

Because the attacker uses valid identities and trusted access, detection is about behavior, not signatures. The cloud audit and identity logs are where this lives.

Anomalous provider and cross-tenant activity. Administrative actions from a service provider at an unusual time, from a new location, or against a tenant the provider rarely touches. Delegated admin sessions that suddenly enumerate or change many tenants are a strong signal of one-to-many abuse.

Identity and role changes. New credentials added to an existing service principal, new privileged or cloud-admin role grants, and login profiles added to accounts that only ever used API keys. These are the persistence steps (T1098) and they are high-signal because they rarely happen outside provisioning.

Impossible travel and anomalous logins. The same identity authenticating from two distant locations in a window too short to travel, or a sign-in from a country, ASN, or device the account has never used. A console login for a non-interactive service account is its own red flag.

Resource and spend anomalies. A sudden jump in compute cost, instances launched in unused regions, or a spike in expensive instance types is the classic resource-hijacking signature, mapping to T1496 Resource Hijacking and its T1496.001 Compute Hijacking sub-technique. Unusual outbound traffic from critical assets can indicate spam, DDoS, or data exfiltration.

Logging tampering. Disabled audit trails, deleted log sinks, and changes to security configurations mean someone is covering their tracks. An identity that turns off the logging that would catch it is behaving like an intruder.

Mature programs feed these signals into cloud detection and response, correlating control-plane events across provider and customer tenants rather than chasing isolated alerts. Threat hunting here leans on indicators of attack, the behavioral patterns of provider abuse, rather than waiting for a static indicator of compromise.

How to prevent and respond to cloud service provider abuse

Prevention is about constraining trust before it is abused. Response is about cutting off provider access fast and proving what it reached.

On prevention:

• Treat the shared responsibility model as a checklist, not a slogan. Under the AWS, Azure, and Google Cloud shared responsibility models, the provider secures the platform and you secure your identities, data, and configuration. Know exactly which side owns each control so nothing falls in the gap.
• Scope provider access tightly. Give a managed service provider or reseller the least privilege it needs, per customer, and remove standing global access. The smaller the delegated rights, the smaller the one-to-many blast radius if the provider is compromised.
• MFA everywhere, phishing-resistant for admins. Require a second factor on every human identity, including provider accounts, and use hardware or passkey factors for privileged and global-admin roles.
• Monitor identities and privileged changes. Alert on new service-principal credentials, new cloud-role grants, and privileged sign-ins. These are the manipulation steps that turn a foothold into durable access.
• Watch critical assets for unusual outbound communication. Egress spikes, traffic to new destinations, and billing anomalies surface mining, spam, DDoS, and exfiltration that ride on trusted infrastructure.
• Build a cloud incident response playbook aligned to the shared responsibility model. Know in advance what you can act on, what the provider must act on, and how to engage them, and train the SOC on cloud-specific investigation.

On response:

• Cut provider and delegated access first. When a provider compromise is suspected, suspend delegated admin sessions and revoke the provider's tokens and credentials before anything else. That ends the one-to-many pivot.
• Hunt the persistence. Look for added service-principal credentials, new role assignments, and created cloud accounts across every affected tenant, not just the first one found. Trusted-relationship attacks fan out, so scope must too.
• Rebuild trust, not just access. Remove attacker-added credentials, roles, and accounts, restore altered data from clean backups, and treat any tenant the provider could reach as in scope until proven clean.

Frequently Asked Questions

What is cloud service provider abuse in simple terms?

Cloud service provider abuse is when an attacker exploits the trust placed in a cloud provider, reseller, or managed service partner, or the provider's own infrastructure, to attack an organization indirectly. Instead of breaking into the victim directly, the attacker rides in on access the victim already trusts, or uses the platform's compute and bandwidth for mining, spam, or DDoS.

How is cloud service provider abuse different from a direct cloud attack?

A direct attack targets the victim's own systems, credentials, or misconfigurations. Cloud service provider abuse targets the trust relationship instead: the attacker compromises a provider or reseller that already has access to the victim, then inherits that access. One provider relationship can fan out to many customer tenants, which is what makes it so damaging.

Why are managed service providers a target for this?

A managed service provider holds standing administrative access into many customer tenants at once. Compromising the provider once gives an attacker a one-to-many path into all of those customers without attacking any of them directly. This vertical propagation is why provider compromise appears in major campaigns.

What MITRE ATT&CK techniques map to cloud service provider abuse?

The core technique is T1199 Trusted Relationship. Related techniques include T1078.004 Valid Accounts: Cloud Accounts, T1098 Account Manipulation with its T1098.001 Additional Cloud Credentials and T1098.003 Additional Cloud Roles sub-techniques, and T1496 Resource Hijacking for mining and other resource abuse.

How do you detect cloud service provider abuse?

Watch behavior in the cloud audit and identity logs. Key signals include anomalous cross-tenant administrative activity from a provider, new service-principal credentials or privileged role grants, impossible-travel logins, spend and egress spikes from resource hijacking, and tampering with logging. Correlating provider and customer tenant events is essential because the attack spans both.

What is the single most effective control against it?

Scoping and monitoring provider and delegated administrative access. Removing standing global access and applying least privilege per customer shrinks the one-to-many blast radius, and alerting on cross-tenant and privileged-role changes catches the abuse early. MFA on every identity, including provider accounts, is the close second.

The bottom line

Cloud service provider abuse is an attack through the trust chain, not the front door. The attacker compromises a provider, reseller, or partner that the victim already trusts, inherits that legitimate access, and either pivots into many downstream tenants or turns the platform's own compute and bandwidth into a weapon. Because every step uses authorized mechanisms, there is no payload to scan for; the only thing wrong is the context.

The defense is to constrain trust before it is abused. Scope provider access to least privilege per customer, put MFA on every identity including the provider's, alert on new credentials and role grants, and watch for cross-tenant and resource anomalies. Know which side of the shared responsibility model owns each control, and have a playbook that lets you cut provider access in minutes. When the trusted side is the threat, the only defense is to have limited what that trust could ever reach.