Resource Hijacking
Resource hijacking uses an accessed system's compute or other capacity for an unauthorized purpose.
What it means
Resource hijacking uses an accessed system's compute or other capacity for an unauthorized purpose. The result can include cost increases and degraded business service.
An investigation example
A cloud workload starts consuming unusual compute capacity under a newly deployed unapproved image.
Evidence to examine
Review workload provenance, process behavior, identity changes, billing patterns, and approved capacity events.
A common analytical pitfall
High utilization or a bill increase alone does not establish hijacking; legitimate workload changes can explain both.
Response considerations
Stop confirmed unauthorized workloads, protect deployment identities, and assess the actual cost and service impact using operational evidence.
Availability can be consumed rather than destroyed
Resource hijacking redirects capacity away from its authorized purpose. Compute, bandwidth, messaging quotas, and hosted services can all have value to an intruder. The affected organization may experience slow service, unexpected charges, exhausted quotas, or reputational harm even when its original data remains intact. This distinguishes the impact from a simple file-deletion scenario.
A spike in resource use is only an observation. Legitimate analytics, backups, software builds, or a sudden increase in customers can produce similar symptoms. Investigators need to connect the consumption with the responsible workload, identity, deployment event, and business purpose. Billing information can help identify when abnormal usage began, but it rarely explains the cause by itself.
A fictional cloud bill investigation
An academy notices new compute charges overnight. The cloud audit trail shows instances created by an identity normally used for a small scheduled report. The report owner confirms that no expansion was approved. Investigators preserve creation events, identity activity, workload details, and relevant network context before deciding how to contain the unauthorized resources.
Deleting the instances may stop immediate cost, but it does not explain how the identity was accessed or whether other services were changed. Review credentials, permissions, and any persistent automation. Recovery should include checking that normal workloads still operate after containment and that spending alerts have an appropriate owner.
Practice separating symptom from cause
Use a fictional usage chart with a sudden increase and list three benign explanations and one unauthorized scenario. For each, identify evidence that would distinguish it. Then propose a safe alert that routes unusual usage for review without automatically declaring every expensive workload malicious. Do not create real costly resources to test the concept; a paper scenario or approved small lab is sufficient.
A useful cost alert should include the affected subscription, resource type, time window, and contact who can confirm expected demand. Without that context, an urgent billing notification may bounce between teams while the unauthorized workload continues consuming capacity.
Related concepts
References & further reading
Original explanations, with primary references for deeper study.
MITRE ATT&CK T1496: Resource Hijacking