Twilio-ontwikkelaars lijken in de afgelopen periode doelwit te zijn geweest van een malicious npm-pakket dat zich voordeed als een (legitieme) security test. Het ging om de package tw-pkgprobe-7731, die volgens onderzoekers eerst werd gepresenteerd als een bug-bounty probe, maar ondertussen gevoelige omgevingsinformatie probeerde te verzamelen en door te sturen.
Wat dit extra zorgwekkend maakt: de code richtte zich op ontwikkelomgevingen die Twilio integreren en probeerde, afhankelijk van de versie, gericht naar data te zoeken die aan Twilio gekoppeld is. Daarmee is het een typisch voorbeeld van risico’s binnen de software supply chain: niet de applicatie zelf, maar een afhankelijkheid in je build of runtime kan een aanvalsmiddel zijn.
Wat was tw-pkgprobe-7731 en hoe werd het vermomd?
Volgens ReversingLabs verscheen tw-pkgprobe-7731 rond half augustus 2026 op de npm-registry. In een relatief korte periode werden meerdere versies gelijktijdig en snel na elkaar gepubliceerd. De npm-gebruiker achter het pakket bestaat inmiddels niet meer.
In de code en comments werd het pakket omschreven als een “authorized bug-bounty research probe” binnen het Twilio HackerOne-programma. Er stond ook bij dat het alleen binnen een serverless “packager sandbox” zou draaien en dat het geen destructieve acties zou uitvoeren.
Dat soort framing is precies het soort context dat developers kan geruststellen. Maar die geruststelling bleek niet gerechtvaardigd, zo blijkt uit de technische analyse.
Hoe werkte het pakket in de praktijk?
Bij uitvoering startte het pakket met een controle: het keek of de omgeving overeenkomt met een Twilio developer context. Vond het die context niet, dan stopte het meteen. Die eerste “gate” maakt het pakket minder zichtbaar buiten het beoogde scenario.
Als de check wél positief was, ging het verder met het ophalen van informatie. Het verzamelde onder meer environment variables en systeemdetails zoals mounts, tijdelijke mappen en diverse configuratiegegevens. Vervolgens werd de verzamelde data doorgestuurd via een webhook, waarmee exfiltratie op een redelijk eenvoudige manier kon plaatsvinden.
Gerichte zoektocht naar Twilio-gerelateerde omgeving
Latere versies richtten zich specifieker op ontwikkelaars die Twilio-API’s gebruiken. Daarbij werd gezocht naar mapstructuren die samenhangen met Twilio account String Identifiers (SIDs). Opmerkelijk is dat het pakket één scenario juist leek te vermijden: als er al een map bestond met een specifieke SID-naam, werd verdergaan met die aanvalsketen niet op dezelfde manier voortgezet.
Wanneer die doelmappen wél werden gevonden, scande de code geïnstalleerde npm-pakketten en de node_modules-omgeving. Daarna werd een eigen, aangepaste npm PoC-component geïntroduceerd, door onder andere een package.json en index.js toe te voegen.
Twilio-credentials en mogelijk effect op billing
In versie 1.0.4 werd volgens de onderzoekers een extra exfiltratie-mogelijkheid toegevoegd. Daarbij werd informatie bedoeld als process.env.ACCOUNT_SID en process.env.AUTH_TOKEN—dus omgevingsvariabelen die de integratie met Twilio vaak van sleutels en tokens voorzien.
Als een aanvaller inderdaad deze waarden vergaart, kan dat meer zijn dan alleen informatielekken. In het rapport wordt gesuggereerd dat een aanvaller zich mogelijk kan autoriseren voor acties richting Twilio. In de praktijk zou dat kunnen betekenen dat er communicatie gestart wordt of dat er billing-activiteiten getriggerd worden, afhankelijk van hoe de token en SID worden gebruikt binnen de applicatie.
Daarmee raakt dit incident direct aan een belangrijk supply chain-beveiligingspunt: een aanvallende afhankelijkheid kan precies die waarden uit je runtime-omgeving trekken waarvoor je normaal gesproken juist tokens vertrouwt.
Versiegedrag: van kwaadwillend naar “terug naar probe”
Een opvallend onderdeel van de bevindingen is dat de malicious npm-pakket niet consistent kwaadaardig bleef. De laatste versies—genoemd als 1.0.8, 1.1.0 en 1.1.1—zouden teruggeschakeld zijn naar het “basis probing profile” uit een eerdere versie (1.0.0), waarbij de extra kwaadaardige functionaliteit uit eerdere iteraties werd weggelaten.
Ook dat is ongebruikelijk genoeg om vragen op te roepen. Onderzoekers geven aan dat het onduidelijk is wat het uiteindelijke doel was en of publicatie mogelijk gekoppeld was aan bug bounty activiteiten. Tegelijkertijd wijst het analyseverslag erop dat de uitgevoerde acties niet in lijn waren met de richtlijnen voor bug hunting die Twilio publiceert.
Met andere woorden: zelfs als sommige versies “onschuldiger” lijken, blijft het totaalbeeld in strijd met een legitieme security review.
OSINT-achtige activiteit en “cloud metadata” opvragen
Naast het verzamelen van omgevingsdata zagen onderzoekers in de latere versies OSINT-achtige handelingen. Daarbij werden verschillende Twilio-gedreven hosts benaderd, zoals support-api en andere aan Twilio gelinkte domeinen. Ook werd op AWS metadata-informatie geprobeerd op een bekend intern adres, te herkennen aan de route naar “latest/meta-data”.
Het opvragen van cloud metadata kan helpen om extra context te vergaren over de omgeving waarin je draait. Daarmee kan het incident uitgroeien tot meer dan één datalek: het pakket kan inzicht geven in infrastructuurdetails die later bruikbaar zijn voor verdere aanvallen.
Waarom dit pakket zo lastig te herkennen was
Volgens ReversingLabs was er nauwelijks sprake van klassieke “verstoptrucs”. Er werd niet gewerkt met typografische trucjes om de npm-account of pakketnaam legitiem te laten lijken. Ook was er geen evidente obfuscation om de code te verhullen.
Dat heeft twee kanten. Enerzijds is het positief dat de code inhoudelijk relatief direct te analyseren was. Anderzijds zegt het dat de aanval waarschijnlijk uitging van minder geavanceerde dreigingstechnieken—maar wel met een focus op overtuigende framing en context (zoals “bug-bounty probe”) die voor ontwikkelaars wél misleidend kan zijn.
Wat kun je nu doen als je Twilio integreert?
Als je Twilio gebruikt in je applicaties, is het slim om je afhankelijkheden en runtime-omgeving te controleren. Begin met het inventariseren van gebruikte npm-packages, inclusief scripts die tijdens build of deploy draaien. Let daarbij extra op op pakketten die “probe”, “security” of “research” in de naam dragen, maar niet passen bij je vaste dependency strategie.
Verder helpt het om tokens en secrets zo beperkt mogelijk te houden: werk met minimale rechten, korte levensduur voor tokens en duidelijke scheiding tussen ontwikkel- en productie-omgevingen. Als een afhankelijkheid dan wél toegang krijgt tot omgevingsvariabelen, is de impact kleiner.
Tot slot: stel logging en monitoring in rond outbound verkeer (zoals webhook-aanroepen) en ongebruikelijke exfiltratiepatronen. Daarmee kun je afwijkingen eerder zien, ook als een pakket “legaal” of “veilig” klinkt in naam of beschrijving.
Wil je meer lezen over hoe dit soort supply chain-issues zich in de praktijk uiten? Zie bijvoorbeeld ook onze artikelen over compromisrisico’s rond dependency-gedreven aanvallen, zoals malafide npm-pakket met runtime-manipulatie.
Conclusie
De analyse van tw-pkgprobe-7731 laat zien hoe een malicious npm-pakket zich kan vermommen als een Twilio security probe en toch waardevolle informatie kan verzamelen. Door omgevingsvariabelen op te halen en in sommige versies potentieel Twilio-credentials te exfiltreren via webhook-verkeer, vormt dit een reëel risico voor ontwikkelaars die afhankelijk zijn van externe npm-pakketten.
Zelfs wanneer latere versies terugschakelen en minder “agressief” lijken, is de eerdere gedragsspanning een waarschuwing: ga niet af op framing alleen. Neem dependency checks, secret-hygiëne en monitoring serieus, zodat je supply chain niet het zwakke punt wordt.
Bron: https://thehackernews.com/2026/09/malicious-npm-package-poses-as-twilio.html
