Een malicious SIM is niet alleen een betaalkaart of identiteitsdrager voor je mobiele verbinding. In sommige cellular IoT-modules kan zo’n kaart het apparaat in de cel-lijn tot commando-uitvoering aanzetten. Onderzoekers van de University of Birmingham en beveiligingsbedrijf Fuzzware onderzochten of moderne telefoons en modems een specifieke SIM-functionaliteit ondersteunen: een interface waarmee een SIM proactief opdrachten naar de modem kan sturen.
Hun conclusie is stevig: in een deel van de geteste apparaten werd die mogelijkheid geactiveerd, waarna de onderzoekers eigen code konden laten draaien. Dat is extra zorgwekkend bij IoT-toepassingen waarin de cellular module en een extra processor in dezelfde hardware-infrastructuur zitten.
Wat is er precies mogelijk met een malicious SIM?
De kern van de kwestie ligt bij een generieke SIM-opdrachtenset richting de modem. In plaats van te wachten tot de modem iets leest, kan een SIM zelf proactieve opdrachten sturen. Onder de aanroep die de onderzoekers onderzochten valt RUN AT: een commando waarmee de modem wordt gevraagd een AT-command uit te voeren.
AT-commands zijn de bekende modem-instructies (afkomstig van systemen rond Hayes Smartmodem) die door vrijwel elke leverancier worden uitgebreid met eigen varianten. Wie die set ondersteunt, geeft een kaart dus in feite toegang tot een soort ingebouwde console voor modemgedrag.
Welke apparaten accepteerden RUN AT?
De onderzoekers testten 26 telefoons en cellular modules op ondersteuning van de interface. Het RUN AT-mechanisme werd ingeschakeld in 9 van de onderzochte cases, en die werden vervolgens benut om eigen code te laten uitvoeren.
Telefoons
Van 18 geteste telefoons accepteerden er slechts 3 de opdracht. Het ging om de OPPO Find X5, OPPO Reno 14 F 5G en de ASUS Zenfone 9. Onderzoekers rapporteerden dat iPhone en Pixel niet in deze groep zaten.
Cellular modules
Bij de modules was het beeld anders. Zes van de acht modules accepteerden de opdracht. Vijf van die zes betroffen Quectel-onderdelen. Daarbij waren modules aanwezig in een EV-oplaadstation, een industriële router en een telematica-eenheid in een auto.
Waarom is de impact op IoT vaak groter?
Een telefoon bevat weliswaar veel softwarelagen, maar de echte risicofactor bij IoT zit in de architectuur. In veel cellular IoT-modules draait niet alleen het radiosysteem: er is ook een kleine applicatieprocessor naast de communicatiehardware. Vaak betreft dat een Linux-omgeving die opdrachten doorgeeft aan de modem.
De onderzoekers beschrijven dit als een “rijke aanvalsurface” omdat een SIM-opdracht niet stopt bij het radio-domein, maar kan doorwerken naar de lokale processor. Daardoor kan een kwaadwillende kaart, afhankelijk van de implementatie, verder gaan dan alleen netwerkinstellingen wijzigen.
Van SIM-opdracht naar code execution: wat vonden de onderzoekers?
Bij één van de casussen, een commerciële EV-lader (Autel, modelcode MAXI US AC W12-L-4G), bleek de module Quectel EC25AFXDGA een mechanisme te hebben waarbij tekst uit de SIM in een shell-aanroep terechtkwam via een onveilige formattering. Een blokkeringsmechanisme zou shell escapes moeten tegenhouden, maar een newline wist die beperking te omzeilen.
In twee opeenvolgende stappen bereikten de onderzoekers code execution. Belangrijk: de uitvoer was volledig gedreven door opdrachten die de SIM uit zichzelf kon sturen.
Wat betekent dit voor een gebruiker of beheerder?
Ook zonder dat je precies weet welke firmware in jouw apparaat zit, is het belangrijk om te begrijpen dat de aanval in veel scenario’s start met een fysieke of logistieke stap: er moet een vijandige SIM in de kaartslot/voorziening zitten. Dat kan gebeuren door een kaart te verwisselen, door een dunne interposer te gebruiken, of door de levering/onderhoudsketen te manipuleren (bijvoorbeeld via een gecompromitteerde operator of productielijn).
De onderzoekers benadrukken dat het niet genoeg is om alleen het telefoonnummer te kennen. Het gaat om de kaart die al in de slot aanwezig is—zeker bij IoT-apparatuur die SIM-trays heeft die toegankelijk zijn en naast de cellular verbinding weinig andere bescherming bieden.
Geen snelle universele patch: wat zegt de verantwoordelijke ecosysteemkant?
Op dit moment is er volgens de onderzoekers geen enkele “one-size-fits-all” patch. De reden is dat het probleem deels gaat over twee niveaus:
- Kwetsbaarheden in de manier waarop modems bepaalde commando’s verwerken (bugfixbaar).
- Het bestaan van RUN AT als ondersteunde interface/functionaliteit (een configuratie-/ontwerpskeuze per vendor).
Onderzoekers geven aan dat het de voorkeur heeft om die interface uit te harden, af te schaffen of helemaal uit te zetten. Een hardended configuratie zou dan standaard worden op toekomstige devices, terwijl bestaande modules via updates moeten worden aangepast.
Wel meldt Qualcomm dat het een hardened configuratie heeft gemaakt die de interface standaard uitschakelt. Quectel zegt kwetsbaarheden in het relevante bestandstoegangspunt te hebben gemitigeerd en is bezig met verdere afhandeling van de interfacekant.
Opvallend genoeg werden er tot en met de onderzoeksperiode nog geen publieke adviezen beschikbaar gesteld door alle betrokken partijen. Sommige portalen zijn bovendien afgeschermd met login om details te bekijken.
Voorbeelden uit de cases: AT-commands met vergaande gevolgen
Op een OPPO Reno 14 F 5G die RUN AT accepteerde, werd een commando gebruikt dat de telefoon vastzette op 2G. Volgens de onderzoekers konden eigenaren dit niet ongedaan maken via gangbare acties zoals airplane mode, netwerkselectie, of het aanpassen van de voorkeursnetwerkgeneratie. De reden ligt in het ontbreken van mutual authentication bij 2G, waardoor een downgrade geen eenvoudige reverse route biedt.
Daarnaast werden extra commando’s gebruikt om het toestel uit te schakelen en de modem te stoppen. Met de tooling die de onderzoekers uitbrachten (CATana) konden ze voor deze handset bovendien veel bereikbare AT-commands identificeren.
In een derde case konden de onderzoekers willekeurige bestanden laten uitlezen via een TFTP-daemon die als root draait, zonder controle op symbolische links. Daarna stuurden ze de data via modem-AT-commando’s. Die variant vereist wel dat er al een kwaadaardige link op het systeem staat, bijvoorbeeld via een SD-card of een aangepaste/gevlochten flash-partitie.
Ook eerder was er AT-gerelateerde code injection
Het onderzoek plaatst dit probleem in lijn met eerdere vondsten: dezelfde daemon had al eerder een AT-reachable command injection op een andere invoerroute. Daarmee wordt duidelijk dat dit type aanval niet volledig “nieuw” is, maar dat de toegang via een SIM-interface nu juist extra exposure geeft bij cellular IoT.
Los daarvan is er in het verleden ook een andere SIM-gerelateerde zwakte beschreven die kon leiden tot het openen van een aanvallerspagina zonder gebruikersinteractie op bepaalde Pixel-toestellen en andere apparaten. Die werd later gepatcht als onderdeel van een Android bulletin. Het huidige onderzoek gaat echter specifiek over het SIM-naar-modem RUN AT pad.
Wat kun je vandaag doen als je een fleet beheert?
Omdat niet alle kwetsbaarheden en interfacekeuzes via één uniforme fix zijn op te lossen, ligt de eerste stap vooral bij beheer en vendorcontrole. De onderzoekers raden beheerders aan om gericht te vragen:
- Wordt RUN AT ingeschakeld in de geleverde firmware van jouw modemmodule?
- Kan die interface worden uitgeschakeld of gedegradeerd naar een veilige modus?
- Welke updates komen beschikbaar voor de onderliggende foutafhandeling (command verwerking, bestandsverwerking, enz.)?
Daarnaast is het verstandig om je beveiligingsmaatregelen rond SIM-trays en fysieke toegang te herzien: onbeheerde IoT-apparatuur met een gemakkelijk toegankelijke SIM-lade blijft een logische plek voor een malicious SIM om binnen te komen.
Als je al nadenkt over AI-gedreven of geautomatiseerde aanvallen in beheeromgevingen, kan het ook nuttig zijn om je bredere “attack surface” benadering te koppelen aan hardening van interfaces. Zie bijvoorbeeld hoe onderzoekers naar model- en omgevingstoegang kijken in de context van herhaalde compromittering via ongewenste code.
Supply chain relevant: modulemakers bepalen mede het risico
Een belangrijk punt uit het onderzoek is de supply chain. De kwetsbare code bleek niet in de eindproducten zelf te zitten, maar in de module. Quectel gaf aan dat de relevante command injection in nieuwere firmware is verholpen, terwijl moduleleveranciers en platformkant het verschil maken tussen “kan een SIM dit doen?” en “is het daadwerkelijk misbruikbaar in de praktijk?”.
Dat maakt dit onderwerp direct relevant voor organisaties die cellular IoT-apparaten leveren of beheren: je moet niet alleen naar de applicatie kijken, maar ook naar de modemmodules, hun configuratie en de updatepolitiek van de leveranciers.
Conclusie
Een malicious SIM kan in bepaalde cellular modemmodules commando’s laten uitvoeren via de RUN AT-interface. Onderzoekers vonden in negen geteste gevallen dat die mogelijkheid leidde tot aantoonbare code execution, met extra impact wanneer IoT-hardware een tweede applicatieprocessor naast de radio integreert.
Er is geen simpele universele patch. Het komt neer op hardening of uitschakelen van de interface waar mogelijk, plus updates voor de onderliggende bugs. Voor beheerders en fleet-owners betekent dit vooral: vraag naar firmware-configuraties (staat RUN AT aan?) en zorg dat fysieke en operationele toegang tot SIM-laden zo veel mogelijk wordt beperkt.
Bron: https://thehackernews.com/2026/08/a-malicious-sim-card-can-run-attacker.html
