A comprehensive study guide covering the four key cloud threat areas (insecure APIs, improper key management, insufficient logging, unprotected storage), cloud forensics challenges (SLA-limited access, elastic instance evidence destruction, chain of custody and data sovereignty), and five cloud audit tools (ScoutSuite, Prowler, Pacu, CloudBrute, Cloud Custodian).
Objective 1.1 — System and network architecture in security operationsObjective 2.2 — Analyze output from vulnerability assessment tools
1
Cloud Threat Landscape — Four Key Vulnerability Areas
Cloud environments introduce unique security challenges. Most cloud vulnerabilities originate in identity and access management — authentication, authorisation, and key management. The four major cloud threat areas you must know for the exam:
Four Key Cloud Threat Areas — Vulnerabilities Under Each
① Insecure APIs
→ HTTP instead of HTTPS
→ No input validation on received data
→ Verbose error messages leaking info
→ No rate limiting → DoS vulnerability
→ Leaked authentication tokens
② Key Management
→ Keys hard-coded in source code
→ Keys not deleted when unused
→ Same keys across dev/staging/prod
→ Unprotected developer workstations
→ Weak auth/authZ before API access
③ Logging & Monitoring
→ SaaS: no access to logs at all
→ Elastic instances deprov = logs lost
→ Logs stored only on ephemeral VMs
→ No long-term retention offsite
→ Gaps in incident investigation
④ Unprotected Storage
→ Default permissions not changed
→ Misconfigured container/IAM/ACLs
→ Weak CORS policy → XSS exposure
→ Public read on private buckets/blobs
→ Incorrect origin settings on CDN
2
Insecure APIs — Threats & Mitigations
APIs are the primary way cloud services communicate. Insecure APIs expose authentication tokens, enable injection attacks, and can be used to DoS your service. Every API security failure is ultimately an access or authentication failure.
Always use HTTPS (TLS/SSL), never HTTP. Unencrypted API traffic exposes authentication tokens, session data, and all transmitted content to any on-path attacker. There is no acceptable reason to run an API over plain HTTP in a production environment.
Server-side input validation on all received data. All data received by an API must pass server-side validation before any processing occurs. If the first question in this course was "what prevents SQL injection and XSS?" the answer is always input validation — the same applies to API inputs.
Sanitise error messages. Error messages related to authentication and authorisation can give attackers clues about the structure of your system, which fields exist, and how to exploit them. Return minimal, generic error messages to external callers. Log the detailed technical error internally.
Implement throttling and rate limiting. APIs without rate limiting are vulnerable to denial-of-service through request flooding. Rate limiting (e.g. 100 requests per minute per IP) prevents abuse and protects availability. After the limit is exceeded, ignore that source for a cool-down period before accepting requests again.
3
Key Management, Logging & Unprotected Storage
Improper key management
Use secure auth protocols
Use SAML, OAuth2, and OIDC for authentication and authorisation before granting API access. Never roll your own auth. These standards are well-tested and supported across all major cloud platforms.
Never hard-code keys
Do not embed API keys, credentials, or secrets in source code. If the code is reversed, leaked, or version-controlled, the keys are exposed. Use secrets managers (AWS Secrets Manager, Azure Key Vault, HashiCorp Vault) instead.
Delete unused keys immediately
Every unused key is an unnecessary attack surface. When a key is no longer needed, delete it. When moving from dev to staging to production, regenerate new keys — dev and staging keys have been exposed to many people. Production keys should be known to the minimum possible number of people.
Harden dev workstations
Developer workstations that touch API keys, secrets, and cloud services must be hardened and run only whitelisted applications. A compromised developer workstation exposes every key and secret it has access to — and in a serverless environment, this IS your entire attack surface.
Insufficient logging and monitoring
SaaS log access limitation
In a SaaS model, you often have no access to underlying logs, audit trails, or monitoring infrastructure — that's the provider's responsibility and may not be contractually accessible to you. When evaluating SaaS products for security-sensitive use, ask: what logs can we access? What security events are visible to us?
Elastic instance log loss
When a cloud instance is deprovisioned (scaled down), any logs stored locally on that instance are deleted along with it. Logs must be exported to durable, non-elastic storage before the instance is terminated. Use centralised log shipping (CloudWatch, Azure Monitor, Splunk) to ensure logs survive deprovisioning.
Unprotected cloud storage — buckets and blobs
Cloud storage containers are called buckets (AWS S3) or blobs (Azure Blob Storage). Each container holds data objects (files). Containers cannot be nested. Access is controlled through three overlapping mechanisms that must all be configured correctly.
3-layer access control
Container policies (what the bucket/blob itself allows), IAM authorisations (what the user's identity is permitted to do), and object ACLs (per-object permissions). All three layers must be configured correctly — a misconfiguration in any one can expose data even if the others are correct.
Default permissions risk
When you create a new storage container, default permissions are applied automatically. These defaults are often too permissive. If you don't explicitly change them to match your security requirements, those permissive defaults persist. Always modify storage permissions immediately after creation.
CORS policy — critical
Cross-Origin Resource Sharing (CORS) policy tells browsers which domains are trusted to make requests to your cloud storage or CDN. A weak or wildcard CORS policy exposes your storage to cross-site scripting attacks by allowing untrusted origins to make requests. CORS must be configured to only allow explicitly trusted domains.
CORS in depth: A CDN distributes your content across edge nodes worldwide, each on a different domain/IP. Without a CORS policy, browsers refuse cross-origin requests between these edge nodes. But a misconfigured CORS policy (e.g. Access-Control-Allow-Origin: *) allows any website to make requests to your storage — enabling attackers to exploit your storage through XSS on any site that loads your content.
4
Cloud Forensics — Three Major Challenges
Traditional digital forensics involves physically imaging drives and collecting evidence directly. Cloud forensics is fundamentally different — you don't own the hardware, the resources are virtual, data spans multiple physical locations, and the provider controls access. Three challenges define cloud forensics:
①
SLA-Constrained Access
You cannot physically access cloud hardware. Your rights to collect forensic evidence are defined by your Service Level Agreement (SLA) with the provider. In most public cloud SLAs, you cannot drive to the data centre and do a bit-by-bit disc image. Any forensic collection must be requested through the provider, who performs it on your behalf. This creates delays and limits the types of evidence you can collect.
②
Elastic Instance Evidence Destruction
Cloud instances are created and destroyed rapidly. When an instance is deprovisioned, its disc space is reclaimed and can be immediately overwritten by a new customer's instance. This permanently destroys forensic evidence. Some providers offer snapshot capabilities and extended log retention to mitigate this, but the volatility of cloud compute is an inherent forensic challenge.
③
Chain of Custody & Data Sovereignty
Chain of custody is broken when a third party (the cloud provider) collects evidence on your behalf — they are not law enforcement and may not follow forensic evidence preservation standards. Additionally, your data may physically reside in another country, subject to that country's data sovereignty laws, making legal evidence collection across jurisdictions extremely complex.
Attacker advantage in the cloud: Attackers can lease cloud instances to use as attack platforms — their traffic appears to originate from AWS, Azure, or GCP IP addresses. When you trace an attack back to an IP, finding it belongs to Amazon doesn't mean Amazon attacked you. It means an attacker leased a VM there and used it as a stepping stone. Multi-cloud attack infrastructure makes attribution especially difficult.
Cloud audit tools assess the security configuration of cloud environments — identifying misconfigurations, policy violations, and vulnerabilities before attackers do. These tools range from defensive auditors to offensive exploitation frameworks. Know the purpose and scope of each.
ScoutSuite
Multi-CloudDefensiveOpen-Source
Written in Python. Audits instances and policies on AWS, Azure, and Google Cloud using API calls. Compiles a report listing VM instances, storage containers, IAM accounts, data, and firewall ACLs. Supports custom rule sets (JSON format) to flag policy violations. Example rule: flag all IAM users without MFA enabled. The most versatile cloud auditor — works across all major cloud platforms.
Prowler
AWS OnlyDefensiveOpen-Source
AWS-only auditing tool. Evaluates cloud infrastructure against CIS benchmarks for AWS, GDPR, and HIPAA. Checks 200+ controls. Command-line tool outputting HTML, CSV, or JSON reports. Can submit findings directly to AWS Security Hub. Supports parallel assessment of multiple AWS accounts. Best choice when the organisation is AWS-only and needs compliance-focused output.
Pacu
AWS OnlyOffensive
An exploitation framework for AWS — think Metasploit for the cloud. Contains modules for obtaining API keys, gaining VM control, privilege escalation, launching secondary attacks, and installing backdoors. Focuses on the post-compromise phase to simulate what a real attacker would do after gaining initial access. Used by red teams for adversarial cloud security testing. Not a defensive auditor.
CloudBrute
Multi-CloudOffensive
Finds a target organisation's infrastructure, files, and applications across major cloud providers (AWS, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode). Works like a web crawler or DirBuster but targeting cloud resources — object storage, VMs, containers, and services. Used during reconnaissance to discover what cloud assets an organisation has exposed. Not a compliance auditor.
Cloud Custodian
Multi-CloudDefensiveOpen-Source
A stateless rules engine for cloud security, governance, and management. Validates and enforces AWS environments against defined policies. Unique feature: can automatically remediate violations it finds (enforce new security policies, not just report). Also does "garbage collection" — automatically deletes unused or underutilised resources outside business hours, saving money. Used for ongoing governance, not just point-in-time audits.
Tool comparison for the exam: ScoutSuite = multi-cloud auditor (AWS/Azure/GCP), custom JSON rules, defensive. Prowler = AWS-only, compliance-focused (CIS/GDPR/HIPAA/200+ controls), defensive. Pacu = AWS-only, offensive exploitation framework (like Metasploit for AWS). CloudBrute = multi-cloud reconnaissance/discovery tool, offensive. Cloud Custodian = multi-cloud governance engine, can auto-remediate AND auto-delete waste (garbage collection). Key distinction: Pacu and CloudBrute are offensive tools. ScoutSuite/Prowler/Cloud Custodian are defensive.
Exam
Quick Reference Cheat Sheet
Four cloud threat areas
1 Insecure APIs: use HTTPS, input validation, sanitised errors, rate limiting. 2 Improper Key Management: no hard-coded keys, delete unused keys, regenerate keys at each environment stage (dev→staging→prod), harden developer workstations, use SAML/OAuth/OIDC. 3 Insufficient Logging: SaaS = no log access, elastic instances destroy logs on deprovisioning — export logs to non-elastic storage before deprovisioning. 4 Unprotected Storage: modify defaults immediately, configure all three layers (container policy + IAM + object ACL), correct CORS policy.
Cloud storage & CORS
Cloud storage containers = Buckets (AWS S3) or Blobs (Azure Blob Storage). Containers host data objects (files). Cannot be nested. Access controlled by: container policies + IAM authorisations + object ACLs — all three must be correct. Default permissions on new containers = too permissive — always change immediately. CORS (Cross-Origin Resource Sharing) policy = tells browsers which domains are trusted to request from your CDN/storage. Weak CORS (wildcard) = XSS exposure. Must restrict to explicitly trusted origins only.
Cloud forensics challenges (3)
1 SLA-constrained access: you cannot physically access cloud hardware. Evidence collection limited by your SLA. Provider collects on your behalf. 2 Elastic instance evidence destruction: deprovisioned instances delete local data; space immediately reused and overwritten. Export logs to durable storage before deprovisioning. 3 Chain of custody + data sovereignty: provider is not law enforcement, chain of custody is broken. Data may be in another country's jurisdiction = cross-border legal complexity. Attacker advantage: attack traffic appears to originate from legitimate cloud IPs (AWS/Azure/GCP).