What Is Cloud Jacking? Account and Resource Hijacking

A developer pushes a commit at 2 a.m. to fix a build. Buried in a config file is a long-term AWS access key, the kind that starts with AKIA. The repo is public for about forty minutes before someone notices and force-pushes it out of history. Too late. Automated scrapers watch public GitHub commits in close to real time, and within those forty minutes the key was already pulled, tested, and used to spin up a fleet of GPU instances mining cryptocurrency in a region the company never touches. The first sign anyone in the company saw was the bill.

That is cloud jacking. No malware dropped, no exploit chained, no perimeter breached. An attacker logged in with valid credentials and used the account exactly as it was designed to be used, just on their behalf instead of yours. This guide covers what cloud jacking is, the entry vectors that lead to it, what attackers do once they are in, how to detect it in your logs, and how to respond before a stolen key becomes a tenant-wide incident.

What is cloud jacking?

Cloud jacking is the hijacking of a cloud account, resource, or service by someone who is not supposed to control it. The attacker gains valid access to a tenant, an account, an identity, or an individual resource, then uses that access for their own ends: mining cryptocurrency, stealing data, moving deeper into the environment, or holding the account for ransom.

The defining trait is that the activity is authorized. A hijacked account is a legitimate account being used by the wrong person. The cloud control plane sees a valid identity making valid API calls, so nothing about the requests themselves is malformed or blocked. This is why cloud jacking maps to MITRE ATT&CK T1078 Valid Accounts, and specifically the cloud sub-technique T1078.004 Cloud Accounts: the attacker is abusing a credential the environment already trusts. There is no payload to scan for. The only thing that looks wrong is the behavior, and only if you are watching for it.

Cloud jacking is not one attack. It is a category that spans a stolen IAM user key, a phished console login, an OAuth token granted to a malicious app, a hijacked subdomain, and a compromised root account. What ties them together is the target, the cloud identity and the resources behind it, and the method, abuse of legitimate access rather than a technical exploit.

How cloud jacking happens

Every cloud jacking incident starts with the attacker obtaining access they should not have. The paths are well worn, and most of them come down to a credential that leaked, a permission that was too broad, or an authentication step that was missing.

Exposed access keys in code and repositories. This is the single most common entry vector, and it is entirely self-inflicted. Long-term AWS keys (AKIA prefix) and their secrets get committed to source files, baked into container images, pasted into CI variables, or hardcoded in mobile apps. Public repositories are scraped constantly. GitGuardian's *State of Secrets Sprawl* research has tracked tens of millions of secrets leaked to public GitHub each year, and a large share of leaked keys stay valid long after exposure because no one rotates them. This is MITRE ATT&CK T1552 Unsecured Credentials: a key sitting in a file is a key an attacker can read.

Phished or leaked console credentials. A username and password phished from an administrator, or reused from a breach dump, opens the web console directly. Without multi-factor authentication on that account, the password is the only thing standing between the attacker and the tenant. Microsoft reports that the large majority of account-takeover attacks are stopped by MFA, which is another way of saying the accounts that get jacked are overwhelmingly the ones without it.

Misconfigured IAM and over-broad permissions. A role with a wildcard policy, a user with AdministratorAccess they never needed, a trust policy that lets any account assume a role, or an instance profile that grants far more than the workload requires. Over-provisioning does not cause the initial access, but it decides how bad the access is once obtained. A misconfiguration like a security group open to 0.0.0.0/0 or a public storage bucket turns a small foothold into a wide one. These are the same class of AWS misconfigurations that surface in nearly every cloud incident review.

Token theft and OAuth abuse. Modern cloud access runs on tokens, not just passwords. An attacker who steals a session token, a SAML assertion, or a refresh token can act as the user without ever knowing the password, and often without tripping MFA, because MFA already happened when the token was issued. OAuth consent abuse is the application-layer version: a user is tricked into granting a malicious app broad permissions to their mailbox or drive, and the app keeps that access until the grant is revoked. CISA documented exactly this pattern in advisory AA21-008A, where an actor forged authentication tokens and abused OAuth applications to move through Microsoft cloud environments after an on-premises compromise.

Subdomain takeover. A DNS record, usually a CNAME, points at a cloud resource that has since been deleted: a decommissioned S3 bucket, an unclaimed app-service hostname, a expired SaaS tenant. The DNS record still resolves, but the target is gone. An attacker who claims that resource now serves content from your subdomain, which is enough to host phishing pages on a trusted name or steal cookies scoped to the parent domain.

No MFA, root account use, and standing keys. The conditions that make all of the above worse: a root or global-admin account used for daily work, long-lived access keys that are never rotated, and identities with no second factor. None of these is an attack on its own. Each one removes a barrier the attacker would otherwise have to clear.

What attackers do after the hijack

Once an attacker controls a cloud identity, what they do next depends on what the account can reach. A handful of objectives recur across almost every case.

Cryptocurrency mining (cryptojacking). The fastest way to monetize stolen cloud compute. The attacker launches expensive GPU or high-CPU instances, often in regions and accounts the victim rarely checks, and runs mining software billed to the victim. CISA defines cryptojacking as the unauthorized use of someone else's computing power to mine cryptocurrency, and the cloud version is purely financial: the attacker spends your money, you get the invoice. This is MITRE ATT&CK T1496 Resource Hijacking.

Data theft. If the hijacked identity can read storage buckets, databases, or secrets, the attacker copies them out. Stolen cloud credentials are one of the most direct routes to a data breach, because the account often has legitimate read access to exactly the data the attacker wants, with no exploit required to reach it.

Lateral movement across the tenant. A single compromised identity is rarely the goal. The attacker enumerates what the credential can do, assumes other roles, reads secrets that unlock further access, and pivots from one account to another inside the same organization. Cloud IAM trust relationships, designed to let services talk to each other, become the attacker's map.

Resource abuse and abuse-for-hire. Beyond mining, hijacked accounts get used to send spam, host malware, proxy other attacks, or stand up infrastructure that is hard to attribute because it sits inside a legitimate organization's cloud.

Ransom and destruction. Some attackers change the root credentials, delete backups, encrypt or wipe storage, and demand payment to restore access. Because they hold valid administrative control, they can lock the legitimate owner out of their own tenant.

Cloud jacking entry vectors, impacts, and controls

The vectors, what they enable, and the control that closes each one. Most of the controls are cheap; the cost is in doing them consistently.

How to detect cloud jacking

Because the attacker uses valid credentials, detection is about behavior, not signatures. The control plane log is where this lives. In AWS that is CloudTrail, which records the API calls made by every identity in the account and is the primary audit trail for spotting an account being used by the wrong person. The equivalent exists in every major cloud. Watch for these patterns.

Impossible travel and anomalous logins. The same identity authenticating from two distant locations in a window too short to physically travel, or a login from a country, ASN, or device the account has never used. A console login for a service account that only ever uses API keys is its own red flag.

Anomalous API calls. Activity that does not fit the identity's history: a read-only analyst calling RunInstances, a workload role suddenly enumerating IAM, calls to regions the account never operates in, or a burst of DescribE and List calls that looks like reconnaissance. AWS GuardDuty raises findings for this class of behavior, including credential exfiltration findings such as UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS and anomalous-behavior findings on IAM users.

New access keys, users, and roles. One of the first things an attacker does is establish persistence. A new IAM user created by an unexpected identity, a fresh access key minted on an existing user, a new role with a permissive trust policy, or login profiles added to service accounts are all high-signal events.

Spend and resource spikes. A sudden jump in compute cost, instances launched in unused regions, or a spike in expensive instance types is the classic cryptojacking signature. GuardDuty flags this directly with findings like CryptoCurrency:EC2/BitcoinTool.B. Billing anomaly alerts are a crude but effective backstop when nothing else fires.

CloudTrail anomalies. Disabled logging, deleted trails, changes to GuardDuty or security configurations, and gaps in the log are signs an attacker is covering their tracks. An identity that turns off the very logging that would catch it is acting like an intruder, not an admin. Mature programs feed all of this into cloud detection and response, correlating control-plane signals into a single picture rather than chasing isolated alerts.

How to prevent and respond to cloud jacking

Prevention is about removing the conditions that make hijacking easy. Response is about speed, because a stolen key is being used within minutes of exposure.

On prevention, the controls are unglamorous and they work:

• MFA everywhere, phishing-resistant for admins. A password alone is not a control. Require a second factor on every human identity, and use hardware or passkey factors for privileged accounts so a phished password is not enough.
• Least privilege. Grant the minimum each identity needs, remove unused permissions, and scope roles to specific workloads. This does not stop the initial access, but it shrinks what an attacker gets from it.
• Kill long-term keys. Prefer short-lived, automatically rotated credentials over static AKIA keys. Where static keys are unavoidable, rotate them on a schedule and alert on their use from unexpected sources.
• Secrets scanning. Run automated secret detection in CI pipelines and across repositories so a committed key is caught before it ships, and treat any committed secret as already compromised.
• Conditional access. Gate authentication on device posture, location, and risk signals so a valid credential from a hostile context is still challenged or denied.
• Lock away root and break-glass. The root account and global admins should not be used for daily work. Protect them with hardware MFA, monitor every use, and store break-glass credentials offline.

On response, three things matter most:

• Revoke fast. The moment a key or session is suspected of being compromised, deactivate the access key, revoke active sessions and tokens, and rotate the credential. Speed beats thoroughness here; a key disabled in two minutes ends the incident, a key disabled in two hours does not.
• Scope the blast radius. Pull CloudTrail and identity logs to determine everything the credential touched: what it read, what it created, what other roles it assumed. Assume any resource the identity could reach is in scope until you prove otherwise.
• Rebuild trust, not just access. Remove attacker-created users, keys, and roles. Restore from clean backups if data was altered. An account that was fully hijacked should be treated as untrusted until every persistence mechanism is found and removed.

The bottom line

Cloud jacking is hijacking by legitimate access. The attacker does not break in, they log in, using a key that leaked, a password that was phished, or a token that was stolen, and then they use the account exactly as it was built to be used. The most common door is an exposed access key, and the most common payoff is a mining bill, data theft, or a path deeper into the tenant.

The defense is not exotic either. MFA on every identity, least privilege so a stolen credential reaches little, no long-term keys lying around, secrets scanning so a committed key never ships, and behavioral monitoring of the control plane so an account used by the wrong person stands out. When it happens anyway, revoke fast and scope the blast radius from the logs. The same discipline that keeps credentials tight is the one that produces the evidence to clean up after the few that slip.