Skip to content
Free lab · no signup · Mobile log triage

Mobile Log Triage (Android & iPhone)

A synthetic shift of MDM, logcat, iOS unified log, mobile threat defense, identity and network events from a mixed Android and iPhone fleet. Most entries are routine. Flag the ones that are not, name the field that gives them away, and map each to MITRE ATT&CK Mobile.

Tiers
Trainee · Analyst · Lead
Logs per shift
400–1000
Attack types
6

Your journey → certificate

BronzeSilverGold

Loading your progress…

All log triage tracks and the capstone · practice certificates, not accredited credentials.

1 in 5 logs hides an attack. 400 logs in the practice set.
10 logs ≈ 3 minutes → a graded shift scorecard you can share.

How to play: a 20-second start

  1. Pick a log in the inbox. Most are normal operations; a few are attacks.
  2. In the detail pane, click any field value that looks wrong.
  3. Hit Check: green = a real flag caught, amber = a flag missed, red = false alarm, each with a “why”.
  4. Stuck? Press Reveal to learn the answer (not scored). Use End shift for your report.
0Reviewedof 400
0Signals caught
0Missed
0False alarms
0%Recallof red flags
0Streak
0/10 logs to your shift scorecard
Inbox400 logs
Android logcatinfoL100365 · 23:58:49 UTC

Device policy controller active: MDM agent

m.okonkwo

Click any field value you think is a red flag (or press 1–9), then Check.

0/10 logs to your shift scorecard

How scoring works

Your shift score (0–100) is 60% red-flag recall (the suspicious fields you caught) plus 40% flag precision (how many of your flags were real). Only logs you check without pressing Reveal count. Check 10 logs, at least one of them an attack, and you get a graded scorecard with a share link. The score is recomputed on the server from the same deterministic log set, so a saved card always matches what you flagged. The daily shift is the same set for everyone that UTC day. Every log is synthetic: no real devices, people or networks.

Attack types in this track

Malicious or sideloaded app

An app installed outside the managed store, with an odd signer, a misspelt package name or permissions far beyond its stated purpose.

  1. Block the package hash and signer in MDM and remove it from the device.
  2. Revoke the user's sessions and reset credentials the app could have seen.
  3. Search the fleet for the same package name, hash or signer.

Privilege and trust abuse

Root or jailbreak, a non-MDM device administrator, a trusted unknown enterprise developer, or an OS build with known exploited flaws.

  1. Mark the device non-compliant so conditional access cuts off company data.
  2. Remove the rogue admin or trusted developer, or wipe the work profile.
  3. Re-enrol on a clean, current OS before restoring access.

Credential and MFA theft

Codes read from SMS or notifications, push bombing until one is approved, or a phone's token replayed somewhere else.

  1. Revoke all refresh tokens and sessions for the user.
  2. Move the user to phishing-resistant MFA with number matching or passkeys.
  3. Review sign-ins and mailbox rules created since the first sign of theft.

Network interception

An evil-twin SSID, an open network posing as corporate Wi-Fi, an unknown CA in a TLS chain, or a user-installed root certificate.

  1. Disconnect the device and remove any unmanaged profile or root CA.
  2. Rotate credentials used while on the network.
  3. Enforce per-app VPN and certificate pinning for company apps.

Stalkerware and data collection

A hidden app with background location, microphone, call-log or screen-recording access that has nothing to do with its name.

  1. Talk to the user privately first: stalkerware can signal personal-safety risk, and removal may alert whoever installed it.
  2. Preserve evidence, then remove the app and reset the device credentials.
  3. Check for a shared or attacker-held cloud account on the device.

Smishing and mobile phishing

A text or QR code that pulls the user to a look-alike domain on their phone, where desktop link scanning cannot see it.

  1. Block the domain at DNS and in the mobile threat defense policy.
  2. Find every recipient and check who opened the link.
  3. Reset credentials for anyone who entered them and warn staff about the lure.

FAQ

Are these real device logs?

No. Every user, device, app and domain is fictional and generated in your browser from a fixed seed. The field names follow what MDM, logcat, the iOS unified log and mobile threat defense tools typically record.

Why do the benign and suspicious logs look so alike?

Because they do in real life. A configuration profile pushed by MDM and one a user downloaded from a website produce nearly the same event. The difference is in fields like who installed it, who signed it and what payload it carries.

Is an accessibility service always malicious?

No. Screen readers and some password managers need it. It becomes a red flag when the app is sideloaded, not on an approved list, or has nothing to do with accessibility.

Why is one technique id an Enterprise id?

MFA push bombing targets the identity provider rather than the phone, so ATT&CK lists it in the Enterprise matrix as T1621 Multi-Factor Authentication Request Generation. The rest map to ATT&CK Mobile.

What should I do first with a jailbroken or rooted device?

Cut it off from company data through conditional access, then wipe or re-enrol it. A broken OS security model means you cannot trust anything the device reports about itself.

The tools people use most on PlayCISO.

All tools
🖤 Black Friday: new customers get 3 months of Pro for $5, then $5/month. Ends 30 Nov. See the deal