1200kmSECURITY RESEARCH
Loading interactive filters…

1200KM / simulation

T1461 Lockscreen Bypass — Attack Simulation

An adversary with physical access to a mobile device may seek to bypass the device’s lockscreen. Several methods exist to accomplish this, including: * Biometric spoofing: If biometric authentication is used, an adversary could attempt to spoof a mobile device’s biometric authentication mechanism. Both iOS and Android partly mitigate this attack by requiring the device’s passcode rather than biometrics to unlock the device after every device…

Complete technique description

An adversary with physical access to a mobile device may seek to bypass the device’s lockscreen. Several methods exist to accomplish this, including:

* Biometric spoofing: If biometric authentication is used, an adversary could attempt to spoof a mobile device’s biometric authentication mechanism. Both iOS and Android partly mitigate this attack by requiring the device’s passcode rather than biometrics to unlock the device after every device restart, and after a set or random amount of time.[SRLabs-Fingerprint][TheSun-FaceID] * Unlock code bypass: An adversary could attempt to brute-force or otherwise guess the lockscreen passcode (typically a PIN or password), including physically observing (“shoulder surfing”) the device owner’s use of the lockscreen passcode. Mobile OS vendors partly mitigate this by implementing incremental backoff timers after a set number of failed unlock attempts, as well as a configurable full device wipe after several failed unlock attempts. * Vulnerability exploit: Techniques have been periodically demonstrated that exploit mobile devices to bypass the lockscreen. The vulnerabilities are generally patched by the device or OS vendor once disclosed.[Wired-AndroidBypass][Kaspersky-iOSBypass]

Official technique definition · Open in the interactive matrix

Detection telemetry and configuration

These contracts are selected through exact technique-to-data-component relationships or explicitly labelled planning overrides. Configure a collector at the relevant observation point; a telemetry name alone is not coverage.

Application Permission · source-mapped

DC0114 collection page — Compare manifest declarations with runtime granted state using authorized package inspection and own-app permission checks.

Providers and collection configuration

  • Android logcat: Permitted logs from a consented test device/emulator; output depends on build, permissions and instrumentation.
  • Android dumpsys: Point-in-time service/package state on an authorized development device.
  • Instrumented test application: Own-app permission, API and state callbacks; not universal visibility into other apps.
  • Use a disposable emulator or owned development device with approved debugging. Record OS/API level, app version and instrumentation privileges.
  • Collect only relevant logcat buffers/tags and service snapshots; add explicit own-app instrumentation for events absent from OS logs.
  • Forward sanitized logs and compare before/after state. Remove test data and revoke debugging access after the lab session.

Required normalized fields: package, permission, declared, granted.

adb shell dumpsys package test.example.lab

Read-only snapshot on a consented debug device. Replace the example package with your owned test app. Output and access vary by Android build; this is not a permission-request event stream.

Illustrative collection event

Project-normalized synthetic JSON, not a native provider log, captured event, attack verdict or validated detection. A parser/adapter is required for a real SIEM. Example names, IPs and values are fictional.

{
  "schema": "1200km.telemetry.example.v1",
  "synthetic": true,
  "timestamp": "2026-09-27T12:00:00Z",
  "telemetry_id": "DC0114",
  "collector": "illustrative-lab-collector",
  "observation": {
    "package": "test.example.lab",
    "permission": "android.permission.CAMERA",
    "declared": true,
    "granted": false
  }
}

Visibility limits: Android tooling does not imply iOS coverage. Standard mobile apps cannot observe all other apps or protected OS internals; MDM status is not full API, filesystem or content telemetry.

Application State · source-mapped

DC0123 collection page — Instrument the owned app lifecycle and corroborate permitted service snapshots; distinguish app events from inferred gateway activity.

Providers and collection configuration

  • Android logcat: Permitted logs from a consented test device/emulator; output depends on build, permissions and instrumentation.
  • Android dumpsys: Point-in-time service/package state on an authorized development device.
  • Instrumented test application: Own-app permission, API and state callbacks; not universal visibility into other apps.
  • Use a disposable emulator or owned development device with approved debugging. Record OS/API level, app version and instrumentation privileges.
  • Collect only relevant logcat buffers/tags and service snapshots; add explicit own-app instrumentation for events absent from OS logs.
  • Forward sanitized logs and compare before/after state. Remove test data and revoke debugging access after the lab session.

Required normalized fields: package, state_before, state_after, source.

Illustrative collection event

Project-normalized synthetic JSON, not a native provider log, captured event, attack verdict or validated detection. A parser/adapter is required for a real SIEM. Example names, IPs and values are fictional.

{
  "schema": "1200km.telemetry.example.v1",
  "synthetic": true,
  "timestamp": "2026-09-27T12:00:00Z",
  "telemetry_id": "DC0123",
  "collector": "illustrative-lab-collector",
  "observation": {
    "package": "test.example.lab",
    "state_before": "background",
    "state_after": "foreground",
    "source": "own_app_callback"
  }
}

Visibility limits: Android tooling does not imply iOS coverage. Standard mobile apps cannot observe all other apps or protected OS internals; MDM status is not full API, filesystem or content telemetry.

Protected Configuration · source-mapped

DC0115 collection page — Use approved device-management/research-build interfaces to snapshot the specific protected setting; document privileges and unsupported fields.

Providers and collection configuration

  • Android logcat: Permitted logs from a consented test device/emulator; output depends on build, permissions and instrumentation.
  • Android dumpsys: Point-in-time service/package state on an authorized development device.
  • Instrumented test application: Own-app permission, API and state callbacks; not universal visibility into other apps.
  • Use a disposable emulator or owned development device with approved debugging. Record OS/API level, app version and instrumentation privileges.
  • Collect only relevant logcat buffers/tags and service snapshots; add explicit own-app instrumentation for events absent from OS logs.
  • Forward sanitized logs and compare before/after state. Remove test data and revoke debugging access after the lab session.

Required normalized fields: device_id, setting, before, after.

Illustrative collection event

Project-normalized synthetic JSON, not a native provider log, captured event, attack verdict or validated detection. A parser/adapter is required for a real SIEM. Example names, IPs and values are fictional.

{
  "schema": "1200km.telemetry.example.v1",
  "synthetic": true,
  "timestamp": "2026-09-27T12:00:00Z",
  "telemetry_id": "DC0115",
  "collector": "illustrative-lab-collector",
  "observation": {
    "device_id": "android-lab-1",
    "setting": "usb_debugging_enabled",
    "before": false,
    "after": true
  }
}

Visibility limits: Android tooling does not imply iOS coverage. Standard mobile apps cannot observe all other apps or protected OS internals; MDM status is not full API, filesystem or content telemetry.

Detection rules and analytic guidance

Open the dedicated detection workspace · Existing query engineering

DET0645 Detection of Lockscreen Bypass

MITRE detection strategy

AN1723 Analytic 1723

For Android, detect Lockscreen Bypass by correlating analyst-visible device/network evidence and management state; use streaming or batched telemetry only where the documented collector is deployed. Correlate Application Permission via Android Enterprise DPC / Application Vetting [DevicePolicyManager.getPermissionGrantState(); PackageManager manifest/requested-permission review]; Application State via Android Enterprise / EMM [Managed package inventory/status and package metadata]; Protected Configuration via Android Enterprise DPC [DevicePolicyManager policy/compliance/security-state queries and SecurityLog events where supported]. Alert on a sequence or state change inconsistent with the device/app baseline, approved management policy, or expected user workflow; do not infer unobserved API calls, file/process activity, or payload content from management state alone.

Platforms: Android.

  • Application Permission — android:DevicePolicyManager; channel DevicePolicyManager.getPermissionGrantState(); PackageManager manifest/requested-permission review.
  • Application State — android:EMM; channel Managed package inventory/status and package metadata.
  • Protected Configuration — android:DevicePolicyManager; channel DevicePolicyManager policy/compliance/security-state queries and SecurityLog events where supported.

AN1724 Analytic 1724

For iOS, detect Lockscreen Bypass from documented management, network, or vetting evidence; treat state queries as periodic observations rather than real-time events. Correlate Application State via Apple MDM [InstalledApplicationList / ManagedApplicationList]; Protected Configuration via Apple MDM [DeviceInformation / SecurityInfo / ProfileList / restrictions and compliance queries]. Alert on a sequence or state change inconsistent with the device/app baseline, approved management policy, or expected user workflow; do not infer unobserved API calls, file/process activity, or payload content from management state alone.

Platforms: iOS.

  • Application State — iOS:MDM; channel InstalledApplicationList / ManagedApplicationList.
  • Protected Configuration — iOS:MDM; channel DeviceInformation / SecurityInfo / ProfileList / restrictions and compliance queries.
Source rule directory and observation requirements

No exact-tagged Sigma source rule was imported. This does not establish that the technique is undetectable; the MITRE guidance and collection requirements remain relevant.

Before treating a rule as coverage

  1. Read the actual condition and logsource; identify attacker-side, victim-side or third-party visibility.
  2. Map native sensor fields, parse times and identities, then compile for the selected backend.
  3. Replay a behavior-positive case, a normal control, an authorized look-alike and a missing-telemetry case.
  4. Record matches and misses with rule version and source events. No match is inconclusive when required telemetry is absent.

Anomaly-based detection

No exact technique-specific Atlas model is present for T1461 in the selected source snapshot. The following is a design worksheet, not a newly validated model.

Anomaly engineering worksheet

Start from the exact analytic above. The collection-specific lenses below are analyst recommendations; they do not assert that an arbitrary statistical deviation detects this technique.

  • Mobile lab instrumentation: Per owned device, app version and permission state: unexpected API/permission changes, background activity and network destinations. OS privacy restrictions and emulator differences limit observability.
  1. Define an entity/peer group and feature; exclude the evaluation period from baseline training.
  2. Use representative normal and maintenance activity. Do not invent a production threshold from a synthetic example.
  3. Evaluate held-out behavior-positive and benign cases; measure false positives, misses and telemetry loss separately.
  4. Keep abnormality separate from maliciousness. Correlate with the behavior-specific source evidence.

Anomaly Detection Atlas · Baseline, validation and blind spots

Attack tools and documented software

No reviewed lab-tool association is selected for this exact technique. This is a curation gap, not a statement that no tool can implement the behavior.

Software observed in source procedures

These are exact ATT&CK software-use relationships, including malware. They provide behavior context, not recommendations to download or execute malware. No safety or detector claim is inherited.

4 source-documented software associations
  • S1083 Chameleon — malware.

    Chameleon has the ability to bypass the biometric prompt for unlocking an infected device, forcing the victim to use PIN authentication. To do so, Chameleon will first check specified conditions, then will use the AccessibilityEvent action to transition from biometric authentication to PIN authentication.[ThreatFabric_Chameleon_Dec2023]

    Exact relationship: relationship--b14a1e23-e1ce-46ec-b4f2-414a13a8b6a7
  • S1092 Escobar — malware.

    Escobar can request the `DISABLE_KEYGUARD` permission to disable the device lock screen password.[Bleeipng Computer Escobar]

    Exact relationship: relationship--48cd0af5-9ad1-44b3-beeb-d576974dadee
  • S1094 BRATA — malware.

    BRATA can request the user unlock the device, or remotely unlock the device.[securelist_brata_0819]

    Exact relationship: relationship--4159bc09-ddf3-4d88-9bf0-853ace9c8151
  • S9006 VajraSpy — malware.

    VajraSpy has requested for `android.permission.DISABLE_KEYGUARD` to disable the device lock screen password.[K7Dhanalakshmi_VajraSpy_April2022]

    Exact relationship: relationship--7e5a6195-11f7-4862-845c-78a9c4fea3fc

Simulation design and documented procedures

Atomic evidence: no compatible candidate in this snapshot. Live lab status: not run for these imported procedures.

Use owned test devices or emulators, disposable app accounts and test data. Verify platform/version instrumentation; desktop test procedures do not establish mobile coverage.

No compatible Atomic procedure is present in this pinned evidence set. Technical feasibility has not been ruled out. A custom procedure must define the behavior, target, collection point, success observable and rollback before execution.

Technique-specific experiment contract

  1. Choose one procedure implementing T1461 Lockscreen Bypass; identify the observable behavior in the source definition, not just its tactic.
  2. Record exact target, tool/version, inputs, privileges, network limits and approval. Never run an imported default target automatically.
  3. Enable the collection sources above and verify a benign baseline reaches the detector.
  4. Run only the approved isolated scenario; capture native events and an independent behavior observable.
  5. Evaluate the exact rule/model, restore the lab, and preserve configuration, event hashes, alerts, controls and misses.

Synthetic logs and offline contract check

Download synthetic collection fixture (JSON) · Download the complete engineering workbook

This fixture exercises the listed collection fields. It does not reproduce Lockscreen Bypass, label its example events as malicious, or measure detection effectiveness. Use the exact analytic and selected procedure to build an independently labelled behavior-positive dataset.

Not run in this browser. No network scan or attack command is executed by this control.

Validation status and remaining work

Source identity
Joined by exact technique/object IDs against hash-pinned sources.
Collection fixture
Available for offline schema exercises; not attack emulation.
Native telemetry / backend / real attack
Not validated for these imported procedures. Source fidelity and page tests cannot establish sensor or detector effectiveness.

All-page audit and evidence inventory · This page’s machine-readable workbook

Sources and evidence boundaries

Pinned MITRE STIX source · SHA-256 824f7d8a37e7893b29e4c6ca6d87b5fbbf3b228ec6384f1a69ee20d523ff59e5. Definition and procedure context are reproduced from this snapshot, not independently re-investigated incidents.

Source-linked mitigations
  • M1001 Security Updates

    OS security updates typically contain exploit patches when disclosed.

  • M1012 Enterprise Policy

    Enterprises can provision policies to mobile devices that require a minimum complexity (length, character requirements, etc.) for the device passcode, and cause the device to wipe all data if an incorrect passcode is entered too many times. Both policies would mitigate brute-force, guessing, or shoulder surfing of the device passcode. Enterprises can also provision policies to disable biometric authentication, however, biometric authentication can help make using a longer, more complex passcode more practical because it does not need to be entered as frequently.

Connected ecosystem references

Linked tags

Detection and collection

T1461 detection workspace

No reviewed association in this snapshot.

Pinned research references. No browser attack runner or production-validated detector is asserted. Imported procedures remain unvalidated; any bounded lab evidence has its own scope. ATT&CK / Atomic provenance · Detection provenance.