When Hackers Run Up Your Cloud Bill

Over US$750,000 in Charges on Your Hacked Cloud Account in Just Four Days

A cloud account can give an attacker access to something as valuable as confidential information. It can give them the ability to consume expensive services at someone else's expense. For an individual developer or a small company, the resulting invoice can become a financial emergency long before anyone finishes investigating the intrusion. A recently reported South Korean case shows how serious that exposure can become.

A case made public on 17 October 2026 involved a customer who used Amazon's cloud through a Korean reseller and normally spent about KRW 80 a day. In October 2024, unauthorized activity generated more than KRW 1 billion in charges over four days, involving computing activity across at least eight countries. Cryptocurrency mining was suspected, but the entry method remained unknown. After objections, the bill was reduced to approximately KRW 400 million.

The Consumer Dispute Settlement Commission reportedly decided in July 2026 that the customer had no payment obligation, citing insufficient grounds to attribute the incident to his negligence and the reseller's delayed recognition of the spending surge. The reseller rejected the decision. Amazon described it as a matter between the reseller and customer, while the reseller said it was seeking to minimize the customer's burden. These remain reported findings and positions, rather than a publicly examined forensic record.

The unresolved dispute deserves attention beyond the size of the invoice. An account with negligible normal spending was apparently able to generate extraordinary charges before effective intervention. The practical question is how much financial damage an intruder can cause between gaining access and being stopped, and who is responsible for shortening that interval.

When criminals obtain cloud credentials with sufficient permissions, they can use legitimate service interfaces to launch computing resources or consume paid services. The underlying infrastructure may operate exactly as designed. The account's permissions allow the activity, and the billing system records the consumption. Compromise of a customer's account does not, by itself, establish that the cloud provider's infrastructure was breached.

This creates an uncomfortable incentive. An attacker can earn money from stolen computing capacity while leaving the resource costs with the account holder. Cryptocurrency mining is one example. Paid AI services create another. The value of an account therefore depends partly on what it can purchase or run, even when it contains little sensitive information and has almost no historical usage.

Sysdig's May 2024 research into LLMjacking documented attackers using stolen cloud credentials to probe access to hosted language models. The researchers identified evidence consistent with reselling access and calculated that one worst-case consumption scenario could exceed USD 46,000 per day. That figure was a model based on prices and quotas at the time, not a confirmed loss in the Korean case or a current universal estimate. The broader mechanism is well established. Criminals can monetize access while someone else receives the usage charges.

There are sound reasons to expect further attempts of this kind. The financial incentive already exists, and attackers can automate the use of compromised accounts. AI may increase their efficiency. The UK National Cyber Security Centre's assessment through 2027 expects AI to improve elements of intrusion activity and increase the frequency and intensity of cyber threats. That is a broader threat assessment, not a forecast specifically measuring cloud billing fraud.

The growing exposure also comes from how legitimate users work. Connecting software, development tools and AI applications to paid services creates additional credentials and permissions to manage. Each connection deserves a practical review of what it can authorize. A key used by a small application should not automatically carry the power to launch expensive infrastructure elsewhere or administer the entire account.

AWS's identity security guidance recommends temporary credentials, least-privilege permissions and multi-factor authentication, including phishing-resistant methods where possible. These controls address different weaknesses. Protecting a console login with MFA does not automatically make every separately issued API key safe. Organizations must review machine access, remove unused credentials and limit the permissions available to software as carefully as they protect human administrators.

Financial controls require the same precision. A budget notification is not a guarantee that spending stops at the stated amount. AWS's standard Budgets documentation says budget information is updated up to three times daily, typically eight to twelve hours after the previous update. It also warns that charges can exceed a notification threshold before an alert arrives. Budget actions can restrict further provisioning, but their design and timing must be understood. An email discovered the following morning may arrive after substantial consumption.

It would also be inaccurate to claim that AWS offers no spending limits. Its current documentation for project spend limits describes controls that pause a project when its limit is reached, while warning that the new experience is available only to a limited number of customers. Customers should verify availability and scope for their actual account and reseller arrangement. Today's documented capabilities cannot be assumed to have existed in the same form when the Korean incident occurred in 2024.

The appropriate design depends on the workload. A personal experiment can often tolerate suspension at a modest spending threshold. A production service may require a more selective response that blocks suspicious new deployments while preserving essential operations. Restricting unnecessary services and regions, separating experimental accounts from production, and protecting changes to spending controls can reduce exposure. An attacker should not be able to remove the financial safeguards using the same compromised identity that triggers them.

Monitoring also needs to connect cost with behavior. Unfamiliar deployments, unexpected credential creation and sudden use of previously unused services can justify investigation before a billing threshold is crossed. Amazon GuardDuty includes detection capabilities for compromised credentials and unauthorized cryptocurrency mining. Detection still requires an accountable responder with authority to act. Customers and resellers should agree in advance who receives urgent alerts, who can restrict access, and how suspicious activity is handled outside business hours.

Reseller arrangements make those responsibilities especially important. A customer may assume that buying through a local provider includes active monitoring, while the actual agreement covers billing and routine support. That possibility should be resolved before an incident through explicit service terms. The contract should identify the security services purchased, the customer's remaining responsibilities, and the process for stopping suspected abuse and disputing its charges. The Korean report does not provide enough contractual detail to determine every party's obligations independently.

AWS's shared responsibility model describes how security duties are divided between the provider and customer, with the customer's obligations varying by service. That framework is useful for designing controls. Determining liability for a disputed invoice still requires examination of the relevant contract, applicable law and evidence. Possession of valid credentials does not establish that the customer knowingly authorized every action performed with them.

The mediation outcome must also be described accurately. The Korea Consumer Agency explains that an accepted mediation decision has judicial effect. A rejected proposal should not be presented as an enforceable court judgment that a company simply ignored. Even so, the reported outcome exposes a practical weakness. A customer can obtain a favorable assessment and still face a prolonged dispute over an amount far beyond their ordinary spending.

A better policy response would make unauthorized cloud consumption a clearly defined incident category. Providers and resellers should preserve relevant evidence, explain how disputed charges were calculated, and offer a transparent review process. Temporarily suspending collection of genuinely disputed charges during investigation deserves consideration, alongside safeguards against fraudulent claims. Technical reviews should examine the customer's security practices and whether other parties met their agreed monitoring and response duties.

For customers facing an active compromise, containment and evidence preservation must proceed together. AWS's response guidance calls for addressing exposed credentials, reviewing unauthorized identity changes and checking resources across all regions. Teams should retain relevant logs and billing records while stopping abusive consumption, coordinate with the provider and reseller, and verify that unauthorized access has been removed. Changing the login password alone may leave API credentials or attacker-created identities usable.

Cloud security reviews should therefore include a question that ordinary budget planning can miss. How much could a compromised identity spend before the organization detects the activity and stops it? Answering that question requires tested controls and clear response authority. Until those are in place, a low monthly bill can conceal a much larger financial exposure, and the consequences of a stolen credential may continue long after the attacker has gone.