8.2 Mobile Attack Vectors & Risks

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.

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

** at rest on the device (storage), in transit (communication), or at the back-end (server). ** the store/signing model (malicious app), the sandbox (root/jailbreak), TLS (MITM), or the user (phishing/smishing). ** encryption/keystore for storage, TLS/pinning for transit, root-jailbreak detection for the sandbox, app vetting for the store model, and phishing-resistant auth for the user. 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.