Cloud, mobile and IoT — Concepts
The perimeter is no longer a building and a firewall. Data lives at a provider, the client runs in the user’s pocket, and the internal network hosts cameras that have not seen a patch since 2019. This lesson settles the notions. The Flutter lab in 11.2 and 11.3 applies the mobile part. Chapter 11.5 covers WiFi and cameras. Here, you learn to prioritize before you open a tool.
A cloud pentest targets the customer’s account: IAM, buckets, functions, keys. It does not target the hypervisor, the datacenter or the provider’s API. The RoE says it in one line. Stepping outside that frame is attacking a third party.
What you will be able to do
- Place each finding in the shared responsibility model: what the customer can fix, what they must demand from the provider.
- Recognize the three cloud mistakes that still pay in 2026: overly open IAM, exposed storage, secrets in clear.
- Name the mobile surfaces (binary, local storage, pinning) without confusing a client-side guard with a server-side control.
- Qualify an IoT target with three questions: default account, cleartext service, recoverable firmware.
1. Why these three surfaces together
Cloud, mobile and IoT do not share the same stack. They share the same shift: the trust boundary has left the network.
| Surface | What the attacker controls | Consequence |
|---|---|---|
| Cloud | Often nothing at first — they look for a key, a role, a bucket | The mistake is a policy, not a buffer overflow |
| Mobile | The entire device, if they want it (root, emulator, proxy) | Every secret in the client will come out |
| IoT | The device, the radio, sometimes the serial port | The fundamentals are enough: factory defaults, HTTP, firmware |
A classic web pentest assumes a server you do not own and a browser you half-control. On mobile, the client sits with the adversary. In the cloud, the “server” is a JSON policy. On IoT, the server is sometimes a Linux 3.10 compiled in 2018. The techniques change; the question stays: where is trust placed, and does it hold?
2. Cloud — the shared responsibility model
The provider secures the cloud. The customer secures what they put in the cloud. The boundary moves with the service.
| Layer | IaaS (EC2, Compute) | PaaS (RDS, App Service) | SaaS (M365, Salesforce) |
|---|---|---|---|
| Data and classification | Customer | Customer | Customer |
| Identities, keys, IAM | Customer | Customer | Customer + provider |
| Operating system | Customer | Provider | Provider |
| Application patching | Customer | Shared | Provider |
| Virtual network, SG, NSG | Customer | Shared | Provider |
| Datacenter, hardware | Provider | Provider | Provider |
What that changes for the report. A public S3 bucket, an
Action: "*" policy on Resource: "*", an access key committed to
Git: that is 100% customer. A 0-day in the Xen hypervisor: out of
scope. A student who writes “AWS is vulnerable” missed the model.
They must write “the prod-backup account allows s3:GetObject to
Principal: "*".”
The perimeter is negotiated before the scan: in-scope accounts
and subscriptions, regions, a ban on attacking provider endpoints, a
ban on DoS against billing APIs. Pacu, Prowler, ScoutSuite and
AzureHound work with the customer’s credentials, not against
amazonaws.com.
3. Cloud — the three mistakes that pay
Application CVEs still exist. The overwhelming majority of cloud incidents over the past five years come from something else: an identity that is too wide, storage reachable with no account, a secret that should never have been a file.
3.1. Overly permissive IAM
IAM is the real OS of the cloud. A policy that says “everything, everywhere” turns a stolen key into administration of the account.
{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}
This double star is not a lab shortcut. You find it on integration roles, “temporary” users from 2019, and inline policies dropped on a Friday evening. Variants that deserve the same finding:
Action: "s3:*"on every bucket, including those of another project.- A trust policy that accepts
sts:AssumeRolefrom a partner account with no ExternalId condition. - Human IAM access keys, two years old, with no rotation, pasted into a Jenkins.
What that stops, concretely: named least privilege
(s3:GetObject on arn:aws:s3:::factures-2026/*), short-lived
assumed roles, MFA on the console, a ban on long-lived keys in favor
of instance roles or CI/CD OIDC.
Review tools, read-only first:
| Tool | Target | Use |
|---|---|---|
prowler | AWS | CIS controls / finding ready for the report |
scoutsuite | AWS, Azure, GCP | Multi-cloud mapping |
pacu | AWS | Offensive modules on the authorized account |
azure-hound | Entra ID | Graph of paths to a Global Admin role |
Start with Prowler or ScoutSuite. Pacu comes next, to prove the impact of a role already identified — not to “see what goes through”.
3.2. Exposed storage
An S3 bucket, a Blob container, a GCS bucket: three names, one
mistake. The object is reachable with no authentication, or with an
AllUsers / anonymous ACL.
aws s3 ls s3://sauvegardes-prod-acme --no-sign-request
If that line lists prefixes, the finding is already Critical. You have not “hacked AWS”. You have read a resource the customer made public. The variants:
- Public listing, authenticated read: the attacker maps the store, then hunts a key elsewhere.
- A pre-signed URL valid for 7 days, sent by email, replayable.
- An Azure storage account with its key in an application variable, itself in a repository.
The remediation is not “turn on encryption”. SSE-S3 encrypts at rest for the provider; a public object stays readable. What closes the hole: blocking public ACLs (Block Public Access), explicit bucket policies, access via a role, access logs turned on.
3.3. Secrets in clear — and the metadata shortcut
Three places where an access key still turns up:
- A Git repository (history included:
git rmdoes not erase it). - An environment variable pasted into a Jira ticket, a Confluence screenshot, a CI job in clear.
- The instance metadata service.
Every cloud VM exposes a local link, often
http://169.254.169.254/. An application that fetches a URL supplied
by the user (image import, webhook, PDF) can be pushed to that
address: that is an SSRF that steals the machine’s role. On AWS,
IMDSv2 (required token, hop limit) shrinks the window sharply.
IMDSv1 remains the default on many old AMIs.
GET http://169.254.169.254/latest/meta-data/iam/security-credentials/
If that URL answers from the application, the finding is not “theoretical SSRF”. It is takeover of the EC2 role, hence often S3 read, sometimes assume of a higher role. Module 7 classified this as A10. Here you attach it to the cloud: the secret was not in the code, it was attached to the instance.
4. Mobile — the client is not a boundary
Essential difference from the web: the binary runs on a device the attacker can own. Root, emulator, TLS proxy, memory dump. Designing security as “nobody will decompile the APK” is a false assumption.
A screen that hides an admin button is not an access control. The
API must refuse. Lesson 11.2 shows it on a Flutter app: the
dashboard renders, the server returns 401. Do not confuse the two.
Three surfaces come back in almost every mobile engagement.
4.1. The binary — APK, IPA, bundle
An APK is a zip. apktool unpacks it, jadx decompiles it to
readable Java. Constants (API URL, “premium” key, feature flag, debug
endpoint) survive compilation.
apktool d application.apk -o apk-out
jadx -d jadx-out application.apk
strings application.apk | grep -iE 'api_key|secret|password|http'
On Flutter, the Dart code lives in libapp.so (or in
main.dart.js for the web build). The reflex is the same: hunt
strings, do not “break” the framework. Walkthrough 11.2 starts
from that grep. Here, keep the rule: if the backend needs a
secret, that secret has no business in the client. An API key in
the APK is no longer a key.
On iOS, the IPA unzips; Info.plist files and Swift/Obj-C binaries
yield the same URLs. A jailbreak is not required for the static
review.
4.2. Local storage
The app writes to disk. An attacker who has the device (or an unencrypted backup) reads:
| Platform | Typical location | Frequent trap |
|---|---|---|
| Android | SharedPreferences XML, SQLite databases | Session token in clear, password “for convenience” |
| iOS | UserDefaults, plist files, Keychain used poorly | Secret in UserDefaults instead of the Keychain |
| Flutter | shared_preferences, app files | Same mistake, cross-platform API |
The Keychain / Keystore can hold a secret. You still have to use it, with a protection level that requires the phone to be unlocked. An XML preference offers none of those guarantees.
4.3. Certificate pinning — what it does, what it does not
Without pinning, a proxy (Burp, mitmproxy) intercepts TLS as soon as the user accepts an enterprise CA — or as soon as the attacker controls the device. Pinning adds a check: the certificate (or the public key) must match the one the app shipped.
Three useful readings:
- Pinning absent: TLS interception is trivial on a device you control. That is the default case.
- Pinning present: it slows dynamic analysis. It does not make
the API safe. Frida and Objection still hook
TrustManager/boringsslon most apps. Pinning is friction, not a boundary. - Pinning + secrets in the APK: you just made the grep a little longer.
Mobile-review tools, in this order: static (apktool, jadx,
strings) then dynamic (frida, objection) on the lab or the
customer’s app. Lab 11.3 offers a non-Docker APK bonus for
anyone who wants the same reflex on a native binary.
5. IoT — the fundamentals are enough
An IoT pentest disappoints people who expect a radio 0-day. It reassures people who have already hardened Windows: you fall back on factory accounts, HTTP, a downloadable firmware.
Three questions, in this order.
5.1. Default account
admin:admin, root:vizxv, admin:12345. Public collections
(RouterSploit, vendor CVE lists) cover a decade of models. If the
password is not unique per device at the factory, the finding is
the same as Mirai in 2016. The remediation is organizational:
inventory, forced change at first login, retirement of hardware whose
vendor no longer ships patches.
5.2. Unencrypted service
Telnet, HTTP administration, MQTT without TLS, video streams with no
authentication. An attacker on the same LAN (or on the WAN if UPnP
opened a port) reads the session. Encryption does not replace
authentication: an RTSP over TLS with admin:admin still falls.
5.3. Recoverable firmware
Many vendors publish the .bin on their site, or the interface
serves it at /upgrade. binwalk extracts the filesystem.
strings dumps private keys, hardcoded passwords, unsigned update
URLs.
binwalk -e firmware.bin
strings firmware.bin | grep -iE 'admin|password|private|BEGIN RSA'
A secret in the firmware is a secret for the entire fleet of the same model. That is the IoT equivalent of the key in the APK.
The radio, WPA2-PSK, PMKID, deauth and the typical chain on an IP camera are covered in lesson 11.5. This page does not repeat them. Keep only the link: if the WiFi falls, the device falls within a minute. The defense that holds starts with segmentation (VLAN / IoT SSID) and inventory, not with an antivirus on the camera.
6. How you prioritize on an engagement
A week of pentest does not cover “the cloud, mobile and IoT”. You choose from the RoE and the value.
| Customer context | High priority | What you do not do first |
|---|---|---|
| SaaS hosted on AWS | IAM, buckets, metadata, Git keys | The AMI kernel |
| Mobile app + API | Bundle, local storage, API controls | A store 0-day |
| Sensor fleet | Factory defaults, HTTP, segmentation | Exotic radio protocols |
| SME with cameras | See 11.5: WiFi, RTSP, factory passwords | A non-public vendor exploit |
The IoT report insists more than the others on organizational remediations: inventory, VLAN, update cycle, a ban on UPnP. A firmware fix the vendor will never publish is not an actionable recommendation.
7. The confusions that cost time
- “The cloud is secure, so my S3 is.” The provider secures the foundation. The ACL is you.
- “We obfuscated the APK.” Obfuscation delays a human. It does
not remove a key from the apk.
stringsis often enough. - “Pinning replaces server-side auth.” No. It bothers the proxy. An IDOR remains an IDOR.
- “IoT = advanced radio attack.” In 2026, most IoT engagements close on a factory password and a port 80.
- “Pacu against AWS.” Pacu against the customer’s account, with a key the customer gave you, inside the written scope.
What to remember
Cloud, mobile and IoT are read with the same grid: who carries the responsibility, where the secret lives, and what an attacker already controls. In the cloud, the answer is almost always a policy (IAM, bucket, key, metadata). On mobile, everything that lives in the client will end up outside; the real control is the API. On IoT, the fundamentals — factory defaults, HTTP, firmware — close more incidents than a protocol exploit.
Next lesson: we apply the mobile grid to a deliberately weak Flutter app, from grepping the bundle through to the admin flag.