CEH Mobile Platform, IoT, and OT Hacking: 38 practice questions

12 of the 38 Mobile Platform, IoT, and OT Hacking questions in the Certsqill CEH bank, shown in full below. Each one carries an explanation for every option, not just the correct one — the wrong answers are where the marks go.

Preparing for CEH? Take the free 5-min readiness check →

1. Default credentials that cannot be changed: Which vulnerability represents the HIGHEST risk?

1. Default credentials that cannot be changed ✓

   Correct. Unchangeable default credentials (OWASP IoT #1: Weak/Hardcoded Passwords) represent the highest risk because they provide persistent, trivial access to any attacker who looks up the model's default credentials — with no remediation path available to the owner.
2. Firmware updates over HTTP without integrity verification

   Incorrect. Insecure update mechanisms are serious (OWASP IoT #9) but require a network MITM position to exploit. Unchangeable default credentials provide direct, immediate access to anyone on the network with no prerequisites.
3. Exposed Telnet interface on the local network

   Incorrect. An exposed Telnet interface is a significant risk but requires credentials to log in (unless they are default/hardcoded). The Telnet exposure is less severe if strong unique credentials were possible — but combined with unchangeable defaults, it amplifies the default credential risk.
4. Lack of encrypted storage for configuration data

   Incorrect. This vulnerability is not mentioned in the scenario. Evaluating unlisted vulnerabilities against those described in the scenario is not appropriate.

Unchangeable default credentials represent the highest IoT risk — they allow trivial authentication with no remediation path, affecting every deployed instance of the device model.

2. APK repackaging / trojanized application: What attack technique is this?

1. APK repackaging / trojanized application ✓

   Correct. APK repackaging decompiles a legitimate app, adds malicious code, and repackages it. Users who install the trojanized APK believe they have the legitimate app but run malware.
2. Tapjacking

   Incorrect. Tapjacking overlays a transparent malicious view over a legitimate app to capture taps intended for the legitimate app. It does not involve repackaging or modifying the application binary.
3. Man-in-the-Disk attack

   Incorrect. Man-in-the-Disk attacks exploit improper use of external storage (SD card) by legitimate apps to manipulate data between app downloads and installations. It targets the app's use of external storage, not APK modification.
4. Rooting exploit

   Incorrect. Rooting exploits gain privileged access to the Android OS. APK repackaging distributes malicious apps without requiring root — it operates at the application layer.

APK repackaging modifies legitimate apps with malicious code and redistributes them as trojans through unofficial channels, bypassing app store security reviews.

3. OT systems prioritize availability over security: Why is this approach problematic in most OT environments?

1. OT systems prioritize availability over security — unplanned downtime for patching can disrupt critical infrastructure, and vendor support for patches is often limited ✓

   Correct. OT/SCADA systems often cannot be patched without stopping operations, patches may not be available for legacy PLCs/RTUs, and vendors may void support warranties if unauthorized patches are applied. Availability (the 'A' in the OT CIA triad, inverted from IT) is paramount.
2. SCADA systems use proprietary encryption that prevents standard patch delivery mechanisms

   Incorrect. The barrier to patching OT systems is operational availability requirements and legacy hardware/software limitations, not encryption of the patch delivery channel.
3. Internet-connected SCADA systems automatically apply patches, making manual patch management redundant

   Incorrect. Most SCADA systems are intentionally air-gapped or isolated from the internet. Auto-patching is rare and often undesirable in OT environments due to testing requirements.
4. OT systems run on modern hardware that is not compatible with legacy vulnerability scanners

   Incorrect. The compatibility issue is the reverse — SCADA systems often run on legacy hardware and software (Windows XP, old PLCs) that modern patch tools may not support. This is an additional complication, but availability is the primary patching barrier.

OT/SCADA systems prioritize availability — patching requires downtime that may not be acceptable for critical infrastructure, and legacy hardware may have no vendor patches available.

4. M2: Insecure Data Storage: What OWASP Mobile Top 10 category does this primarily represent?

1. M2: Insecure Data Storage ✓

   Correct. M2 covers insecure data storage including using external/world-readable locations (SD card, shared preferences without encryption, SQLite without encryption) to store sensitive data like authentication tokens.
2. M3: Insecure Communication

   Incorrect. M3 covers insecure transmission of sensitive data over networks (e.g., plain HTTP, insufficient TLS validation). Storing data on device storage is a local storage issue, not a communication issue.
3. M4: Insecure Authentication

   Incorrect. M4 covers flaws in authentication mechanisms (weak passwords, missing MFA, insecure token validation). The authentication token exists — the problem is how it is stored, not how authentication is performed.
4. M1: Improper Platform Usage

   Incorrect. M1 covers misuse of platform security features (e.g., incorrect use of Android Keystore, improper Intents). While using external storage is arguably improper platform usage, M2 (Insecure Data Storage) is the more direct and precise classification for storing sensitive data in an insecure location.

Storing authentication tokens in plaintext on an SD card is M2: Insecure Data Storage — sensitive data should be stored only in platform-secured, encrypted storage mechanisms.

5. It bypasses iOS code signing enforcement and app: Beyond policy violation, what specific security risk does ja

1. It bypasses iOS code signing enforcement and app sandboxing, allowing unsigned code to run with elevated privileges and apps to access each other's data ✓

   Correct. Jailbreaking removes Apple's code signing checks (any binary can run) and the app sandbox (apps can read each other's data containers). It also typically installs Cydia and SSH, expanding the attack surface.
2. It permanently deletes all data on the device, requiring a full restore

   Incorrect. Jailbreaking does not delete user data — it modifies the OS to remove security restrictions. Data remains on the device (and becomes more accessible to malicious apps).
3. It automatically enrolls the device in the attacker's MDM server

   Incorrect. MDM enrollment requires explicit configuration. Jailbreaking does not automatically enroll the device in a remote MDM. It does, however, make the device more susceptible to unauthorized MDM profiles if malicious apps are installed.
4. It disables cellular and Wi-Fi functionality until the device is restored

   Incorrect. Jailbreaking does not disable hardware functionality like cellular or Wi-Fi. Network functionality remains operational — and in fact becomes more exploitable due to reduced security controls.

Jailbreaking disables iOS code signing and app sandboxing — unsigned malicious code can run with root privileges, and apps can access each other's previously isolated data containers.

6. Mount the squashfs filesystem and search for hardcoded: What is the researcher's NEXT most useful step to find

1. Mount the squashfs filesystem and search for hardcoded credentials, private keys, and configuration files containing sensitive data ✓

   Correct. After extracting the filesystem, searching for hardcoded credentials (grep -r 'password' .), private keys (find . -name '*.pem'), and config files is the highest-yield first step. Most IoT vulnerabilities are discovered in extracted filesystem content.
2. Flash the modified firmware back to the device to test runtime behavior

   Incorrect. Reflashing requires firmware modification and is a later stage after understanding what vulnerabilities exist. Static analysis of the extracted filesystem comes first — it's faster and non-destructive.
3. Run the firmware binary directly on the analyst's Linux system

   Incorrect. IoT firmware often targets embedded architectures (MIPS, ARM) incompatible with x86 analyst workstations. Direct execution is not possible without emulation (QEMU). Static filesystem analysis is the practical first step.
4. Decode the firmware's encryption key using the manufacturer's public key

   Incorrect. If the firmware were encrypted, binwalk would not have extracted a filesystem successfully. Since squashfs was extracted, the firmware is not encrypted — or the encryption was already handled. The key analysis step is inapplicable here.

After extracting an IoT firmware filesystem, the highest-yield first step is searching for hardcoded credentials, private keys, and sensitive configuration data in the extracted files.

7. IMSI catcher — captures IMSI numbers of all nearby phones: What attack is this and what is the primary capabil

1. IMSI catcher (Stingray) — captures IMSI numbers of all nearby phones and can intercept 2G/3G calls and SMS by downgrading connections ✓

   Correct. An IMSI catcher (StingRay, STING) impersonates a legitimate BTS. Phones connect to the strongest signal source, revealing their IMSI (International Mobile Subscriber Identity). Legacy 2G connections can be downgraded from encryption to cleartext.
2. Femtocell attack — exploiting operator-provided home cell extensions for SIM cloning

   Incorrect. Femtocell attacks target consumer small-cell base stations (femtocells) provided by operators for home coverage. IMSI catchers are active fake BTS devices deployed by attackers — not femtocells.
3. SIM swapping — social engineering a carrier to transfer a victim's number to an attacker's SIM

   Incorrect. SIM swapping is a social engineering attack targeting carrier customer service to transfer a phone number — no fake BTS hardware is involved.
4. Bluetooth snarfing — extracting data from Bluetooth-enabled phones via OBEX protocol

   Incorrect. Bluetooth snarfing exploits Bluetooth protocol vulnerabilities to extract data. The described attack uses cellular network impersonation — IMSI catcher targets the GSM/LTE radio interface.

IMSI catchers impersonate cellular base stations, capturing IMSI numbers and potentially intercepting 2G traffic via encryption downgrade attacks.

8. Missing MQTT authentication and authorization: What vulnerability is this?

1. Missing MQTT authentication and authorization — unauthenticated clients can subscribe to all topics (#) and receive or publish messages to any device ✓

   Correct. MQTT's '#' wildcard subscribes to all topics. Without authentication, any client can subscribe to all topics and receive all messages — including sensitive data and control commands. This enables information disclosure and device manipulation.
2. Insecure Direct Object Reference (IDOR) — accessing topic IDs that belong to other devices

   Incorrect. IDOR is a web application vulnerability involving unauthorized access via object references. MQTT topic access without authentication is a protocol-level misconfiguration, not IDOR.
3. Replay attack — resending captured MQTT messages to trigger device actions

   Incorrect. Replay attacks reuse captured messages. The described scenario is a passive subscription to an unauthenticated broker — the researcher is receiving live messages, not replaying captured ones.
4. DNS cache poisoning — redirecting MQTT broker hostnames to attacker-controlled servers

   Incorrect. DNS cache poisoning would redirect MQTT clients to a fake broker. The scenario involves directly connecting to the legitimate broker without authentication — not DNS manipulation.

MQTT brokers without authentication allow any client to subscribe to all topics (#), enabling unauthorized access to sensitive IoT data and the ability to send control commands to any device.

9. Over-privileged application: What security concern does this raise?

1. Over-privileged application — the excessive permissions beyond CAMERA indicate potential spyware, data harvesting, or Trojan functionality ✓

   Correct. A flashlight app legitimately requires only CAMERA permission (for flash control). Requesting READ_CONTACTS, LOCATION, READ_CALL_LOG, and SEND_SMS indicates data harvesting, tracking, or trojanized app behavior.
2. The app requires root access — dangerous permissions require device rooting

   Incorrect. The listed permissions are normal (not root/system) Android permissions that any app can request with user consent. Root access is a separate and much more serious privilege level.
3. The app will crash due to incompatible permission combinations

   Incorrect. Android does not prevent apps from requesting multiple unrelated permissions — they can all be granted simultaneously. The security concern is behavioral (what the app does with these permissions), not technical incompatibility.
4. The app targets API level below 23, which doesn't enforce runtime permissions

   Incorrect. The concern is the excessive and suspicious permission scope regardless of API level. While pre-API 23 apps requested all permissions at install time, the security concern here is the mismatch between app functionality and requested permissions.

A flashlight app requesting contacts, location, call logs, and SMS permissions is massively over-privileged — indicative of spyware, adware, or trojanized app behavior harvesting sensitive user data.

10. Eavesdropping and replay attacks: What attack is feasible against this configuration?

1. Eavesdropping and replay attacks — capturing and replaying Z-Wave S0 frames to control smart home devices ✓

   Correct. Z-Wave S0 security uses a temporary key (XOR with a static key transmitted in plaintext during pairing), making eavesdropped frames decryptable and replayable. Sniffed commands can be replayed to control lights, locks, and sensors.
2. Buffer overflow in the Z-Wave chipset's firmware — causing remote code execution

   Incorrect. While Z-Wave chipset vulnerabilities exist, the described scenario specifically involves S0 key exchange weakness — the attack enabled by this weakness is frame capture, decryption, and replay, not buffer overflow.
3. SQL injection in the hub's web management interface

   Incorrect. SQLi is a web application attack unrelated to Z-Wave protocol weaknesses. The vulnerability described is in the Z-Wave RF protocol layer, not the hub's web interface.
4. DNS cache poisoning to redirect hub update downloads to malicious firmware

   Incorrect. DNS cache poisoning is a network attack on DNS infrastructure. The Z-Wave S0 vulnerability is in the RF protocol authentication and encryption — not in network-layer update mechanisms.

Z-Wave S0 security transmits the network key in cleartext during pairing (XOR with known key), enabling attackers to eavesdrop on the key exchange and decrypt/replay all subsequent device commands.

11. Frida injects JavaScript into the running app process: Which approach allows Frida to bypass certificate pinni

1. Frida installs a custom CA certificate into the iOS trusted root store, making the proxy certificate trusted

   Incorrect because installing a CA in the trusted root store defeats OS-level trust validation but does not bypass application-level pinning. Certificate pinning explicitly checks that the server certificate matches a hardcoded value regardless of CA trust.
2. Frida injects JavaScript into the running app process to hook SSL/TLS API functions and replace the pinning validation logic at runtime, causing all certificates to be accepted ✓

   Correct because Frida is a dynamic instrumentation framework that hooks into running processes and replaces function implementations at runtime. Scripts like 'SSL Kill Switch' use Frida to hook Security.framework APIs (e.g. SecTrustEvaluate) and return success regardless of the certificate, bypassing application-level pinning.
3. Frida performs a man-in-the-middle attack at the TCP layer before TLS handshake, preventing pinning checks from executing

   Incorrect because Frida operates as a process-level instrumentation framework, not a network-layer proxy. The TLS handshake and pinning checks occur within the app process — Frida hooks those application functions.
4. Frida decrypts the compiled application binary and patches the pinned certificate hash directly in the app bundle

   Incorrect because this describes static binary patching, a different technique. Frida performs dynamic (runtime) hooking without modifying the binary on disk — static patching is a separate bypass method.

Frida bypasses certificate pinning by dynamically hooking SSL/TLS validation APIs at runtime, causing pinning checks to return success for any certificate.

12. The request adds a NAT port forwarding rule that exposes: What does this accomplish and why is UPnP dangerous

1. The request performs ARP poisoning, redirecting traffic for 192.168.1.50 to the attacker's machine

   Incorrect because UPnP AddPortMapping creates NAT port forwarding rules in the router, not ARP table manipulation. ARP poisoning requires a different protocol and operates at Layer 2.
2. The request adds a NAT port forwarding rule that exposes the internal server's SSH port (22) to the public internet on port 52000; UPnP is dangerous because it accepts these requests without authentication from internal hosts ✓

   Correct because UPnP IGD (Internet Gateway Device) protocol allows internal devices to request port forwarding through SOAP messages to the router's UPnP service. The router adds a mapping: external port 52000 → internal 192.168.1.50:22 (SSH). Since UPnP has no authentication, any internal attacker or malware can expose internal services to the internet on arbitrary ports.
3. The request exploits a SOAP injection vulnerability in the router's web interface to execute commands as root

   Incorrect because the request uses the legitimate UPnP AddPortMapping SOAP action — it is using UPnP's intended functionality, not exploiting a code injection vulnerability. The 'attack' is the UPnP design itself (unauthenticated port control).
4. The request enables the router to scan the internal network for all open SSH services and report back to the attacker

   Incorrect because UPnP AddPortMapping is a port forwarding directive — it does not instruct the router to perform network scanning. The attacker specifies a specific InternalClient IP and port.

UPnP AddPortMapping creates unauthenticated NAT forwarding rules, enabling any internal host (or malware) to expose internal services to the internet — a significant attack surface on home and SMB routers.

Other CEH domains

• Web Application Hacking — 100 questions →
• System Hacking Phases and Attack Techniques — 96 questions →
• Reconnaissance Techniques — 84 questions →
• Network and Perimeter Hacking — 81 questions →
• Cryptography — 35 questions →
• All 498 CEH questions →