Study guide
8.2 Mobile Attack Vectors & Risks
EC-Council Certified Ethical Hacker CEH
Track your progress as you read
Finished sections get a check mark.
1 Introduction & Exam Overview
1.1 CEH Exam Format, Cost & Eligibility 1.2 The Five Phases of Ethical Hacking 1.3 Information Security Fundamentals 1.4 Ethical Hacking Concepts, Scope & Legal Framework 1.5 The CEH Domains & Your Study Priority Map
2 Reconnaissance, Footprinting, Scanning & Enumeration
2.1 Footprinting & Reconnaissance Concepts 2.2 Footprinting Sources & Techniques 2.3 Network Scanning Concepts 2.4 Banner Grabbing, OS Fingerprinting & Scanning Beyond IDS/Firewall 2.5 Enumeration 2.6 Vulnerability Scanning & Countermeasures
3 Vulnerability Analysis & System Hacking Phases
3.1 Vulnerability Analysis Concepts 3.2 System Hacking Methodology Overview 3.3 Gaining Access: Password Attack Concepts 3.4 Privilege Escalation Concepts 3.5 Maintaining Access: Backdoors, Rootkits & Persistence 3.6 Covering Tracks, Anti-Forensics & Blue-Team Detection
4 Malware Threats, Sniffing & Social Engineering
4.1 Malware Concepts and Taxonomy 4.2 Malware Analysis and Detection 4.3 Sniffing Concepts and Layer 2 Attacks 4.4 Sniffing Countermeasures and Detection 4.5 Social Engineering Types and Human Psychology 4.6 Social Engineering and Insider Threat Defenses
5 Network & Perimeter Hacking
5.1 Denial of Service and DDoS Attacks 5.2 Session Hijacking 5.3 Evading IDS and IPS (Defensive Focus) 5.4 Evading Firewalls 5.5 Evading Honeypots and Defensive Deception 5.6 Network Security Controls and Architecture 5.7 Packet Analysis and Secure Protocols for Defenders
6 Web Server & Web Application Hacking
6.1 Web Server Attacks & Hardening 6.2 OWASP Top 10 Overview 6.3 Injection: SQL Injection & Command Injection 6.4 Cross-Site Scripting (XSS) & CSRF 6.5 Authentication, Session & Access-Control Flaws 6.6 API & Web App Security Testing Concepts
7 Wireless Network Hacking
7.1 Wireless Concepts and Standards 7.2 Wireless Encryption 7.3 Wireless Threats and Attack Concepts 7.4 Wireless Security Countermeasures
8 Mobile Platform, IoT & OT Hacking
8.1 Mobile Platform Threats & Security Models 8.2 Mobile Attack Vectors & Risks 8.3 Mobile Device Management & Enterprise Defense 8.4 IoT Hacking Concepts & Defense 8.5 OT, ICS & SCADA Security
9 Cloud Computing & Cryptography
9.1 Cloud Computing Concepts 9.2 Cloud Threats & Attack Surfaces 9.3 Cloud Security Controls 9.4 Cryptography Fundamentals 9.5 PKI & Cryptographic Applications 9.6 Cryptanalysis, Crypto Attacks & Best Practices
8.2 Mobile Attack Vectors & Risks
Key Takeaways Explain This Topic AI
Malicious or repackaged apps are the dominant mobile malware delivery vector; sideloading and unofficial stores amplify the risk
Rooting (Android) and jailbreaking (iOS) disable platform protections, breaking the sandbox and code-signing trust model
Insecure data storage on the device exposes credentials and tokens if the device is lost, stolen, or compromised
Mobile man-in-the-middle (MITM) typically exploits rogue or open Wi-Fi plus missing TLS validation or certificate pinning
SMS one-time passwords (OTP) are phishable and SIM-swap-vulnerable; phishing-resistant factors such as FIDO2/WebAuthn are stronger
Last updated: September 2026
How Mobile Devices Get Compromised
CEH frames mobile risk around vectors (how an attacker reaches the device) and countermeasures . You should be able to match a described scenario to its vector and name a defense. No exploitation procedures are presented here — this is detection and prevention only. The mobile-specific tooling CEH references for authorized analysis includes the Mobile Security Framework (MobSF) for static/dynamic app analysis, drozer for Android attack-surface assessment, Frida and Objection for runtime instrumentation, and Burp Suite as the intercepting proxy when testing app-to-server traffic.
You should recognize these as assessment tools, not memorize attack steps.
Malicious & Repackaged Apps
The most common mobile malware path is a malicious application : a hostile app, or a legitimate app that has been repackaged with added malicious code and redistributed through a sideloaded APK file or an unofficial store. Trojanized utilities, fake updates, and cloned banking apps are typical lures. Repackaging works because Android accepts self-signed certificates, so an attacker can decompile, inject code, re-sign, and redistribute.
Why it works: users grant broad permissions on install/runtime; sideloading bypasses store review.
Defenses: install only from official stores, enforce app vetting/reputation, block sideloading via policy, run a Mobile Threat Defense agent, and apply least-privilege permission review.
Rooting and Jailbreaking Risk
Rooting (Android) and jailbreaking (iOS) remove vendor-imposed restrictions to gain privileged (root/superuser) control. Users often do this for customization, but the security cost is severe:
It can break the app sandbox and weaken or bypass code-signing enforcement.
It disables some OS integrity protections and may stop the device from receiving timely security updates.
It expands what malware can do once present, since privilege boundaries are gone.
Defense: root/jailbreak detection inside sensitive apps, plus Mobile Device Management policy that blocks or quarantines compromised devices from corporate resources via conditional access .
Insecure Data Storage
If an app writes credentials, session tokens, or personal data to the device in plaintext (shared preferences, SQLite databases, cache files, or logs), that data is exposed when the device is lost, stolen, backed up insecurely, or running on a rooted/jailbroken OS. Defense: store secrets in the platform hardware-backed keystore/Keychain , encrypt local data, minimize what is stored, and never log sensitive values.
- Network and Authentication Vectors
- Mobile Man-in-the-Middle (MITM)
A man-in-the-middle (MITM) attack on mobile usually combines a rogue or open Wi-Fi access point with an app that does not properly validate the server's TLS certificate. If validation is weak or disabled (accepting any/expired/self-signed certificate), traffic can be intercepted, read, or altered. Captive-portal and evil twin access points are common setups.
Defenses: enforce TLS everywhere, implement certificate pinning (bind the app to an expected certificate or public key) for high-value endpoints, discourage untrusted Wi-Fi, and require an enterprise or per-app VPN for corporate traffic.
Smishing and SMS / OTP / SIM-Swap Risk
Smishing (SMS phishing) lures users via text message to credential-harvesting pages or malicious downloads. Closely related, SMS-delivered one-time passwords (OTP) are widely used but weak:
They can be phished in real time — the victim relays the code to a fake site while the attacker logs in.
They can be intercepted via signaling-network (SS7) weaknesses.
They can be stolen through SIM-swap social engineering, where the attacker convinces the carrier to port the victim's number to a new SIM.
Vector Primary weakness Best countermeasure
Malicious / repackaged app Sideloading + broad permissions Official stores, app vetting, block sideloading, MTD
- Rooting / jailbreaking Sandbox + signing bypass Root/jailbreak detection + MDM conditional access
- Insecure data storage Plaintext secrets at rest Hardware keystore, encryption, data minimization
- Mobile MITM (rogue Wi-Fi) Weak TLS validation TLS + certificate pinning + enterprise VPN
- Smishing / SMS OTP / SIM swap Phishable, portable factor Phishing-resistant authenticators (FIDO2/WebAuthn)
Stronger authentication alternatives: authenticator apps with time-based codes, push-based approval with number matching , or phishing-resistant hardware/platform authenticators (FIDO2/WebAuthn). These bind the credential to the legitimate origin, so a relay/phishing site cannot reuse them. Treat SMS OTP as a fallback, never the primary high-assurance factor.
Additional Vectors and How to Reason About Them
Beyond the core five, CEH may describe other mobile vectors. Recognize them by their mechanism and pair each with a defense:
Malicious / fake Wi-Fi profiles and configuration profiles: an attacker tricks a user into installing a profile that adds a rogue certificate authority or VPN, enabling silent interception. Defense: block untrusted profile installation through MDM and educate users.
Bluetooth and proximity attacks: unnecessary Bluetooth/NFC services or pairing weaknesses expand the surface. Defense: disable unused radios, require confirmed pairing.
Lock-screen and physical access: weak passcodes, no biometric, or no auto-lock expose a lost device. Defense: enforce strong passcode/biometric, short auto-lock, and full-device encryption.
Clipboard and inter-process data leakage: sensitive data copied to a shared clipboard or exposed through an exported component (Android) can be read by another app. Defense: restrict clipboard in managed apps, avoid exporting sensitive components.
Mobile phishing through apps and links: beyond smishing, in-app links and OAuth consent screens can be spoofed. Defense: user awareness, link inspection, and restricting OAuth scopes.
A Repeatable Method
First, locate the exposed data: at rest on the device, in transit, or at the back-end server. Second, identify the failed trust boundary: app distribution/signing, the operating-system sandbox, peer authentication on the network, or user authentication. Third, choose a matching control: protected storage and keystores, correctly validated TLS (and pinning where appropriate), device-integrity checks as one signal, app vetting, or phishing-resistant authentication. No single check proves that a device or app is trustworthy. This decision path lets you answer scenario questions even when the wording is unfamiliar, because every mobile control maps cleanly back to one of those broken trust relationships. The exam rewards this structured mapping far more than memorizing tool names.