Cloud Threats, Vulnerabilities, and Attack Techniques

Introduction and Context

Cloud computing changes the location, ownership, and operation of computing resources, but it does not remove security risk. Applications, identities, data, networks, and administrative functions are still exposed to accidental errors and deliberate attacks. What changes is the way those risks are distributed across the customer, cloud service provider, software suppliers, administrators, and automated management systems.

A cloud attack is rarely a single dramatic event. More commonly, an attacker combines several weaknesses: a publicly exposed storage resource, an excessive identity permission, a stolen credential, and inadequate monitoring. Understanding these combinations is essential for cloud professionals because effective protection begins with recognizing how attacks develop.

This chapter examines major cloud threats, vulnerabilities, and attack techniques. It focuses on misconfiguration, insecure interfaces, credential theft, account hijacking, malware, denial-of-service, insider threats, supply-chain compromise, tenant-isolation failure, and common attack paths. The discussion applies to infrastructure as a service (IaaS), platform as a service (PaaS), software as a service (SaaS), containers, serverless platforms, and hybrid environments.

Learning Objectives

By the end of this chapter, a learner should be able to:

1. Distinguish a threat, vulnerability, attack, exposure, and risk.
2. Explain how cloud misconfiguration and insecure interfaces create attack opportunities.
3. Recognize credential theft, account hijacking, malware, and denial-of-service techniques.
4. Analyse insider, supply-chain, and tenant-isolation threats.
5. Trace common cloud attack paths from initial access to impact.
6. Recommend practical preventive, detective, and corrective controls.
7. Evaluate security incidents using shared-responsibility and risk-management principles.

1. A Vocabulary for Cloud Threat Analysis

A threat is a potential cause of harm, such as a criminal group, malicious employee, vulnerable software package, or natural event. A vulnerability is a weakness that can be exploited, such as an overly permissive policy or unpatched virtual machine. An attack is the deliberate attempt to exploit a vulnerability. An exposure is a condition in which a resource is accessible or observable in an unintended way. An incident is an event that actually compromises, or threatens to compromise, confidentiality, integrity, or availability.

Risk combines the possibility of an adverse event with its consequences. A simple qualitative model is:

Likelihood describes how probable or feasible exploitation is; impact describes the resulting harm. This expression is a decision-making model rather than a precise universal law. Organisations may use numerical, ordinal, or scenario-based methods. Risk is not eliminated merely because a vulnerability has a low probability: a highly consequential vulnerability may still require treatment.

The attack surface is the collection of reachable assets, interfaces, identities, software components, network paths, and operational processes that an attacker could target. Cloud environments can enlarge the attack surface through APIs, temporary resources, infrastructure-as-code repositories, federated identities, third-party integrations, and public management consoles.

Shared Responsibility

Cloud security responsibilities are divided. The provider normally protects physical facilities, core hardware, and foundational services. The customer remains responsible for some combination of identities, data, operating systems, applications, network configuration, and endpoint security. The exact division depends on the service model:

Shared responsibility is not shared accountability in an identical sense. A customer cannot assume that a provider will correct a customer-created public bucket, exposed secret, or excessive permission.

2. Misconfiguration: The Most Common Cloud Weakness

Misconfiguration occurs when a cloud resource is deployed with insecure or unintended settings. Examples include:

• a storage bucket or database exposed to the public Internet;
• a firewall rule permitting unrestricted inbound access;
• administrative interfaces reachable from untrusted networks;
• an identity policy granting broad permissions when only one action was required;
• disabled logging or retention periods that are too short;
• encryption keys managed without adequate access control or rotation;
• default passwords, sample applications, or unused accounts left active;
• a container orchestrator dashboard exposed without strong authentication.

Misconfiguration is especially dangerous because cloud resources are created rapidly and often by automated templates. A single incorrect parameter can be replicated across hundreds of systems. Configuration drift may then occur when manually changed systems no longer match approved templates.

Why Misconfiguration Persists

Cloud environments are dynamic. Developers may create temporary storage, test databases, functions, and service accounts. These resources can survive beyond the project that created them. Multiple teams may also interpret “private,” “internal,” or “trusted” differently. In addition, a secure configuration in one context may be unsafe in another; an internal API exposed to a private network may become vulnerable when a routing change makes that network reachable externally.

Controls

Effective controls include secure baseline configurations, policy-as-code, infrastructure-as-code review, automated configuration scanning, change approval, asset inventories, and continuous monitoring. Preventive guardrails should block clearly unsafe states, such as public access to sensitive storage. Detection remains necessary because not all unsafe conditions can be prevented automatically.

3. Insecure Interfaces and APIs

Cloud services are controlled largely through web consoles, command-line tools, software development kits, and APIs. These interfaces are powerful and therefore attractive targets. An insecure API may suffer from weak authentication, inadequate authorization, insufficient input validation, excessive data disclosure, poor rate limiting, or insecure error handling.

Authentication answers “Who are you?” Authorization answers “What are you allowed to do?” Confusing these functions is a serious design error. A user may be correctly authenticated but still able to retrieve another customer’s records because the application fails to enforce object-level authorization.

Common API attack techniques include:

• Credential and token replay: using a stolen API key, session token, or signed request.
• Broken object-level authorization: changing an identifier in a request to access another object.
• Privilege escalation: invoking administrative functions from a lower-privileged account.
• Injection: placing malicious input into commands, queries, templates, or interpreters.
• Enumeration: discovering valid users, resources, or account identifiers through response differences.
• Abuse of automation: sending requests at a volume or speed that overwhelms services or bypasses business controls.

Secure interfaces require strong authentication, least-privilege authorization, server-side validation, consistent error messages, logging, rate limits, replay protection where appropriate, and formal API lifecycle management. Secrets should not be embedded in client-side code or public repositories. Deprecation is also a security issue: unsupported API versions may contain weaknesses and may lack modern controls.

4. Credential Theft and Account Hijacking

Cloud identities are control planes. A stolen password, access key, session cookie, OAuth token, or private key can allow an attacker to act as a legitimate user or service. Account hijacking occurs when an attacker gains control of an account and uses it for unauthorised access, data theft, persistence, cryptomining, fraud, or further compromise.

Credential Theft Methods

Credential theft may occur through phishing, fake login pages, malware, password reuse, credential stuffing, exposed source code, compromised endpoints, insecure storage, or interception of poorly protected secrets. Attackers also search public repositories, container images, build logs, error messages, and infrastructure state files for keys.

Service accounts are particularly important. They often have long-lived credentials and broad permissions, while their activity may not be associated with a human owner. A compromised service account can therefore operate quietly and access many resources.

Account-Hijacking Sequence

A typical sequence is:

1. Obtain a password, token, key, or session artifact.
2. Test the credential against the cloud control plane or an application.
3. Discover the victim’s permissions, accounts, regions, and resources.
4. Create persistence, such as a new access key, user, role trust relationship, or scheduled function.
5. Increase privileges or move to another account.
6. Access data, alter configurations, deploy malware, or consume resources.
7. Delete or manipulate logs and use legitimate tools to avoid suspicion.

Defensive Measures

Multi-factor authentication substantially reduces the value of a stolen password, although phishing-resistant methods are stronger than codes that can be relayed. Other controls include short-lived credentials, workload identity, conditional access, privileged access management, key rotation, secret vaults, device security, impossible-travel and anomalous-behaviour detection, and immediate revocation procedures.

The principle of least privilege requires that an identity receive only the permissions necessary for an approved task, for only as long as necessary. Permissions should be reviewed against actual use rather than assumed need. Separation of duties is also important: no single identity should be able to request, approve, execute, and conceal a sensitive operation without oversight.

5. Malware in Cloud Environments

Malware includes ransomware, data-stealing software, botnet agents, cryptominers, remote-access tools, and malicious scripts. Cloud malware may run inside virtual machines, containers, serverless functions, CI/CD runners, user endpoints, or compromised management hosts.

Cloud characteristics affect malware behaviour. Rapid elasticity can allow an attacker to deploy many instances quickly. Ephemeral systems may disappear before forensic collection. Containers provide process isolation but do not make malicious code harmless; a container escape or excessive host permission can expose the underlying node. Serverless functions can be abused for persistence, data access, or high-volume execution.

Initial infection may result from a vulnerable public application, malicious package, stolen administrator credential, poisoned container image, exposed remote service, or compromised build pipeline. After execution, malware may attempt discovery, privilege escalation, credential access, lateral movement, data collection, encryption, or resource abuse.

Defence requires hardened images, vulnerability and dependency scanning, runtime monitoring, endpoint detection, application allow-listing where feasible, network segmentation, restricted metadata-service access, immutable backups, and tested recovery procedures. Detection should consider unusual instance creation, unexpected outbound connections, abnormal process execution, sudden resource consumption, and use of administrative tools from unfamiliar locations.

6. Denial-of-Service and Resource Exhaustion

A denial-of-service (DoS) attack attempts to make a service unavailable. A distributed denial-of-service (DDoS) attack uses many source systems, often a botnet, to generate traffic or requests. Cloud attacks may also exploit application logic, queues, serverless invocation, storage operations, or expensive database queries.

The impact is not limited to network bandwidth. An attacker may exhaust CPU, memory, connection pools, database capacity, API quotas, concurrent function executions, or cloud spending limits. An apparently available service can therefore become operationally unusable.

Controls include provider DDoS protection, content delivery networks, web application firewalls, autoscaling with safe limits, caching, rate limiting, circuit breakers, queue controls, origin protection, quota monitoring, and tested incident playbooks. Autoscaling alone is not a complete defence: it can increase availability but may also increase financial loss if every malicious request causes additional resources to be created.

Availability planning should define recovery time objectives and recovery point objectives. These are organisational requirements, not attack formulas: the recovery time objective specifies the maximum acceptable restoration time, while the recovery point objective specifies the maximum acceptable data loss measured in time.

7. Insider Threats

An insider is a person or trusted entity with legitimate access. Insiders may be malicious, coerced, negligent, or simply make a mistake. Contractors, administrators, developers, support personnel, partners, and compromised employees can all create insider risk.

Examples include copying customer data, approving an unsafe change, disabling monitoring, leaking credentials, introducing a backdoor, or accidentally publishing sensitive information. Cloud control planes magnify the effects of privileged actions because one identity may affect many regions or accounts.

Important controls include least privilege, just-in-time administration, separation of duties, dual approval for high-risk actions, independent logging, privileged-session monitoring, data-loss prevention, access reviews, rapid offboarding, and a culture that encourages reporting mistakes. Monitoring must be proportionate and lawful. Employee privacy, labour law, due process, and legitimate whistle-blowing rights should not be ignored in the name of surveillance.

8. Supply-Chain Compromise

A cloud supply chain includes operating systems, libraries, container images, plugins, SaaS integrations, managed services, deployment tools, hardware, consultants, and build systems. A supply-chain compromise occurs when an attacker compromises a supplier or component so that downstream users receive malicious code, altered updates, stolen credentials, or unauthorised access.

A software build pipeline is particularly sensitive. If an attacker changes source code, dependencies, build runners, signing keys, or release repositories, the resulting software may appear legitimate. Dependency confusion, typosquatting, malicious packages, vulnerable libraries, poisoned images, and compromised update mechanisms are common risk categories.

Risk reduction includes supplier due diligence, approved repositories, dependency pinning, software composition analysis, signed commits and artifacts, isolated build environments, protected branches, multi-person approval, provenance records, vulnerability disclosure processes, and a software bill of materials. Signatures help verify origin and integrity, but they do not prove that the signed software is safe; a legitimate supplier account can sign malicious code after compromise.

9. Tenant-Isolation Failures and Virtualisation Risk

Public clouds are multi-tenant environments: resources belonging to different customers share physical or logical infrastructure. Tenant isolation is the separation that prevents one customer from accessing another customer’s data, processes, memory, storage, or management functions.

Isolation may fail through a hypervisor vulnerability, container escape, insecure storage reuse, flawed access controls, side-channel leakage, shared network mistakes, or a provider software defect. The probability and technical details vary by architecture, but the consequence can be severe because many customers may be affected by one underlying fault.

Customers should understand the isolation assurances and security options offered by a provider. Sensitive workloads may require dedicated hosts, confidential-computing technologies, customer-managed keys, private connectivity, or stronger workload separation. These controls can reduce some risks but may increase cost and complexity. Provider assurance reports, penetration-testing rules, incident-notification commitments, and contractual responsibilities should be examined as part of risk management.

10. Common Cloud Attack Paths

Attack paths describe how an attacker moves from an initial weakness to an objective. A useful analysis asks four questions: What is exposed? What identity or code is reached? What permissions or trust relationships follow? What impact becomes possible?

Path A: Public Storage to Data Disclosure

A developer makes a storage resource public for testing. An attacker discovers its address through search, scanning, or an application response. The attacker lists or downloads objects, finds configuration files containing credentials, and uses those credentials against the control plane. The original error was misconfiguration, but the final impact results from both data exposure and secret management failure.

Path B: Web Application to Cloud Control Plane

A vulnerable web application permits command execution or access to a workload identity. The attacker queries a metadata service or local credential source, obtains temporary permissions, discovers accessible resources, and uses excessive permissions to read data or create persistence. Restricting workload identity permissions and protecting credential endpoints are key barriers.

Path C: Phishing to Administrative Takeover

A user submits credentials to a fraudulent login page. The attacker reuses the session or password, bypasses weak authentication, registers a new access method, and changes forwarding rules or access policies. Phishing-resistant authentication, conditional access, session monitoring, and rapid revocation interrupt this path.

Path D: Dependency to Production

A build process downloads a malicious or vulnerable dependency. Automated tests and deployment promote the component into production. The component accesses environment secrets or customer data. Dependency controls, artifact signing, isolated builds, and runtime restrictions reduce the likelihood and impact.

Attack-Path Analysis Method

A practical assessment can inventory assets, identify entry points, map identities and trust relationships, locate privilege boundaries, identify possible lateral movement, and estimate business impact. The aim is not merely to count vulnerabilities but to find connected weaknesses. A medium-severity issue that links a public interface to a powerful identity may deserve higher priority than several isolated low-impact findings.

Illustrative Case Study: The Exposed Analytics Environment

Background. A fictional online retailer uses object storage for sales reports and a managed analytics platform. Developers create test environments through infrastructure-as-code, while a service account exports reports nightly.

Problem. A test storage container is accidentally configured for public read access. A report contains an internal API endpoint and a deployment log includes a long-lived service credential. The service account can read customer analytics, create compute jobs, and modify storage policies.

Analysis. An external researcher discovers the public container and reports the exposure. Before investigation begins, automated monitoring detects unusual report downloads and compute jobs in a new region. The incident team determines that the exposed credential was used to access the analytics platform. The initial vulnerability was a storage misconfiguration, but excessive service-account permissions and secrets in logs increased the impact.

Approach. The retailer disables and replaces the credential, revokes active sessions, restricts the storage resource, and preserves logs for investigation. It reviews access to affected data, notifies relevant stakeholders, and checks for persistence such as new keys or scheduled jobs. Longer-term changes include short-lived workload identity, secret redaction in logs, policy-as-code checks that block public storage, separate accounts for testing and production, narrower permissions, and alerts for unusual downloads and geographic activity.

Outcome. Investigation finds limited unauthorised access and no evidence of altered customer records. The retailer improves its incident playbook and adds a pre-deployment security gate.

Learning points. A cloud incident often involves a chain rather than one defect. Public exposure, secret leakage, excessive permission, and weak detection reinforced one another. Effective security therefore combines prevention, least privilege, monitoring, response, and recovery.

11. Governance, Ethics, and Professional Practice

Cloud security professionals must protect confidentiality and availability while respecting privacy, lawful authority, and proportionality. Security testing should be authorised and scoped; scanning a provider or another tenant without permission may be unlawful. Logs and monitoring can contain personal information and should have defined purposes, access restrictions, retention periods, and disposal procedures.

Regulated data may require controls concerning location, processing, breach notification, retention, encryption, and third-party access. Contracts should define responsibilities, audit rights, service levels, incident communication, subcontracting, and exit or portability arrangements. Artificial intelligence can assist anomaly detection, code review, and alert triage, but AI-generated recommendations require human validation. Models may produce false positives, miss novel attacks, expose sensitive data, or be manipulated through malicious inputs.

12. Practical Security Baseline

A diploma-level cloud practitioner should be able to apply the following baseline:

1. Maintain an accurate inventory of accounts, resources, data, APIs, and suppliers.
2. Enforce strong, phishing-resistant authentication for privileged access.
3. Apply least privilege, short-lived credentials, and regular access reviews.
4. Block public exposure of sensitive resources unless explicitly approved.
5. Use secure templates, code review, policy-as-code, and configuration scanning.
6. Patch operating systems, applications, images, and dependencies according to risk.
7. Protect secrets with managed vaults and prevent them from entering code or logs.
8. Segment networks and workloads; restrict administrative interfaces.
9. Collect tamper-resistant logs and monitor identity, configuration, data, and cost anomalies.
10. Prepare and test incident response, backup, restoration, and account-revocation procedures.
11. Assess suppliers, dependencies, managed services, and software provenance.
12. Review the effectiveness of controls after incidents, near misses, and major architectural changes.

Challenges and Limitations

No control provides complete protection. Multi-factor authentication may not stop token theft or an authorised malicious user. Encryption does not prevent misuse by an identity that is allowed to decrypt data. Automated scanners can miss business-logic flaws and may generate false positives. Least privilege can be difficult to implement in rapidly changing environments, while excessive restrictions may encourage unsafe workarounds. Provider security assurances reduce uncertainty but do not replace customer configuration and monitoring. Finally, security priorities must be balanced with availability, usability, cost, innovation, and legal obligations.

Chapter Summary

Cloud threats arise from technical weaknesses, human actions, trusted relationships, and failures in governance. Misconfiguration is dangerous because cloud resources are powerful, dynamic, and often automated. Insecure APIs can fail through weak authentication, broken authorization, injection, data disclosure, and inadequate rate limiting. Stolen credentials and hijacked accounts provide attackers with legitimate control-plane access, while malware can exploit virtual machines, containers, functions, endpoints, and build systems.

DoS and DDoS attacks target not only bandwidth but also compute, databases, queues, quotas, and spending limits. Insider threats require least privilege, separation of duties, monitoring, and lawful governance. Supply-chain compromise demonstrates that trusted code and suppliers can become attack paths. Tenant-isolation failures affect the foundations of multi-tenant cloud architecture and require provider assurance and, where justified, stronger workload separation.

The most useful professional perspective is attack-path analysis. Security teams should connect exposures, identities, trust relationships, privilege boundaries, and business impact rather than treating vulnerabilities as isolated checklist items. Effective cloud security combines preventive guardrails, detective monitoring, responsive containment, tested recovery, and continuous improvement under the shared-responsibility model.

Key Terms

Threat: A potential cause of harm to a system, organisation, or individual.

Vulnerability: A weakness that can be exploited.

Attack surface: The reachable assets, interfaces, identities, and processes that may be targeted.

Exposure: An unintended condition in which a resource is accessible or observable.

Misconfiguration: An insecure or unintended setting in a cloud resource or service.

API: An interface through which software or users request services and operations.

Authentication: Verification of an identity.

Authorization: Determination of what an authenticated identity may do.

Account hijacking: Unauthorised control or use of a legitimate account.

Credential stuffing: Testing reused credentials obtained from another breach.

Malware: Malicious software designed to disrupt, damage, spy, steal, or gain control.

DDoS: A distributed denial-of-service attack using many sources to impair availability.

Insider threat: Risk arising from a trusted person or entity with legitimate access.

Supply-chain compromise: Compromise of a supplier, component, or development process affecting users downstream.

Tenant isolation: Separation preventing one cloud customer from accessing another customer’s resources.

Least privilege: Granting only the permissions necessary for an approved task.

Persistence: Methods used by an attacker to retain access after initial compromise.

Lateral movement: Movement from one compromised resource or identity to another.

Policy-as-code: Machine-enforceable rules that validate or restrict configurations.

Shared responsibility: Division of cloud security duties between provider and customer.

Review Questions

5 Short Answer Questions

1. Distinguish a threat, vulnerability, attack, and incident.
2. Give four examples of cloud misconfiguration.
3. Why are service accounts attractive targets for attackers?
4. State two differences between a DoS attack and a DDoS attack.
5. What is meant by tenant isolation?

5 Long Answer Questions

1. Explain the shared-responsibility model for IaaS, PaaS, and SaaS, using examples of customer and provider duties.
2. Describe how an insecure API can permit unauthorised access even when users are correctly authenticated.
3. Discuss the causes, consequences, and controls associated with cloud account hijacking.
4. Explain how supply-chain compromise can move from a dependency or build system into production.
5. Evaluate the role of least privilege, monitoring, and incident response in reducing insider-threat impact.

3 Analytical / Application Questions

1. A company discovers that a public storage resource contains deployment logs, one of which includes a service credential. Construct a likely attack path and recommend immediate and long-term controls.
2. A serverless application experiences unexpectedly high invocation costs and intermittent unavailability. Analyse whether this could be resource-exhaustion abuse and identify evidence that should be collected.
3. A development team wants to use a community container image in production. Design a risk-assessment process covering provenance, vulnerabilities, permissions, testing, deployment, and runtime monitoring.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes authentication from authorization?

A. Authentication determines what a user may do; authorization verifies identity.

B. Authentication verifies identity; authorization determines permitted actions.

C. Authentication encrypts data; authorization backs up data.

D. Authentication detects malware; authorization prevents denial-of-service.

Correct Answer: B. Authentication verifies identity; authorization determines permitted actions.

Question 2

Which cloud condition is an example of misconfiguration?

A. A provider operating a physical data centre

B. A storage resource containing sensitive data configured for public read access

C. A user completing multi-factor authentication

D. A service using encrypted network connections

Correct Answer: B. A storage resource containing sensitive data configured for public read access

Question 3

Why are excessive service-account permissions dangerous?

A. They prevent all automated operations.

B. They make cloud resources physically unavailable.

C. A stolen service credential may provide broad access to data and management functions.

D. They automatically disable audit logging.

Correct Answer: C. A stolen service credential may provide broad access to data and management functions.

Question 4

Which control most directly reduces the value of a stolen password?

A. Phishing-resistant multi-factor authentication

B. Increasing storage capacity

C. Disabling software updates

D. Publishing API documentation

Correct Answer: A. Phishing-resistant multi-factor authentication

Question 5

Which activity is characteristic of a supply-chain compromise?

A. A customer changes a firewall rule through an approved console

B. A malicious dependency is introduced into a build and deployed as trusted software

C. A user restores a file from a backup

D. A provider adds physical servers to a data centre

Correct Answer: B. A malicious dependency is introduced into a build and deployed as trusted software

Question 6

What is the principal objective of a denial-of-service attack?

A. To improve service scalability

B. To make a service or resource unavailable to legitimate users

C. To verify a digital signature

D. To reduce the number of authorised users

Correct Answer: B. To make a service or resource unavailable to legitimate users

Question 7

Which sequence best represents a common cloud attack path?

A. Public exposure → stolen secret → control-plane access → data access

B. Backup restoration → patching → encryption → public disclosure

C. Multi-factor authentication → least privilege → isolation → no exposure

D. Code review → signed artifact → deployment approval → secure deletion

Correct Answer: A. Public exposure → stolen secret → control-plane access → data access

Question 8

Which statement about tenant isolation is correct?

A. It means every customer uses a physically separate global Internet.

B. It prevents one tenant from accessing another tenant’s resources in shared infrastructure.

C. It eliminates the need for customer identity controls.

D. It guarantees that no cloud software can contain vulnerabilities.

Correct Answer: B. It prevents one tenant from accessing another tenant’s resources in shared infrastructure.

Question 9

Which practice best limits the impact of a compromised identity?

A. Granting permanent administrator permissions to all service accounts

B. Using least privilege and short-lived credentials

C. Disabling logs to protect privacy

D. Sharing one account across a whole development team

Correct Answer: B. Using least privilege and short-lived credentials

Question 10

A malicious actor causes a serverless function to execute repeatedly, increasing cost and exhausting concurrency. Which threat is most directly illustrated?

A. Resource-exhaustion or denial-of-service abuse

B. Tenant isolation success

C. Secure dependency management

D. Data classification

Correct Answer: A. Resource-exhaustion or denial-of-service abuse