Post cover image

July 17, 2026

Web Pentester’s Guide to Thinking Like an IoT Pentester

IoT isn’t difficult because it introduces completely new security concepts. It’s difficult because it forces multiple security domains —…

By Muhammad Sameer

6 min read

IoT isn't difficult because it introduces completely new security concepts. It's difficult because it forces multiple security domains — web, mobile, cloud, radio — into a single ecosystem, all at once.

When I started learning IoT security, I expected to spend most of my time reversing firmware, soldering UART pins, and dumping flash chips.

That's certainly part of the job.

But after working real IoT assessments, I realized something that surprised me: the device is often the least interesting part of the engagement.

Most of what you need, you already have. IoT systems are mostly collections of technologies that web, mobile, and cloud pentesters already know how to break — just wired together in ways that create new trust relationships. The hard part isn't learning new attacks — it's recognizing where the real attack surface begins.

This isn't another list of IoT tools or firmware tricks. It's the mental model I use every time I walk into an unfamiliar IoT system — and I'll use one running example throughout: a cloud-connected home security camera.

The Device Is Just One Box in a Bigger Picture

None

Ask someone new to IoT what they want to attack, and the answer is almost always: "the device." That's understandable — it's the most visible component. But it's a narrow view.

Picture the camera the way most people do:

Camera

Now picture what it actually is:

Camera → Firmware → Wi-Fi → Gateway/Router → MQTT/HTTPS → Cloud Backend
→ REST API → Mobile App → User

Every one of those components is part of the attack surface. More importantly, every arrow between them represents a trust relationship: the mobile app trusts the cloud, the cloud trusts the device, the device trusts its firmware updates, the gateway trusts whatever connects to it. Compromising the firmware is only one way in. Sometimes the mobile app is softer. Sometimes the cloud API is wide open. Sometimes the MQTT broker just hands you everything.

So the question that actually matters isn't "how do I hack this camera?" It's "who does this camera trust, and why?" That reframe changes everything about how you spend your time on an assessment — and it's the thread running through the rest of this article.

Before Burp, I Draw

The first thing I do on a new engagement isn't launching Burp, opening Ghidra, connecting UART, or running Binwalk.

I sketch the architecture. Badly, if necessary.

Sensors → Microcontroller → Wi-Fi → MQTT Broker → Cloud → API → Mobile App

I don't care if it's accurate yet — the point is to see how data moves, because every arrow represents communication, authentication, authorization, encryption, and trust. Those arrows matter more than the boxes.

This is also where it helps to stop thinking of protocols as "networking details." From an attacker's perspective, MQTT, BLE GATT, CoAP, and REST all expose interfaces that accept, process, and exchange data. Different technologies, same mindset.

During recon, I keep asking one question for every component: "what talks to what?" Does the device call an API directly? Does the mobile app talk to the device, or only to the cloud? Does BLE do anything besides provision Wi-Fi credentials? Each answer surfaces another trust relationship, and eventually the architecture itself tells you where to spend your time.

The Rule of Five

Once I've identified a component — sensor, mobile app, cloud API, MQTT broker, gateway, firmware — I stop caring what it is and start asking what role it plays in the ecosystem. Over time, I realized I was asking the same five questions regardless of whether I was looking at firmware, MQTT, BLE, or a cloud API. Eventually, I wrote them down. Now they're the first five questions I ask whenever I encounter a new IoT component.

1. Who am I? How is this component identified — device ID, MAC address, certificate, JWT, API key? Identity is usually the foundation of everything else.

2. Who do I trust? Does the device trust the cloud? Does the cloud trust the device? Is that trust mutual, or one-directional? Breaking a trust relationship is often more valuable than exploiting a software bug.

3. How do I communicate? MQTT, BLE, HTTPS, CoAP, UART — the protocol itself is rarely interesting. What matters is what it assumes about the other side.

4. What secrets do I hold? Wi-Fi credentials, certificates, private keys, MQTT credentials, API tokens, OTA signing keys. Finding a secret is useful; understanding how it's used downstream is more valuable.

5. What happens if I'm compromised? Don't stop at "I compromised MQTT." Ask what that buys you. Can you unlock doors, push firmware, impersonate other devices, pivot into the cloud, affect the physical world? This is the question that turns isolated findings into attack chains — and it's the one I'll come back to below with the camera.

These five questions work on anything: a BLE characteristic, an MQTT broker, a cloud API, a firmware image, a Zigbee gateway. Even with zero prior knowledge of the underlying tech, they tell you where to dig next.

A Practical Methodology

With a rough architecture sketched and a sense of how components talk to each other, the next question is always: where do I actually start? I follow the flow of trust rather than the physical layout of the system:

Recon
│
├── Draw the architecture
├── Map communications
├── Identify trust boundaries
├── Follow identities
├── Follow secrets
│
▼
Cloud
│
▼
API
│
▼
Mobile
│
▼
Firmware
│
▼
Hardware
│
▼
Build attack chains

Notice hardware shows up near the end. That's deliberate, for reasons that will make more sense by the time we get to firmware.

Map every communication channel. Device↔cloud, device↔mobile, gateway↔cloud, mobile↔cloud, cloud↔third-party APIs — and the protocol behind each (HTTP, MQTT, BLE, Zigbee, CoAP, WebSocket, TCP/UDP). Don't think of these as networking plumbing. Think of them as places where input enters the system.

Find who owns identity. How does a new device register? Where are IDs generated, who issues certificates, does every device get unique MQTT credentials, or could a compromised camera impersonate the fleet? A broken provisioning process is a bigger finding than most memory-corruption bugs, because it scales.

Follow the secrets. API keys, JWTs, MQTT credentials, device certs, BLE pairing keys, Wi-Fi credentials, OTA signing keys — the interesting part isn't finding them, it's tracing how they move: cloud → mobile app → device provisioning → persistent storage. Whatever stage first exposes a secret, everything downstream inherits that weakness.

Treat the mobile app as documentation

IoT apps leak an enormous amount before you've touched hardware — hidden endpoints, MQTT topics, device UUIDs, BLE service definitions, auth flows, debug functionality. An hour with the APK routinely saves days of blind enumeration, which is exactly why firmware comes so late in the flow above: by the time you pull it, the app and the cloud API have already told you most of the story, and firmware is just filling in the remaining gaps rather than being the starting point.

Putting It Together: One Chain, Not Three Findings

This is where the camera pays off.

Say the assessment turns up three things, each unremarkable on its own:

  • The mobile app embeds a hardcoded MQTT username and password, meant for provisioning new cameras.
  • The MQTT broker accepts wildcard topic subscriptions (#) instead of scoping clients to their own device.
  • Firmware update packages pushed over MQTT aren't signature-checked before the camera installs them.
APK

↓

Extract MQTT Credentials

↓

Connect to Broker

↓

Subscribe to #

↓

Observe Update Topics

↓

Craft Malicious Firmware

↓

Push OTA

↓

Remote Code Execution

Individually, these might land in a report as one low and two mediums. Chained, they're a full compromise: pull the MQTT credentials from the APK, connect to the broker, subscribe to # and watch every camera on the fleet publish its telemetry and update topics, then craft a malicious firmware image and push it down the same unsigned update channel used for legitimate releases. One extracted secret plus one broker misconfiguration plus one missing signature check adds up to remote code execution across every device in the deployment — no firmware reversing required to get there, because the mobile app and the broker configuration told you everything you needed.

That's the difference between findings and an attack chain, and it's why clients respond to chains much better than to a list of severities: a chain describes impact, not just weakness.

The Question I End On

Before writing the report, I ask myself one last thing: if I had to compromise this entire ecosystem through a single entry point, which one would I pick? For the camera above, it's the mobile app — not because it's exotic, but because it's the shortest path to a credential that unlocks the rest of the chain. On other engagements it's been the cloud API, or an exposed broker, or occasionally firmware itself. It's almost never "the device" in isolation.

Final Thoughts

Coming from web or mobile security, IoT can look overwhelming — unfamiliar protocols, embedded devices, radio interfaces, firmware formats. It's tempting to assume you need to master all of it before your first assessment.

You don't. What's different isn't the skill set — it's the mindset. IoT systems are chains of components that trust one another, and every sensor, app, cloud service, API, gateway, and firmware image is a link in that chain.

The next time you pick up an IoT target, resist the urge to reach for UART or Binwalk. Spend thirty minutes drawing the architecture instead. Identify every component, every communication channel, and every trust relationship. Apply the Rule of Five to each one. You may find that the easiest path into the system has nothing to do with the hardware at all.

Stop thinking about devices. Start thinking about ecosystems.