Rogue SIM Cards Execute Attacker Code on Industrial Modems

The SIM slot in a cellular module is not passive storage for a subscriber identity. Under the SIM Application Toolkit (STK) specification — part of the GSM standard since 1996 — the card can issue proactive commands that instruct the host device to take action: display text, send an SMS, launch a session. On a smartphone, decades of baseband firmware iteration have narrowed what those commands can actually reach. On the cellular modules embedded in EV charging stations, industrial routers, and car telematics units, that narrowing largely did not happen.

Researchers at the University of Birmingham and security firm Fuzzware tested 26 phones and cellular modules, found the capability in the cellular module population, and demonstrated that a malicious SIM in such a device could order it to execute commands of the attacker’s choosing. On a module controlling an EV charger or sitting inside an industrial router managing remote-site connectivity, that is enough to take the whole device over.

The Mechanism

STK commands travel over the ISO 7816 interface between SIM and modem. The modem firmware decides which commands it will honor. Smartphone basebands implement that decision under pressure from a decade of research: SIMjacker in 2019, WIBattack shortly after, subsequent rounds of coordinated disclosure that pushed handset vendors to tighten the gate. The result is an imperfect but substantively hardened posture.

Machine-to-machine cellular modules — the cat-M, NB-IoT, and LTE-M chipsets used in industrial and automotive applications — did not participate in that cycle. They expose an AT command interface, often directly to the host system over serial or USB, and the SIM is assumed to be the one placed there by the operator. The Birmingham/Fuzzware team found that on devices of this class, STK-initiated commands could reach execution paths that a current-generation smartphone baseband would reject.

The practical consequence: a malicious SIM physically inserted into a target module can run arbitrary commands on the host device. No vulnerability in the device’s application firmware is required. The attack surface is the cellular interface itself.

What Gets Deployed Here

The device classes where this matters are the ones where cellular is the management path: EV charging stations at parking facilities and highway corridors, industrial LTE routers used for SCADA and remote monitoring, fleet telematics units in commercial vehicles. These are not high-turnover consumer devices. A cellular module in a roadside industrial router may run for five years with no physical inspection. The same module likely uses a managed SIM from a mobile virtual network operator or a corporate M2M account.

That last point extends the attack surface past the physical slot. Remote SIM provisioning — the OTA mechanism that M2M deployments use to update SIM credentials and applets without touching the device — means the SIM applet layer is reachable from the SIM management backend. A compromise of that backend could push malicious toolkit applets to an entire fleet without a single physical visit.

What to Check

The practical set is specific:

• Determine whether your deployed modules honor STK commands from the SIM. Modem AT documentation for cat-M and NB-IoT modules typically describes STKD and STGR command handling, or equivalent vendor-specific commands. Read it. If the documentation is silent on STK filtering, contact the module vendor directly.
• Audit remote SIM provisioning access. M2M SIM management platforms grant write access to applet provisioning. Know who has that access, confirm audit logging is in place, and verify the platform’s own authentication posture.
• Apply cellular module firmware updates. Not all vendors have addressed this class of issue; check your module’s security bulletin page and apply any updates that reference STK or SIM command handling.
• Prefer modules with explicit STK command filtering in the datasheet. For new deployments, this is a procurement question, not a retrofit problem.

The University of Birmingham and Fuzzware research is detailed in The Hacker News’s coverage; the full paper is expected to follow.