Laptop Stolen at Airport: Emergency Remote Wipe via RMM

LIMEHAWK - Managed IT

Home>Incident Reports>Laptop Stolen at Airport: Emergency Remote Wipe via RMM

Time to wipe

16 minutes from theft

Incident

Friday, 4:47 PM. Sales rep calls from an airport — laptop bag was sitting next to her seat at the gate, she walked 30 feet to a phone charging station, came back five minutes later, laptop was gone. Ticket came in as "laptop stolen at airport - need help."

Within two minutes of pulling the device up in the RMM console we had the worst-case confirmation: the agent was online, and the public IP was not the airport's WiFi. It had already changed while she was on the phone with us. Whoever took it had it on their own network. We had a connection to it, and we had minutes — not hours.

Assessment

- theft confirmed: device on a different network than the airport WiFi, IP changed mid-call
- data at risk: customer contracts, pricing sheets, CRM credentials cached in Chrome
- BitLocker status: enabled, but the device was in sleep mode — not requiring a boot-time decryption prompt
- RMM agent: online and responsive — we had a channel

Why standard options weren't good enough

Each "standard" option for a stolen laptop has a critical weakness when the attacker is already running:

- wait for Intune wipe — only triggers when the device checks in. Default Intune sync schedule is 8 hours. If the thief disables WiFi, it's never.
- rotate credentials — disabling the user's AD account and revoking CRM tokens is fine, but cached credentials in Chrome still work offline, and local files on disk don't care whether her account is enabled
- trust BitLocker — the device was in sleep mode, not fully powered off. Opening the lid hits a Windows lock screen, not the BitLocker pre-boot prompt. A competent attacker can boot to recovery and work from there.
- RMM direct wipe — the agent is online right now. We can push a command to it in the next 60 seconds. No waiting for an MDM sync cycle that might never come.

Decision was made. We got verbal authorization from the sales director and documented it in the ticket. Time from theft report to authorization: 11 minutes.

Resolution

Windows 10/11 ships with an MDM_RemoteWipe CIM class in the root\cimv2\mdm\dmmap namespace regardless of whether the device is MDM-enrolled. It exposes the same factory-reset mechanism Intune uses — which means you can invoke it locally via PowerShell, and if you can invoke it via PowerShell, you can push it through RMM.

Warning — destructive operation

Irreversible factory reset. All data permanently erased.
  No undo, no confirmation prompt, no recovery.
  Last-resort for confirmed theft scenarios only.

How it works

1. opens a CIM session to the local WMI repository
2. queries root\cimv2\mdm\dmmap for the MDM_RemoteWipe provider
3. invokes doWipeMethod — the same method Intune calls remotely
4. Windows triggers a SYSTEM-level factory reset, bypassing all user permissions
5. device immediately reboots into Windows RE and begins the secure erase

Critical advantage: this doesn't wait for cloud sync. The RMM agent executes it locally with SYSTEM privileges. If the device is online to your RMM, you can wipe in seconds instead of hours.

Outcome

Script executed at 5:03 PM. RMM confirmed the command was received. 47 seconds later the device dropped offline permanently — exactly what we expected as Windows rebooted into recovery mode to begin the wipe. Whoever was in possession of that laptop got a freshly factory-reset device. We confirmed no data was exfiltrated before the wipe started.

- time to wipe: 16 minutes from theft report to execution
- data exposed: 0 records (confirmed, no evidence of exfiltration)
- compliance status: maintained, no breach notification required

Key takeaways

Takeaway

RMM agents give you immediate access when cloud MDM sync cycles are too slow — if you only rely on Intune, a default sync schedule can mean 8+ hours of exposure.

Takeaway

sleep mode does not equal BitLocker protection. The device has to be fully powered off for BitLocker to actually gate access at boot.

Takeaway

have your wipe script tested and documented before you need it. 5 PM on a Friday is not the time to write and QA PowerShell.

Takeaway

document authorization in the ticket before you wipe. Remote wipe is destructive and irreversible — you want a paper trail with an authorized approver on it, not just a verbal "go.".

Need help with something like this? Contact us

• Getting Verification Codes You Didn't Request? How to Tell Spam From Account Compromise (Security)

• Finding Your BitLocker Recovery Key After a Windows Update Breaks Boot (Security)

• BEC Wire Fraud at a Title Company: How We Stopped a High-Six-Figure Loss (Security)