Cloud Security Pitfalls - TryHackMe Writeup

Cloud migrations are exciting, but they can also introduce brand-new blind spots. This TryHackMe room breaks down the common pitfalls, explains the shared responsibility model, and shows what a SOC analyst should prioritize. I will also add extra beginner-friendly context so the “why” behind each point is clearer.

TL;DR

• What this teaches: Cloud service models, shared responsibility, and monitoring pitfalls
• Difficulty: Beginner
• Best for: SOC analysts, blue teamers, and cloud-curious defenders

Task 1: Introduction

Moving from on-prem to cloud doesn’t magically fix old security issues. It changes where the risk lives and who can see it. Think of it like moving to a new apartment: you might get better locks and utilities, but you still have to lock the door, keep track of your keys, and know who has access. The room’s goals are to help you:

• learn the main cloud models: IaaS, PaaS, SaaS
• explore security risks coming from cloud providers
• understand core security concepts in the cloud
• identify monitoring challenges in a SOC

Prereqs: Basic web app knowledge is enough. The TryHackMe SOC Level 1 path helps but isn’t required.

Task 2: What is Cloud?

The three cloud models

IaaS gives you compute and networking without owning hardware. You still manage the OS, apps, and security hardening. A good mental model is “renting a server”: the provider owns the building and power, but you decide how the server is configured and secured.

PaaS abstracts the infrastructure so developers can deploy apps without managing servers. This is like renting a fully equipped kitchen: you bring the recipe (code), but the tools and maintenance are handled for you.

SaaS is a complete product delivered as a service (Slack, Zoom, Gmail, etc.). You manage access, data, and configuration, but not the underlying platform. This is closer to using a restaurant: you choose what to order and who eats, but you don’t control the kitchen.

Quick answers

• Q1: Which model lets you migrate a large on-prem network to the cloud? Answer: IaaS
• Q2: Which model do Elastic Cloud and CrowdStrike Falcon fit into? Answer: SaaS

Task 3: Security of the Cloud (provider responsibility)

Cloud providers run massive, hardened infrastructure, but it’s still “someone else’s computer.” Provider security issues are rare, yet they’re high impact when they happen. If the provider is breached, many customers can be affected at once. This is why we treat cloud risk as a supply chain risk even if the provider has strong security controls.

Supply-chain risk still applies

A provider breach can hit many customers at once. You still need to:

• segment access
• monitor logins
• validate activity across endpoints and SaaS usage

Visibility gap

If an attacker operates inside a SaaS provider, customers often have zero visibility. You can only see what the vendor chooses to expose in logs. If the compromise happens entirely within their infrastructure, you may only notice it after data has already been accessed or exfiltrated.

Quick answers:

• Q1: Is the provider responsible for securing its own infrastructure? Yea
• Q2: Should you fully trust them without watching for supply-chain threats? Nay

Task 4: Security in the Cloud (your responsibility)

You’re still responsible for your assets in the cloud: VMs, apps, identities, configurations, and data. A simple rule is: if you create it, configure it, or store it, you own its security.

Common migration pitfalls

• Moving an unpatched server to the cloud doesn’t make it secure. The same vulnerable software is still running; the location changed, not the risk.
• Old password policies without MFA become dangerous in public cloud. The internet is always “on” for attackers, so weak authentication is a common first step.
• On-prem rules don’t always map cleanly to cloud workflows. For example, internal-only admin tools can become exposed if a misconfigured security group opens them to the world.

Cloud logging hurdles

Many SaaS platforms have:

• Paid logs (extra license cost)
• Poor formats (missing fields, weak documentation)
• No SIEM integration

Beginner tip: assume cloud logs are a limited resource. Enable what you can early, send it to a SIEM, and document any gaps so they are not forgotten.

Quick answers:

• Q1: Does moving an unpatched server to the cloud make it secure? Nay
• Q2: First major obstacle to SIEM integration? Paid logs

Task 5: Cloud Security Monitoring

Monitoring changes with each model:

• SaaS: ingest audit logs and watch for risky actions
• IaaS: monitor both workloads (VMs/containers) and the control plane

For beginners: the control plane is the admin layer where you create VMs, change network rules, and manage identities. If attackers gain control-plane access, they can spin up resources, exfiltrate data, or disable logging.

Common cloud security tools

• CASB: policy enforcement (who can access SaaS and what data they can move)
• CWPP: workload protection (defend VMs, containers, and runtime activity)
• CSPM: misconfiguration detection (catch risky settings like public storage buckets)

Minimal SOC checklist

Beginner tip: start with “who did what, from where, and when” as your baseline for detections. Those four questions catch a surprising amount of cloud abuse.

Quick answers:

• Q1: What term describes cloud compute resources like VMs or containers? Workloads
• Q2: Where do Falco and Tetragon fit? CWPP

Task 6: Challenge

The room’s final challenge reinforces the shared responsibility model.

Challenge 1 flag:

THM{flag_as_a_service!}

Challenge 2 flag:

THM{ready_for_cloud_migration!}

Task 7: Conclusion

This room is a solid primer on cloud security realities: the shared responsibility model, provider vs. customer risk, and the very real logging gaps that impact SOCs. If you’re starting your cloud journey, this is a great foundation before diving into AWS (IaaS) and Entra ID (SaaS) specifics.

If you want, I can also add a short “defender’s checklist” section or a glossary for cloud terms.