Back to Intelligence

Malicious SIM Cards Can Execute Attacker Code on Cellular IoT Modems — Detection and Hardening Guide

SA
Security Arsenal Team
August 11, 2026
12 min read

Security researchers at the University of Birmingham and firmware security firm Fuzzware have demonstrated something defenders of cellular-connected infrastructure have long feared but rarely tested: a malicious SIM card can instruct the device it sits in to execute commands of the attacker's choosing. On the cellular modules embedded in electric-vehicle chargers, industrial routers, and automotive telematics units, that capability is sufficient to fully compromise the host device.

The team tested 26 phones and cellular modules for the capability and found it broadly present across the ecosystem. This is not a single-vendor CVE with a clean patch path — it is a systemic weakness in how cellular modules handle SIM Application Toolkit (SAT/USAT) proactive commands and how host systems trust the modem. The original reporting is available at The Hacker News.

Why this matters now: cellular IoT deployments have exploded across critical infrastructure — EV charging networks, remote industrial telemetry, fleet management, smart-grid endpoints. These devices are typically unattended, remotely deployed, and managed through the very cellular link this attack abuses. An attacker who can provision or swap a SIM (physical access, compromised MVNO, rogue reseller, or supply-chain insertion) gains a code-execution primitive on hardware your SOC cannot see with traditional EDR.

Technical Analysis

What is affected

  • Cellular modules integrated into EV chargers, industrial routers/gateways, and vehicle telematics control units (TCUs)
  • Consumer phones — 26 devices total were tested across phones and modules, with the capability confirmed present
  • The weakness lives at the intersection of the SIM Application Toolkit (SAT/USAT) proactive command interface and the baseband/host AT-command bridge — not in a single firmware version

How the attack works (defender's view)

The SIM Application Toolkit is a legitimate GSM/3GPP standard that lets a SIM card issue proactive commands to the handset or module — historically used for carrier menus, roaming services, and value-added features. The attack chain:

  1. Delivery: An attacker-controlled SIM is inserted into the target device. This can happen via physical access to an unattended field unit (EV charger, roadside telemetry), a compromised or rogue mobile virtual network operator (MVNO) provisioning SIMs, or supply-chain tampering before deployment.
  2. Proactive command abuse: The malicious SIM issues SAT proactive commands toward the modem. The modem's baseband firmware processes these commands and, on affected modules, bridges attacker-controlled content to the host-facing command interface (the AT-command layer or equivalent IPC).
  3. Host command execution: Because many cellular IoT designs treat the modem as a trusted peripheral, commands arriving from the modem side are executed with the privileges of the modem-management stack — frequently root on embedded Linux gateways.
  4. Full device takeover: On modules in EV chargers, industrial routers, and telematics units, the researchers showed this is enough to take over the entire device — enabling persistence, lateral movement into the management VLAN, firmware manipulation, or disruption of the physical process the device controls.

Exploitation requirements and status

  • Requirements: Attacker-controlled SIM present in the device (physical insertion, rogue provisioning, or supply chain). No host-side authentication or user interaction is needed.
  • Status: Research-demonstrated capability across a broad device set. No CVE identifier has been published in the reporting to date, and there is no confirmed in-the-wild campaign as of this writing — but the primitive is reliable, standard-based, and requires no memory-corruption exploit, which makes weaponization straightforward for motivated actors.
  • Why it evades traditional controls: The attack surface is below the OS. EDR agents on the host see only the effects (a shell spawned by the modem daemon, an unexpected outbound connection over the cellular interface). The baseband itself is a black box to nearly every security stack.

The real-world exposure

Think about your asset inventory: every EV charging pedestal with a cellular fallback link, every industrial router on a remote SCADA segment, every fleet telematics dongle. Most organizations provision these SIMs through third-party aggregators, never rotate them, never physically inspect the devices, and send zero modem telemetry to the SIEM. That is the detection gap this research exposes.

Detection & Response

Because the compromise originates in the baseband, host-side detection focuses on the observable aftermath: modem-management daemons spawning unexpected child processes, abnormal AT-command interface activity, and unexpected outbound connections over cellular interfaces. These are high-fidelity signals on embedded Linux gateways — legitimate modem daemons almost never spawn shells or interpreters.

SIGMA Rules

YAML
---
title: Modem Management Daemon Spawning Shell or Interpreter
id: 9c2e7b41-3d58-4f1a-b6d2-8a4c5e9f1023
status: experimental
description: Detects cellular modem management daemons (ModemManager, quectel-CM, uqmi, mbimcli wrappers) spawning shells or script interpreters on Linux IoT gateways. Consistent with host-side effects of a malicious SIM issuing proactive commands that bridge to host command execution.
references:
  - https://thehackernews.com/2026/08/a-malicious-sim-card-can-run-attacker.html
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/08/15
tags:
  - attack.execution
  - attack.t1059.004
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentImage|endswith:
      - '/ModemManager'
      - '/mmcli'
      - '/quectel-CM'
      - '/uqmi'
      - '/umbim'
      - '/mbimcli'
      - '/atinout'
      - '/chat'
  selection_child:
    Image|endswith:
      - '/sh'
      - '/bash'
      - '/dash'
      - '/ash'
      - '/python'
      - '/python3'
      - '/perl'
      - '/busybox'
      - '/nc'
      - '/ncat'
      - '/wget'
      - '/curl'
  condition: selection_parent and selection_child
falsepositives:
  - Vendor firmware update mechanisms that legitimately invoke scripts via the modem stack (rare — validate against change windows)
level: high
---
title: Direct Access to Cellular Modem AT Command Interfaces
id: 4f1a8c62-7b93-4e05-a291-6d3c8b5f7041
status: experimental
description: Detects unexpected processes opening cellular modem serial interfaces (/dev/ttyUSB*, /dev/cdc-wdm*, /dev/ttyACM*) for raw AT command interaction. On managed IoT gateways only the designated modem daemon should touch these devices; interactive or scripted access may indicate attacker commands bridged from a malicious SIM.
references:
  - https://thehackernews.com/2026/08/a-malicious-sim-card-can-run-attacker.html
  - https://attack.mitre.org/techniques/T1105/
author: Security Arsenal
date: 2026/08/15
tags:
  - attack.discovery
  - attack.command_and_control
logsource:
  category: process_creation
  product: linux
detection:
  selection:
    CommandLine|contains:
      - '/dev/ttyUSB'
      - '/dev/ttyACM'
      - '/dev/cdc-wdm'
      - '/dev/mhi_'
      - 'AT+C'
      - 'AT^'
  filter_known_daemons:
    Image|endswith:
      - '/ModemManager'
      - '/quectel-CM'
      - '/mmcli'
  condition: selection and not filter_known_daemons
falsepositives:
  - Field engineering diagnostics during maintenance windows — correlate with ticketing
level: medium
---
title: Outbound Connection Over Cellular Interface From Non-Modem Process
id: 2b8d5f13-9a47-4c06-b834-1e7f2a6d9058
status: experimental
description: Detects network connections initiated over cellular interfaces (wwan0, ppp0, rmnet*) by processes outside the approved connection-management set on IoT gateways. A compromised module typically phones home over the cellular link it controls.
references:
  - https://thehackernews.com/2026/08/a-malicious-sim-card-can-run-attacker.html
  - https://attack.mitre.org/techniques/T1071/
author: Security Arsenal
date: 2026/08/15
tags:
  - attack.command_and_control
  - attack.t1071
logsource:
  category: network_connection
  product: linux
detection:
  selection:
    SourceInterfaceName|startswith:
      - 'wwan'
      - 'ppp'
      - 'rmnet'
      - 'qmi_'
    Initiated: 'true'
  filter_expected:
    Image|endswith:
      - '/ModemManager'
      - '/pppd'
      - '/NetworkManager'
      - '/connmand'
      - '/openvpn'
      - '/strongswan'
  condition: selection and not filter_expected
falsepositives:
  - Custom telemetry agents explicitly routed over cellular — maintain a per-device allowlist
level: high

KQL — Microsoft Sentinel / Defender Hunt

These queries assume your IoT gateways forward syslog (or CEF from an edge collector) into Sentinel. Even without agents on the devices, edge syslog from the modem stack and any process accounting (auditd) gives you workable visibility.

KQL — Microsoft Sentinel / Defender
// Hunt 1: Modem daemon spawning shells/interpreters (syslog/auditd from IoT gateways)
Syslog
| where TimeGenerated > ago(14d)
| where ProcessName in~ ("ModemManager", "quectel-CM", "uqmi", "umbim", "pppd", "chat")
     or SyslogMessage has_any ("ModemManager", "quectel", "ttyUSB", "cdc-wdm")
| where SyslogMessage has_any ("/bin/sh", "/bin/bash", "busybox", "python", "curl", "wget", "nc ")
| project TimeGenerated, Computer, ProcessName, SyslogMessage, SeverityLevel
| order by TimeGenerated desc;

// Hunt 2: Raw AT command activity or unexpected serial interface access
CommonSecurityLog
| where TimeGenerated > ago(14d)
| where Message has_any ("AT+C", "AT^", "/dev/ttyUSB", "/dev/ttyACM", "/dev/cdc-wdm")
| where DeviceProduct !has "ModemManager"
| summarize EventCount = count(), DistinctHosts = dcount(DeviceHostName)
  by DeviceHostName, Message, bin(TimeGenerated, 1h)
| order by TimeGenerated desc;

// Hunt 3: Outbound sessions over cellular interfaces from Defender-onboarded gateways
DeviceNetworkEvents
| where TimeGenerated > ago(14d)
| where InitiatingProcessFileName !in~ ("ModemManager", "pppd", "NetworkManager", "connmand", "openvpn")
| where RemotePort in (80, 443, 8080, 4444, 53) and ActionType == "ConnectionSuccess"
| join kind=inner (DeviceProcessEvents
    | where TimeGenerated > ago(14d)
    | summarize ParentCmd = any(ProcessCommandLine) by DeviceId, InitiatingProcessId = ProcessId)
  on DeviceId, $left.InitiatingProcessId == $right.InitiatingProcessId
| where ParentCmd has_any ("wwan", "ppp", "ttyUSB", "ModemManager")
| project TimeGenerated, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine,
          RemoteIP, RemoteUrl, RemotePort
| order by TimeGenerated desc

Velociraptor VQL Hunt

For responders doing triage on a suspected compromised gateway (via an offline collection or an edge Velociraptor deployment), this artifact hunts the parent/child anomaly directly:

VQL — Velociraptor
-- Hunt for modem daemons spawning unexpected child processes and
-- inventory recent outbound connections on cellular-equipped Linux gateways
SELECT Pid, Ppid, Name, Exe, CommandLine, Username, CreateTime
FROM pslist()
WHERE Name =~ '(ModemManager|quectel|uqmi|umbim|pppd|chat)'
   OR Exe =~ '(ModemManager|quectel)'

-- Follow-up: enumerate children of any modem-related PID
SELECT c.Pid AS ChildPid,
       c.Name AS ChildName,
       c.CommandLine AS ChildCmdLine,
       p.Name AS ParentName,
       c.Username AS ChildUser,
       c.CreateTime AS ChildStart
FROM pslist() AS c
JOIN pslist() AS p ON c.Ppid = p.Pid
WHERE p.Name =~ '(ModemManager|quectel|uqmi|umbim|pppd|chat)'
  AND c.Name =~ '(sh|bash|ash|dash|python|perl|busybox|nc|curl|wget)'

A note on fidelity: on an embedded gateway, ModemManager or quectel-CM spawning sh is almost never legitimate. If you see it, treat the device as compromised, isolate it from the management network, and pull the SIM for forensic preservation before rebooting anything.

Remediation

There is no single patch — this is an architectural trust problem. Prioritize in this order:

1. Inventory and SIM provenance (immediate)

  • Build a complete inventory of cellular-equipped devices: model, module vendor (Quectel, Telit, Sierra Wireless, u-blox, Fibocom, etc.), firmware version, SIM ICCID, and provisioning source.
  • Verify every SIM's chain of custody. SIMs sourced through third-party resellers or pre-provisioned by integrators should be considered higher risk. Replace untrusted SIMs with ones provisioned directly by your contracted carrier.
  • Enable carrier-side controls: private APNs, IMEI-SIM locking (so the SIM only works in the enrolled device), and SIM-swap alerting where your carrier/MVNO supports it.

2. Physical and provisioning hardening

  • Tamper-evident seals or locked enclosures on SIM slots of unattended field units (EV chargers, roadside cabinets).
  • Physical inspection cadence for critical sites — a swapped SIM is the primary delivery vector.
  • Disable or restrict SIM hot-swap where the enclosure design allows.

3. Host-side hardening script

Run the following audit/hardening baseline on Linux-based cellular gateways. It validates modem interface permissions, restricts who can touch the AT interfaces, and enables auditd watch rules so the Sigma detections above actually fire:

Bash / Shell
#!/bin/bash
# Cellular gateway modem hardening + audit baseline - Security Arsenal
# Run as root on embedded Linux gateways with cellular modules

# 1) Identify cellular serial interfaces
ls -l /dev/ttyUSB* /dev/ttyACM* /dev/cdc-wdm* 2>/dev/null

# 2) Lock down modem device nodes to root only
for dev in /dev/ttyUSB* /dev/ttyACM* /dev/cdc-wdm*; do
  [ -e "$dev" ] && chmod 600 "$dev" && chown root:root "$dev"
done

# 3) Persist via udev rule so permissions survive reboot/hot-plug
cat > /etc/udev/rules.d/99-modem-lockdown.rules <<'EOF'
SUBSYSTEM=="tty", KERNEL=="ttyUSB*", MODE="0600", OWNER="root", GROUP="root"
SUBSYSTEM=="tty", KERNEL=="ttyACM*", MODE="0600", OWNER="root", GROUP="root"
SUBSYSTEM=="usbmisc", KERNEL=="cdc-wdm*", MODE="0600", OWNER="root", GROUP="root"
EOF
udevadm control --reload-rules && udevadm trigger

# 4) Audit watches: alert on any non-daemon open of modem interfaces and
#    on execution of shells/interpreters by the modem stack
if command -v auditctl >/dev/null 2>&1; then
  for dev in /dev/ttyUSB* /dev/ttyACM* /dev/cdc-wdm*; do
    [ -e "$dev" ] && auditctl -w "$dev" -p rwxa -k modem_at_access
  done
  auditctl -a always,exit -F arch=b64 -S execve -F exe=/bin/sh -k modem_shell_exec
  auditctl -a always,exit -F arch=b64 -S execve -F exe=/bin/busybox -k modem_shell_exec
fi

# 5) Verify ModemManager is not running in debug mode (verbose AT logging to syslog
#    is useful, but debug mode has exposed command surfaces on some builds)
ps aux | grep -i [M]odemManager | grep -i debug && echo "WARN: ModemManager debug mode enabled"

# 6) Confirm firewall posture: cellular interface should not accept unsolicited inbound
iptables -L INPUT -n -v | grep -Ei 'wwan|ppp|rmnet' || \
  echo "WARN: no explicit inbound policy on cellular interface - default deny recommended"

# 7) Record module firmware version for vendor advisory tracking
mmcli -m 0 2>/dev/null | grep -Ei 'manufacturer|model|revision' || \
  echo "INFO: query module firmware via vendor AT command (ATI/AT+CGMR) manually"

4. Firmware and vendor engagement

  • Contact your module vendor (or the device OEM) and ask the direct question: does the module filter or restrict SAT proactive commands before they reach the host command processor? Request the firmware roadmap addressing this research.
  • Track the University of Birmingham / Fuzzware disclosure for the full list of the 26 tested devices and any coordinated vendor advisories or CVE assignments that follow.
  • Where firmware fixes land, treat cellular module updates with the same urgency as router CVEs — these modules sit on your management network boundary.

5. Architectural controls (medium term)

  • Segment cellular IoT onto isolated VLANs with no direct path to OT/SCADA or corporate management planes. A compromised charger should be able to reach exactly one broker endpoint and nothing else.
  • Outbound allowlisting at the APN/private-GGSN level: the cellular link should only reach your head-end. This neuters attacker C2 even if the module is fully compromised.
  • Mutual TLS with certificate pinning for device-to-cloud telemetry, so a hostile modem cannot silently redirect management traffic.
  • Push modem-stack syslog and auditd output from gateways to your SIEM — the detections above are worthless without telemetry collection.

6. Incident response readiness

  • Add "suspected malicious/compromised SIM" to your IR playbooks: preserve the SIM (it is evidence), capture baseband logs before reboot, image the gateway, and review carrier provisioning records for unauthorized SIM swaps.
  • If you operate EV charging or industrial telemetry at scale, run a targeted hunt using the Sigma/KQL content above across the last 90 days of retained logs.

Conclusion

This research closes a long-standing blind spot: the SIM card — an artifact most organizations never inventory, never rotate, and acquire through opaque channels — is a code-execution vector against the cellular modules at the edge of critical infrastructure. There is no patch Tuesday for this. The defensive wins come from SIM provenance, physical hardening, network segmentation, and finally treating modem telemetry as first-class SIEM data. Start with the inventory; you cannot defend a cellular fleet you cannot enumerate.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub

Is your security operations ready?

Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.