Scenario Overview and Learning Goals
What you are practicing: handling a lost or stolen phone case from first report through actionable investigative outputs. This lab focuses on decision-making, coordination, and mobile-specific evidence opportunities that remain available even when the device is not in your possession.
What you will produce: a structured case timeline, a list of prioritized evidence sources (carrier, MDM, cloud, apps), a set of preservation actions, and a set of investigative questions answered with artifacts (for example: when the phone last checked in, whether it was wiped, whether SIM swap occurred, and what accounts were accessed after loss).
Scenario setup: A user reports their corporate-issued smartphone is missing. The phone may contain corporate email, chat, VPN, and MFA apps. The user is unsure whether it was lost or stolen. You are the responder tasked with containing risk and collecting evidence that can support both security response and potential HR/law-enforcement follow-up.
Key Concepts Specific to Lost/Stolen Phone Cases
Why these cases are different
When the device is missing, you often cannot perform a traditional acquisition. Your primary evidence comes from remote telemetry (MDM/EMM), cloud service logs (email, identity provider, collaboration tools), carrier records (SIM and network events), and user-side artifacts (the user’s other devices, screenshots, messages, and receipts). The goal is to reconstruct what happened and reduce ongoing exposure.
Two parallel tracks: containment and reconstruction
Lost/stolen phone handling runs two tracks in parallel: (1) containment to prevent further access (account actions, remote lock/wipe, token revocation), and (2) reconstruction to determine what data or accounts may have been exposed and whether the event is benign loss or adversarial theft.
Continue in our app.
You can listen to the audiobook with the screen off, receive a free certificate for this course, and also have access to 5,000 other free online courses.
Or continue reading below...
Download the app
Common attacker paths after phone theft
In practice, theft becomes a security incident when the attacker can bypass the lock screen, exploit notification previews, abuse saved sessions, or trigger account recovery flows. Another frequent path is SIM swap or SIM removal to intercept SMS-based MFA. Your investigation should explicitly test these hypotheses using available logs and records.
Lab Inputs: What to Ask for Immediately
User interview checklist (fast, factual)
Collect precise details that will later anchor your timeline. Ask for: last known location and time; whether the phone was powered on; whether it had a passcode/biometric; whether lock screen notifications were visible; whether the user received “new device sign-in” alerts; whether the user’s phone number stopped working; whether the user changed any passwords after the loss; and whether the user used personal accounts on the device (personal email, messaging, cloud storage).
Device and account identifiers
Request identifiers that help you query systems: phone number, device make/model, OS type and approximate version, corporate asset tag, IMEI/MEID if known, EID (eSIM) if available, and the primary corporate identity (UPN/email). If the user has the original box or carrier portal access, the IMEI is often printed there.
Context that changes your response
Determine whether the device is corporate-owned with MDM, BYOD with limited management, or unmanaged. Also determine whether it is used for MFA (authenticator app, push approvals, SMS), VPN, privileged admin tasks, or access to regulated data. These factors drive urgency and the scope of evidence collection.
Step-by-Step Workflow: First 60 Minutes
Step 1: Confirm device management status and last check-in
In your MDM/EMM console (for example, Intune, Workspace ONE, MobileIron), locate the device record and capture: last check-in time, compliance status, OS version, installed corporate apps, and recent management actions. Note whether the device is marked as “lost mode,” “pending wipe,” or “retired.”
Step 2: Apply containment actions in a controlled order
Choose actions that preserve investigative value while reducing risk. A typical order is: (a) place device in lost mode/lock with a message and callback number; (b) disable corporate access from that device if your platform supports device-based access controls; (c) revoke refresh tokens/sessions for high-risk apps; (d) reset passwords for the user if compromise is suspected; (e) remote wipe only when you have enough telemetry captured or when risk is unacceptable. Document the exact time each action was taken because it will affect subsequent logs.
Step 3: Protect the user’s identity and MFA posture
Immediately evaluate whether the phone number is used for SMS MFA or account recovery. If yes, coordinate with identity administrators to remove SMS as a factor, require stronger factors, and re-register authenticator apps on a new device. If the user reports loss of cellular service or unexpected carrier messages, treat SIM swap as likely and escalate to carrier verification steps.
Step 4: Preserve remote logs that may roll over quickly
Export or snapshot relevant logs from: MDM device actions and audit trail; identity provider sign-in logs; email access logs; VPN logs; and collaboration tool audit logs (chat, file sharing). Prioritize logs with short retention or high volume. The point is to capture a stable view before routine rotation or admin actions change the environment.
Step-by-Step Workflow: Same Day (2–8 Hours)
Step 5: Build a working timeline with “anchors”
Create a timeline with anchor points: last confirmed user activity on the phone; last MDM check-in; time of loss report; time containment actions were applied; first suspicious sign-in after loss (if any). As you add events, keep a column for “source system” (MDM, IdP, email, carrier, user statement) so you can later resolve conflicts.
Step 6: Investigate account access after the loss
Query identity sign-in logs for the user around the incident window. Look for: new device registrations, new MFA methods added, sign-ins from new geolocations, impossible travel patterns, repeated MFA prompts, and sign-ins using legacy protocols. Correlate these with email audit logs (mailbox access, forwarding rule creation, OAuth consent, mailbox delegation) and collaboration logs (new sessions, file downloads, sharing changes).
Step 7: Check for token reuse and “still signed in” sessions
Even with a locked phone, apps may remain signed in. Review your IdP and app logs for long-lived sessions continuing after the reported loss. If you see activity that continues without reauthentication, that is a strong indicator the device (or a stolen session token) is being used. Use session revocation and conditional access policies to force reauthentication.
Step 8: Evaluate remote wipe decision points
Remote wipe is a containment tool, but it can also remove on-device artifacts that might be recoverable if the phone is later found. Decide based on: sensitivity of accessible data; likelihood of recovery; whether the device is online; whether you already captured MDM telemetry; and whether you have alternative evidence sources. If you proceed, record the exact wipe command time and whether it was acknowledged by the device.
Evidence Sources and What Each Can Prove
MDM/EMM console artifacts
MDM data can show device posture and management actions: last check-in, IP address at check-in (if logged), OS build, installed managed apps, compliance state, encryption status, and a history of admin actions (lock, lost mode, wipe). In many cases, MDM is your best evidence for “device was online at time X” and “wipe was executed at time Y.”
Identity provider and directory artifacts
Identity logs can prove whether the user account was accessed after the loss and from where. They can also show changes to authentication methods, device registrations, and risk signals (unfamiliar sign-in properties). Directory audit logs can show password resets, group membership changes, and admin actions that might be attacker-driven.
Email and collaboration artifacts
Email and collaboration audit trails can show data exposure: large downloads, mass mailbox access, creation of forwarding rules, sharing links created, external sharing enabled, or unusual access to sensitive channels. These artifacts help answer “what data could have been accessed from the missing phone?”
Carrier and SIM-related artifacts
Carrier records can help confirm SIM swap, SIM change, port-out attempts, and service interruptions. Even without full call detail records, carrier portals often show SIM activation history and device association changes. If the user reports sudden loss of service, correlate that time with identity logs showing password resets or MFA changes.
Endpoint and secondary-device artifacts
The user’s laptop or desktop may contain evidence of follow-on compromise: phishing emails received after the loss, password reset confirmations, authenticator re-registration prompts, or browser sessions used to change account settings. Also consider any paired devices (smartwatch, tablet) that might still receive notifications or show last-known device location events.
Practical Lab: Work the Scenario with a Structured Playbook
Phase A: Intake worksheet (fill-in exercise)
Create a worksheet with these fields and fill them from the scenario: user name and ID; phone number; device type; corporate ownership; MDM enrollment status; last seen time/location; lock method; notification preview setting (unknown/disabled/enabled); apps used for MFA; and whether the phone is the only MFA device.
Phase B: MDM verification and exports (hands-on)
In your MDM, perform these actions and capture outputs: locate device record; export device details page to PDF or screenshot; export audit log entries for the device and the user admin actions; record last check-in timestamp and any IP address; check whether “Find my device” or location history is available and export if permitted. If your platform supports it, generate a device compliance report covering the incident window.
Phase C: Identity and app log queries (hands-on)
Run targeted queries for a 72-hour window around the loss. Collect: sign-ins by application; sign-ins by location; MFA events (approvals/denies/timeouts); device registration events; and OAuth consent grants. Then pivot: for any suspicious sign-in, list the user agent, IP, and app accessed, and check whether it aligns with a mobile device or a desktop browser.
Phase D: Suspicion scoring (decision exercise)
Assign a simple score to decide whether this is “likely lost” or “likely stolen/compromised.” Example scoring: +2 if SIM swap indicators exist; +2 if new MFA method added; +2 if sign-ins from new country; +1 if repeated MFA prompts; +1 if mailbox forwarding rule created; +1 if MDM shows device online after reported loss. Use the score to justify containment escalation (password reset, session revocation, wipe, carrier escalation).
Investigation Questions and How to Answer Them
Question 1: When was the phone last known to be under the user’s control?
Answer using the user’s last activity statement plus corroboration: last MDM check-in before the loss report, last successful mobile app sign-in, and any last-known location event. If these disagree, treat the earliest reliable timestamp as the “latest safe time” and note uncertainty.
Question 2: Was the phone online after it was reported missing?
Check MDM last check-in and any device heartbeat logs. If the device checked in after the report, note the network type if available (cellular vs Wi-Fi) and the IP/geolocation. This can indicate the phone is still powered and potentially in someone else’s possession.
Question 3: Did anyone access corporate accounts using the phone or its sessions?
Correlate identity sign-ins and application audit logs after the loss. Look for continued access without reauthentication, which suggests existing sessions. If you see access from mobile user agents consistent with the device model, that supports “phone used.” If access is from desktop browsers or automation, consider token theft or credential compromise instead.
Question 4: Is there evidence of SIM swap or phone-number takeover?
Use user-reported service loss time, carrier portal SIM change history, and identity logs showing password resets or MFA changes shortly after service loss. If SMS MFA was used, check for successful sign-ins that required SMS at that time. A tight time correlation is a strong indicator.
Question 5: Was the device remotely locked or wiped, and did it succeed?
Use MDM action logs: command issued time, device acknowledgment time, and final status (success/pending/failed). If wipe is pending and the device has not checked in, assume the device may still contain data until it comes online again.
Common Pitfalls and How to Avoid Them
Acting before capturing volatile telemetry
Immediate password resets and token revocations are often necessary, but they can also change the log story (for example, causing sign-in failures that obscure what was happening). Capture key exports first when feasible, especially MDM audit trails and identity sign-in snapshots.
Over-relying on the user’s memory
Users may misremember times and locations under stress. Treat user statements as one source and corroborate with system timestamps. When you cannot corroborate, record the uncertainty explicitly in your timeline.
Assuming “remote wipe” equals “problem solved”
A wipe command may not execute if the device is offline, in airplane mode, or has no connectivity. Always verify status and keep monitoring for check-ins. Also consider that account compromise can continue even after a wipe if credentials or tokens were already stolen.
Artifacts to Package for the Case File (Lab Deliverables)
Minimum evidence bundle
- MDM device details export (device identifiers, compliance, last check-in)
- MDM audit log export (lost mode/lock/wipe actions with timestamps)
- Identity sign-in logs for the incident window (including MFA events)
- Email and collaboration audit events relevant to access and sharing
- Carrier/SIM change confirmation (if available) or user-reported service disruption notes
- A single consolidated timeline table (event, timestamp, source, notes)
Example timeline table format
Timestamp (UTC) Event Source Notes 2026-01-05 18:12:00 User last remembers phone in taxi Interview Uncertain +/- 15 min 2026-01-05 18:25:10 Device last MDM check-in MDM IP 203.0.113.10 2026-01-05 19:03:00 Loss reported to IT Ticket Containment started 2026-01-05 19:10:22 Lost mode enabled MDM Audit Command acknowledged 2026-01-05 19:18:41 New sign-in to email from new location IdP Sign-in User agent: Mobile Safari 2026-01-05 19:20:05 MFA method added (SMS) Directory Audit Suspicious 2026-01-05 19:22:30 Session revocation executed IdP Admin Forced reauthOptional Extensions (If the Phone Is Recovered)
Recovery handling decisions
If the phone is recovered, treat it as potentially tampered. Before powering it on, coordinate with your mobile forensics capability and your MDM administrators. If it is already wiped, your focus shifts to cloud logs and any backups. If it is not wiped and is accessible, you may be able to extract additional artifacts depending on platform constraints and lock state.
Comparing recovered-device state to remote telemetry
Use the recovered device to validate earlier assumptions: confirm whether the device shows signs of passcode changes, new profiles, new SIM/eSIM, or new app installs. Compare those observations to MDM records (installed apps, configuration profiles) and identity logs (new device registration). Discrepancies can indicate tampering or gaps in telemetry.
