AI helpt malware, maar het verhaal achter die ontwikkeling is genuanceerder dan vaak wordt gedacht. Onderzoekers van Unit 42 van Palo Alto Networks analyseerden 405 malware-samples die op de één of andere manier met AI te maken hadden. Denk aan ransomware waarbij LLM’s mogelijk een rol speelden, maar ook aan installateurs die simpelweg de naam van een bekende AI-app gebruiken als lokmiddel.
De kernbevinding: het overgrote deel van de samples belandde niet buiten een veilige onderzoeksomgeving. Pas als een sample daadwerkelijk in de echte wereld draaide, leidde dat consequent tot beveiligingsmeldingen.
Bijna alles blijft in sandboxen en testen
Unit 42 vergeleek de bestands-hashes van de 405 samples met verschillende bronnen: endpoint-telemetrie, netwerkverkeer dat naar de sandbox werd doorgestuurd en interne alerts die ontstaan wanneer een sample écht draait. Daarbij viel een groot verschil op tussen “bekend bij onderzoekers” en “actief op systemen”.
Ongeveer 97% van de onderzochte samples bereikte volgens de onderzoekers nooit een echte target. Ze bleven beperkt tot een sandbox, een researchrepository of interne testomgevingen. Slechts 12 hashes kwamen voor op live endpoints. In het netwerkverkeer dat voor sandboxanalyse werd doorgestuurd lag dat aantal iets hoger: 15 tot 20 hashes dook daar op.
Opmerkelijk genoeg triggerde elk van de 12 samples die daadwerkelijk door het systeem op een beschermd endpoint werden gedetecteerd, een security alert.
Drie groepen achter AI-gerelateerde samples
De samples die niet in productie terechtkwamen, vielen volgens Unit 42 in drie duidelijke categorieën. Dat is relevant, omdat het laat zien dat “AI in de malware” niet automatisch betekent dat er grootschalige, wijdverbreide aanvallen plaatsvinden.
1) Proof-of-concept code voor technieken
De grootste groep bestond uit proof-of-concept (PoC) code. Deze samples zijn gemaakt om een techniek te demonstreren, met beperkingen die niet passen bij echte aanvallen. Ze waren bijvoorbeeld gericht op alleen lokale of privé-netwerken en bevatten debugoutput die een echte aanvaller doorgaans liever niet achterlaat. Bovendien werden ze slechts één keer geüpload door een researchlab of universiteit.
2) Testmateriaal voor defensie-evaluaties
Een tweede groep kwam van organisaties die hun eigen detectie- en verdedigingsmechanismen testten. Dat herken je doordat dezelfde bestanden in een korte tijd herhaaldelijk opnieuw werden geüpload vanuit dezelfde bron. Het zijn dus niet per se “in the wild” actieve dreigingen, maar evaluatiecases.
3) AI-branding als lokmiddel
De derde groep gebruikte AI-merken vooral als lokker. Daarbij verkleedden aanvallers een “gewoon” payload als installateurs voor bekende AI-producten, zonder dat er daadwerkelijk AI-functionaliteit achter zat. Het gaat dan om reputatie- of herkenningswaarde: slachtoffers kunnen sneller geneigd zijn om op een plausibel ogende installer te klikken.
De 12 live-detecties: verspreid, niet geconcentreerd
De twaalf samples die wél live endpoints bereikten, omvatten vijf verschillende malwarefamilies. Unit 42 zag die families verdeeld over drie landen en zonder duidelijke concentratie in één sector of regio. Dat wijst erop dat het fenomeen niet beperkt lijkt tot één specifieke “hotspot”, maar eerder voortkomt uit hoe malware op dit moment wordt samengesteld en aangeboden.
Belangrijk: Unit 42 beschrijft dat bestaande verdedigingsmechanismen deze AI-gerelateerde samples detecteerden met dezelfde technieken die ook bij klassieke malware worden ingezet.
FunkSec: ransomware waar LLM’s mogelijk een versneller waren
De meest voorkomende familie in de dataset was FunkSec, een ransomwarevariant. Meerdere onderzoekers linken deze strain aan mogelijke LLM-assistentie. Opvallend detail uit de analyse zijn projectbestandsnamen die in de onderzochte samples waren ingebed. Unit 42 stelt dat ontwikkelaars lijken te hebben “geswitcht” tussen verschillende namen voor dezelfde ransomware, in een tempo dat meer past bij prompt-gedreven generatie dan bij een traditioneel ontwikkelritme.
Daarmee wordt duidelijk waar “AI helpt malware” vooral op neerkomt: niet per se op nieuwe, ondetecteerbare technieken, maar op het sneller variëren en samenstellen van onderdelen.
Recipe Lister: installer met backdoor en digitale handtekening
Van alle samples die het meest opdoken, was er één die zichzelf presenteerde als een “recipe-finding app” met de naam Recipe Lister. Het bestand werd geleverd als installateur en droeg een digitale handtekening. Na installatie startte het stiekem een backdoor.
Volgens Unit 42 is het sample meer dan 50 organisaties gepasseerd. Dat leverde naar schatting ongeveer 6.500 endpointrecords op en rond 9.600 alerts. Hoewel de handtekening eerst minder verdacht leek, hielpen andere signalen uiteindelijk bij detectie: de combinatie van een opvallende signer en zwaar gepakte of versleutelde inhoud maakte het minder geloofwaardig en makkelijker herkenbaar.
Oyster backdoor: vermomd als Dropbox-installer
Een andere familie die in de analyse genoemd wordt is een Oyster-backdoor. Ook hier speelt branding als tactiek: het sample gedroeg zich alsof het een Dropbox-installer was en de digitale handtekening vermeldde Dropbox als uitgever.
Unit 42 merkt daarbij op dat aanvallers steeds vaker gebruikmaken van AI-tools om dit soort delivery-code sneller en goedkoper tot stand te brengen. Het gaat dan vooral om snelheid in het “startpunt” van de aanval: het moment waarop een malafide payload bij een slachtoffer terechtkomt.
Rhadamanthys en de rol van command-and-control
Naast ransomware en backdoors vond Unit 42 ook een Windows executable die werd geassocieerd met de Rhadamanthys information stealer. Dit sample zette actief command-and-control communicatie op. Eerdere berichtgeving koppelde dit aan een infectieketen waarbij AI-hulp een rol kon spelen.
Wat hier opvalt, is opnieuw niet dat detectie onmogelijk zou zijn, maar dat de effectiviteit vooral samenhangt met traditionele “volgorde van aanvalsstappen”: een payload die draait, communicatie die op gang komt en gedetailleerde signalen die in beveiligingssystemen zichtbaar worden.
360 Total Security-imitatie en COM hijacking
Ten slotte zat in de dataset een sample dat een onderdeel van de Chinese security software 360 Total Security imiteerde. Unit 42 noemt hierbij een persistentietechniek: COM hijacking. Ook dit sample werd niet per se als “AI-afhankelijk” gezien, maar het kwam wel in campagnes voor samen met AI-achtige lokmiddelen. Daarom is het meegenomen in de set die Unit 42 onderzoekt.
Waarom bestaande verdediging het haalt
Een belangrijke conclusie van Unit 42: bestaande beveiliging werkt voor deze AI-gerelateerde samples op dezelfde manier als voor traditionele malware. Dat betekent niet dat AI geen invloed heeft, maar wel dat de dreiging tot nu toe vooral draait om versnelling en variatie in ontwikkeling en vermomming.
De onderzoekers noemen onder andere:
- Sandbox-detonation: het sample wordt geanalyseerd door het in een gecontroleerde omgeving te laten draaien.
- Detectie op basis van gedrag: systemen letten op acties en patronen die passen bij malware.
- Afwijkingen in digitale handtekeningen: onregelmatigheden in uitgever, signer of onderliggende kenmerken vallen op.
- Metingen van packing of encryptie: zwaar ingepakte bestanden worden minder vaak “legitiem” bevonden.
In de onderzochte dataset vereiste geen van de AI-gerelateerde samples volgens Unit 42 een compleet nieuwe detectiemethode. Met andere woorden: “AI helpt malware” hoeft niet automatisch te betekenen “AI kan niet worden geblokkeerd”.
Wat dit betekent voor organisaties
Voor beveiligingsteams is dit vooral een signaal om niet in paniek te raken, maar ook niet te onderschatten. Als AI met name snelheid en variatie toevoegt, dan kun je verwachten dat aanvallen zich aanpassen in tempo, vooral in hoe lokinstallateurs eruitzien of hoe payloads worden verpakt.
Tegelijk laat de dataset zien dat goede basisverdediging — sandboxing, endpointtelemetrie en alerting die gedrag en anomalieën bewaakt — doorgaans wél degelijk werkt. Het is dus geen kwestie van “nieuwe wonderdetectie”, maar van consistente uitvoering van wat al werkt en het scherp monitoren van signalen die wijzen op misleiding.
Wil je breder kijken naar AI-gerelateerde bewijs- en beveiligingsstandaarden, dan past ook dit onderwerp bij de discussie over betrouwbare AI-runtime: TRACE voor AI-runtime attestation: bewijs standaardiseren.
Conclusie: AI als ontwikkelversneller, niet als ondetecteerbare magie
Unit 42’s analyse van 405 AI-gerelateerde malware samples laat een helder beeld zien: vrijwel alles bleef steken in sandboxen of testomgevingen. Slechts een klein deel bereikte live endpoints en elk gedetecteerd voorbeeld leidde tot een security alert.
De dreiging zit volgens de onderzoekers vooral in de rol van AI als versneller van ontwikkeling, variatie en delivery-achtige componenten. AI maakt malware niet automatisch “onvindbaar”; bestaande detectiemethoden blijken in deze dataset voldoende om samples met dezelfde aanpak te blokkeren. Voor organisaties betekent dat: blijf het fundament goed inrichten, verfijn signalen rond digitale handtekeningen en packing-gedrag, en behandel AI-branding als een serieus onderdeel van de dreigingsketen.
Bron: https://www.securityweek.com/ai-speeds-up-malware-development-not-its-success-rate-analysis/
