44. Mobile Device Security – Android, iPhone, Bluetooth and Wi-Fi
Chala mitrano, Chapter 43 madhe IoT / OT baghitla – aata mobile phones. Pocket madhe full computer: bank apps, OTP, WhatsApp business, camera, GPS. CEH exam modules madhe mobile topic yeto, pan aapan he shikto defence-first: lost phone, rogue APK, evil twin Wi-Fi, Bluetooth pairing risk – kasa Blue harden karto. Ghabru naka – OWN emulator / second test phone / host-only lab (Kali 192.168.56.10, optional target 192.168.56.50). Neighbour / colleague / stranger cha phone never. Stalkerware, OTP steal, silent spyware recipes – nahi. Lakshat theva: phone hacked aahe ka? – checklist + cleanup from a clean device; scare tactics with invented numbers nahi.
What you will learn in this chapter
- Mobile threat model – lost/stolen, malware, phishing, rogue apps, network attacks
- Android security basics – permissions, Play Protect concepts, sideloading risks (Blue hardening)
- iPhone / iOS basics – App Store, sandbox, Lockdown Mode awareness (Blue hardening)
- Signs a phone may be compromised – practical checklist, no invented scare stats
- Cleanup / response – passwords from a clean device, revoke sessions, factory reset last, bank / CERT awareness
- MDM / BYOD concepts for SME (fictional Sahyadri Traders)
- Bluetooth risks – pairing hygiene; BlueBorne-class awareness only (no exploit recipes)
- Wi-Fi on phones – evil twin / captive portal awareness; HTTPS / VPN concepts; own lab only
- App permissions, screen lock, biometrics, encryption at rest, updates + permission-hygiene lab
- Project Build-Hack-Fix for Raja-Rani Traders + ethics / IT Act (never touch others' phones)
Lab scope
Practice only on devices and VMs you own: Android emulator, a spare test phone you wiped, or host-only lab (Kali 192.168.56.10, Metasploitable 192.168.56.20, optional mobile-portal VM 192.168.56.50). Never install stalkerware, never steal OTP / SMS from someone else's phone, never pair Bluetooth "for fun" to strangers' earbuds, never run evil-twin gear against café / college Wi-Fi users. BlueBorne / Stagefright / Pegasus names = awareness and patching, not weaponized recipes. IT Act sections such as 43 and 66 apply if you access others' devices or accounts without authority (verify current text). Lab = learn hardening. Other people's phones = out of scope forever.
Concepts in this chapter
- 44.1Mobile Threat Model – What Can Go Wrong
- 44.2Android Security Model – Permissions, Play Protect, Sideloading
- 44.3iPhone / iOS Security Model – App Store, Sandbox, Lockdown Mode
- 44.4Signs a Phone May Be Compromised – Practical Checklist
- 44.5Cleanup and Response – If You Believe the Phone Is Compromised
- 44.6MDM and BYOD – SME Concepts for Sahyadri Traders
- 44.7Bluetooth Risks – Pairing Hygiene and BlueBorne Awareness
- 44.8Wi-Fi on Phones – Evil Twin and Captive Portal Awareness
- 44.9Hardening Checklist and Permission-Hygiene Lab
- 44.10Project, Ethics, IT Act and Purple Interview Lines
The chapter recap is at the end of the last concept page.
Chapter 44: Mobile device security — practice tasks
Open chapter lessons · Full guided lab: phone security check up android iphone (not repeated here)
44.1 Phone security check-up
EasyITWhy: Phones hold email and bank apps.
What: Run through the linked check-up on your phone.
How:
- Screen lock on.
- OS updated.
- App permissions reviewed.
- Find My Device / Find My iPhone on.
Expected output: All four Yes.
Hint
Remove unused apps with payment access.
Answer / how to check
- Written Yes/No list.
44.2 Sideloading risk (paper)
EasyBankingWhy: Apps outside official stores bypass review.
What: Mark each install path Safe or Risky.
Data file: mobile.csv
| Install path |
|---|
| Google Play / App Store |
| APK from a Telegram link |
| USB debugging left on |
About this file: Made-up install paths. Each row is one path to judge.
How:
- Read the data file.
Expected output: Play Store/App Store Safe; unknown APK Risky; USB debug on daily phone Risky.
Hint
Bank apps especially.
Answer / how to check
- Two Risky items.
44.3 Bluetooth hygiene
EasyHealthcareWhy: Open Bluetooth is a quiet risk.
What: On your phone, review paired devices.
How:
- Forget devices you don't use.
- Turn Bluetooth off when not needed.
- Avoid accepting pair requests from strangers.
Expected output: Unused devices removed.
Hint
Clinic staff: watch for fake pairing near wards.
Answer / how to check
- Paired list is short and known.
Extended teaching notes
Why this lesson matters
Cameras, sensors and plant controllers often ship with weak defaults. Segment them from IT, change passwords, block inbound internet, and watch outbound traffic.
Real examples
Global: Mirai showed what default passwords on routers/cameras can do at scale. Indian SME (sample): a factory puts PLCs on a separate VLAN reachable only via a jump host.
Mini case study
Suppose we are on a purple-team exercise for an Indian mid-size company (sample data). Red notes a technique from this lesson against a lab clone. Blue must show the control that stops it, the log that would have fired, and the ticket that hardens production. That is the standard this course trains you for.
Defender's worksheet (do this today)
- Write the lesson title, date and the exact lab target you are allowed to use.
- List three owned systems (VMs, apps, or cloud accounts) where this lesson applies.
- Run one safe check from the lesson on a lab system only. Paste the command and output.
- Write a two-sentence fix you would give a teammate.
- Name one related public advisory (CERT-In, CISA, NVD, or a vendor bulletin) with its date.
Indian workplace (sample data)
Suppose we are a junior analyst at Infosys, TCS, Wipro or a fintech SOC in Bengaluru/Pune. Turn this lesson into one checklist item with an owner, a due date and a place to store evidence (ticket + screenshot).
Global practice
Compare your notes with OWASP, CIS Benchmarks, NIST CSF/IR guidance or a cloud Well-Architected security question. Write five lines on what overlaps.
Everyday analogy
Explain the risk and the fix to a family member without jargon. If they can repeat the warning, you understand it well enough to teach juniors.
Key terms
- Control: a safeguard (patch, config, process, detection).
- Finding: a weakness backed by evidence.
- Remediation: the fix plus how you verified it.
- Scope: systems you have written permission to touch.
- Least privilege: only the access the task needs.
- Defence in depth: several layers so one failure does not end the story.
Common mistakes
- Skipping written permission "just for a quick scan".
- Practising on hostel, office or public targets without authorisation.
- Collecting tool output without writing the fix.
- Copying attack steps onto production to "verify". Defenders verify with versions, configs and patches.
- Publishing screenshots that contain secrets, cookies or internal hostnames.
Recap
- Evidence, fix, owner, date.
- Own lab only.
- Fix > spectacle.