JavaScript-obfuscatie verwijst naar het omzetten van normale, voor mensen leesbare JavaScript-code naar een vorm die opzettelijk moeilijk te lezen en te begrijpen is. Obfuscatie wordt over het algemeen gebruikt om de bedoelde betekenis van de code te verbergen - en maakt het daardoor uiterst moeilijk om de functies van de code te volgen of te reverse-engineeren. Anders dan bij versleuteling van code vereist het obfusceren van code geen algoritme of privésleutel om uit te voeren. De logica en functionaliteit van de code blijven precies hetzelfde, maar de code staat vol vage en ondoorzichtige functienamen, vreemde programmatische structuren en gecodeerde strings.
Ontwikkelaars gebruiken soms tools zoals JavaScript-obfuscators om hun code en intellectueel eigendom te beschermen en te voorkomen dat het wordt gestolen. Maar vanuit een beveiligingsperspectief, met name in de context van scripts van derden, is geobfusceerde code een enorme rode vlag. Aanvallers gebruiken deze obfuscatie vaak om hun kwaadaardige code te verbergen - van malware en datadiefstal-logica tot exploitcode - in wat eruitziet als een willekeurige wirwar van tekst. Dit alleen al kan eenvoudige beveiligingsscanners omzeilen en handmatige analyse van scripts aanzienlijk bemoeilijken.
Waarom is het deobfusceren van JavaScript belangrijk voor beveiliging?
Als het gaat om webbeveiliging is payload-zichtbaarheid - het vermogen om de code die op je site draait te zien en te inspecteren - absoluut cruciaal. Het deobfusceren van JavaScript (het omgekeerde of decoderen van de code) geeft een beveiligingsanalist een helder beeld van het script en wat het onder de motorkap doet. Als je door deze obfuscatie heen niet kunt kijken, ben je in feite blind voor wat die code mogelijk doet.
Alleen vertrouwen op oppervlakkige beveiligingsmaatregelen is niet voldoende om je site te beschermen. Content Security Policy-headers kunnen bijvoorbeeld beperken van welke locaties scripts mogen worden geladen, maar bieden geen zichtbaarheid in de payload van de scripts zelf. Als een externe host wordt gecompromitteerd en begint met het serveren van geobfusceerde malware - zoals we in 2024 rapporteerden bij de Polyfill-aanval - zal een CSP je niet vertellen dat de inhoud van het script kwaadaardig is. Omdat het afkomstig is van een goedgekeurde bron, wordt het vertrouwd en wordt de mogelijk kwaadaardige inhoud niet gemarkeerd.
Een andere reden waarom payload-zichtbaarheid cruciaal is, heeft te maken met de dynamische aard van de meeste client-side aanvallen. Zoals besproken in ons Q2-rapport over client-side aanvallen, ziet cside steeds meer aanvallen die geobfusceerde code in sites injecteren die vaak terugkoppelt naar een command-and-control-server voor verdere instructies. Dit kan een site blootstellen aan bedreigingen zoals kwaadaardige advertenties en omleidingen, cryptojacking-scripts en browser-exploitkits, allemaal dynamisch aangestuurd door een derde partij.
Welke veelvoorkomende JavaScript-rode vlaggen moet je in de gaten houden?
Onleesbare of verminkte code
Een van de grootste rode vlaggen om op te letten is wanneer de code van een script een zinloze wirwar is van tekens, lange numerieke arrays en vreemde functies die in niets lijken op voor mensen leesbare code. Aanvallers verbergen strings vaak door ze te coderen met hexadecimaal, Base64 en Unicode-escapes, en ze op te splitsen in onleesbare stukken. Dergelijke variabelen zien eruit als _0x5e of aa1122bbcc en hebben zelden betekenisvolle namen. Legitieme bibliotheken kunnen code minificeren die hierop lijkt, maar ze zijn doorgaans niet diep geobfusceerd met rommeldata.
Gecodeerde/rommeldata in strings
Kwaadaardige scripts verbergen kritieke strings (zoals URL's, trefwoorden, JavaScript-payloads) vaak door ze te coderen en rommeldata erin te verwerken. Ze kunnen bijvoorbeeld een URL obfusceren via hexadecimale codering en er meerdere constante rommelsubstrings doorheen strooien om decodering te dwarsbomen. Functies zoals atob(), unescape() en aangepaste routines die strings transformeren, zijn vaak duidelijke indicatoren dat het script iets probeert te verbergen. In het verleden was het bekend dat aanvallers willekeurige tekst invoegden of meerdere coderinglagen gebruikten om variabelen zoals eval en document.cookie te verbergen.
Dynamische functiegeneratie (eval en verwanten)
Een andere rode vlag in een script is het gebruik van functies zoals eval(), de Function()-constructor of setTimeout() en setInterval(). Dit betekent vaak dat het script code construeert tijdens runtime, wat een favoriete techniek van malware kan zijn om de echte payload uit te pakken. Moderne, legitieme scripts gebruiken eval() zelden vanwege de beveiligings- en prestatiegevolgen, dus de aanwezigheid ervan in een script van een derde partij zou argwaan moeten wekken. Op vergelijkbare wijze is het dynamisch aanmaken van DOM-scriptelementen via document.createElement('script') een andere manier om kwaadaardige code te injecteren. Als je code ziet die een <script>-tag opbouwt met een verdachte externe URL, is dat een groot waarschuwingssignaal dat je site mogelijk gecompromitteerd is.
Verdachte externe verbindingen
Elk script van een derde partij dat verwijst naar externe domeinen of IP-adressen die niets te maken hebben met de functie van de site, is een veelzeggend teken van kwaadaardig gedrag. Als een geobfusceerd script bijvoorbeeld plotseling een fetch()- of XHR-verzoek doet naar een domein dat niets met de site te maken heeft, is dit vaak een indicator van kwaadaardig gedrag. Aanvallers gebruiken vaak hun eigen servers voor exfiltratie of controlepunten, en elke verschijning van deze domeinen in code van derden is een rode vlag.
HTML- en DOM-manipulatietrucs
Geobfusceerde kwaadaardige JavaScript manipuleert de pagina vaak op heimelijke manieren. Dit is vaak te zien aan het aanmaken van onzichtbare of overlay-elementen, het instellen van extreem hoge z-index-waarden (om de pagina te bedekken met een frauduleuze invoer of prompt) en het injecteren van formulieren en event listeners. cside rapporteerde onlangs over een aanval op CoinMarketCap waarbij een kwaadaardige pop-up met een hoge z-index-waarde werd gebruikt om gebruikers te verleiden hun wallets te koppelen aan een kwaadaardige derde partij, waardoor hun wallets van alle cryptocurrency werden leeggehaald.
Polymorfe obfuscatie bij JavaScript-aanvallen
Een van de meer geavanceerde en ontwijkende technieken die aanvallers kunnen gebruiken om de ware bedoeling van hun script te verbergen, is polymorfe obfuscatie. Polymorfe obfuscatie is code die elke keer dat de payload wordt afgeleverd van structuur verandert, ook al blijft het onderliggende gedrag hetzelfde. Deze techniek is overgenomen uit traditionele malware-ontwikkeling, waarbij polymorfe binaries hun uiterlijk muteren om antivirusdetectie te omzeilen. In het browsergebaseerde JavaScript-ecosysteem bereiken aanvallers vergelijkbare ontwijking door variabelenamen te rouleren, functies te herstructureren, de controlestroom te wijzigen en willekeurige rommelcode door het script te verspreiden.
Dit betekent dat twee payloads met dezelfde bedoeling - zoals het afskimmen van een afrekenformulier op een website - er op codeniveau volledig anders uit kunnen zien. Dit maakt detectiemethoden zoals hash-gebaseerde handtekeningen en statische IOC-gebaseerde filters ontoereikend, en maakt het in het algemeen ongelooflijk moeilijk om je ertegen te beschermen. Omdat de code dynamisch en veranderlijk is, kunnen perimeterverdedigingen zoals Content Security Policy (CSP) en Subresource Integrity (SRI) niet voldoende bescherming bieden tegen polymorfe aanvallen. Deze beveiligingen kunnen valideren waar het script vandaan komt en of het is gewijzigd, maar bieden geen inzicht in wat het script daadwerkelijk doet tijdens runtime.
Welke tools en technologieën deobfusceren JavaScript?
Deobfuscatie is in wezen een reverse-engineering-oefening om gecodeerde strings en functies om te zetten naar iets dat voor mensen leesbaar is. Het vereist vaak een combinatie van de onderstaande technieken om een script volledig te deobfusceren:
- Code-beautifiers of -formatters: Tools zoals JSBeautify, deobfuscate.io, JSnice en de4js kunnen een gepakt of geminificeerd script nemen en de code opnieuw indenteren met regelafbrekingen, waardoor het een correct gestructureerd stuk code wordt. Dit verwijdert de obfuscatie vaak niet, maar maakt de opmaak van de code leesbaarder.
- String-decoderingshulpmiddelen: Omdat geobfusceerde code gegevens vaak codeert met hex, Base64, enzovoort, kunnen eenvoudige decoderingshulpmiddelen de oorspronkelijke strings herstellen. Veel beveiligingsanalisten gebruiken Python-scripts of sites zoals Dencode.com om veelgebruikte formaten te decoderen.
- Handmatige refactoring en vervanging: Soms is de eenvoudigste manier de meest handmatige manier - na het gebruik van een code-beautifier, het doorlezen van de code en het statisch vervangen van geobfusceerde variabelenamen of functies door hun werkelijke betekenis, kan de bedoeling achter bepaalde functies duidelijk worden.
- AST-analyse: Voor zeer complexe scripts wenden beveiligingsonderzoekers zich vaak tot zelf ontwikkelde scripts om de code te parsen en te transformeren. Door een JavaScript-parser te gebruiken om de Abstract Syntax Tree (AST) van een script te verkrijgen, kan een onderzoeker programmatisch door de structuur navigeren en obfuscatielagen verwijderen. Deze aanpak kan helpen om zaken zoals control-flow flattening of uitgebreide codering van functies automatisch te vereenvoudigen, al vereist het wel sterke programmeervaardigheden.
Kan geobfusceerde JavaScript automatisch worden geanalyseerd?
Automatische analyse en sandboxing zijn onmisbaar voor het verwerken van grote hoeveelheden geobfusceerde JavaScript en het in realtime opsporen van bedreigingen. Het handmatig analyseren van elk script is vaak onpraktisch, dus organisaties kunnen een combinatie van dynamische sandboxing, statische codeanalyse en threat intelligence inzetten om JavaScript op schaal te begrijpen.
- Dynamische analyse via sandboxing: Een manier om te bepalen wat verdachte code doet, is deze uitvoeren in een gecontroleerde omgeving (bijvoorbeeld een browser die stap voor stap door de code loopt) en observeren wat er gebeurt. Wanneer een geobfusceerd script daar wordt uitgevoerd, kan de sandbox vaak gedrag registreren dat kwaadaardig lijkt. Probeert het script het afrekenformulier te wijzigen? Doet het een AJAX-aanroep naar een verdacht of bekend kwaadaardig domein? Spawnt het verborgen iframes of verbruikt het een aanzienlijke hoeveelheid CPU? Omdat de sandbox de acties van het script ziet, kan het patronen markeren, zelfs als de code geobfusceerd was. Sommige sandboxes kunnen zelfs in de JavaScript-engine inprikken om de gedeobfusceerde code te dumpen zodra het script zichzelf in het geheugen heeft uitgepakt. De dynamische aanpak is geweldig omdat er geen begrip van de code voor nodig is en in plaats daarvan direct de kwaadaardige uitkomsten worden geobserveerd, maar geavanceerde malware kan dit detecteren en zijn gedrag aanpassen.
- Statische analyse met kunstmatige intelligentie en grote taalmodellen: Aan de statische kant van analyse gebruiken beveiligingstools vaak patroonherkenning en kunstmatige intelligentie om de tekst en het gedrag van scripts te onderzoeken en te bepalen of ze kwaadaardig zijn, zelfs als ze geobfusceerd zijn. Het gebruik van grote taalmodellen om snel een basislijn van activiteit van het script te verkrijgen is steeds populairder geworden, omdat het een beveiligingsanalist in staat stelt snel onderscheid te maken tussen een geminificeerd script en een kwaadaardig script.
Bij cside evalueert onze automatische analysepipeline zowel geobfusceerde als gedeobfusceerde JavaScript door detectieregels uit te voeren voor en na normalisatie van de code naar iets leesbaars. Deze tweelaagsaanpak helpt ons ontwijkende bedreigingen op te sporen die mogelijk pas verschijnen zodra de code is uitgepakt. Anders dan veel traditionele scanners gebruikt cside attribuutgebaseerde detectiemodellen om te zien hoe een script interageert met de DOM API en welke elementen het mogelijk aanmaakt, wijzigt en koppelt. Deze gedragsattributen stellen ons in staat verdachte wijzigingen te zien, zelfs als het script zwaar geobfusceerd is of tijdens runtime wordt gegenereerd.
Wat zijn enkele praktijkvoorbeelden van kwaadaardige geobfusceerde JavaScript-aanvallen?
Geobfusceerde JavaScript staat centraal in veel praktijkaanvallen waarover cside heeft gerapporteerd, van spraakmakende inbreuken tot alledaagse malwarecampagnes.
- Magecart-creditcardskimmers: Magecart is een overkoepelende term voor groepen die historisch gezien kwaadaardige JavaScript in e-commercesites hebben geïnjecteerd om betalingskaartnummers te stelen. Bij de aanval op British Airways in 2018 compromitteerden aanvallers scripts van derden en voegden geobfusceerde skimmercode in. Deze code was ontworpen om creditcardgegevens op afrekenspagina's te stelen en naar door aanvallers beheerde servers te sturen, terwijl het opgaat in legitieme scripts. Magecart-aanvallers gebruiken doorgaans scriptobfuscatie om functies te coderen en de ware bedoeling van de logica van de code te verbergen. Voor meer informatie over de British Airways-aanval heeft cside een speciaal rapport gepubliceerd over de aanval en (hoe we het domein dat bij de aanval werd gebruikt in handen kregen!)
- Cryptojacking-scripts: De opkomst van in-browser cryptocurrency-miners zag ook geobfusceerde code worden gebruikt om hun aanvallen uit te voeren. Bij een cryptojacking-aanval injecteert een aanvaller een script dat stilletjes de CPU van een bezoeker gebruikt om cryptocurrency te minen. Om gemakkelijke detectie te vermijden (buiten het pieken van het CPU-gebruik van een gebruiker), was de code vaak geobfusceerd of werd geserveerd vanaf een gecompromitteerd content-CDN. cside publiceerde onlangs hoe cryptojacking-aanvallen prominenter zijn geworden in het afgelopen jaar en sterk zijn veranderd in de manier waarop ze worden uitgevoerd.
- Progressive Web App-injectie en omleidingen: In 2025 rapporteerde cside over een aanval waarbij een Progressive Web App werd gebruikt om mobiele gebruikers om te leiden naar een Chinese oplichterij met volwasseneninhoud. De payload van deze aanval was eerder gezien, maar de levering via een Progressive Web App was een ongelooflijk unieke aanvalsvector. Hoewel PWA's vaak worden genegeerd in de client-side beveiligingsruimte, zijn ze ook vatbaar voor de browser-side aanvallen die cside vaak ziet.
Wat zijn de beste praktijken voor doorlopende JavaScript-beveiligingsmonitoring en -verdediging?
Je webapplicatie veilig houden tegen kwaadaardige code van derden is geen eenmalige inspanning, maar vereist doorlopende monitoring en goede praktijken om risico's te minimaliseren.
- De cside-proxy: De cside-proxy fungeert als tussenpersoon tussen je site en externe scripts van derden, waardoor we JavaScript-aanvallen kunnen onderscheppen, analyseren en stoppen voordat ze worden uitgevoerd in de browser van de gebruiker. Onze proxy maakt realtime monitoring van scriptgedrag mogelijk bij elke paginalading, zonder de codebase van de applicatie te wijzigen of Content Security Policy-vereisten aan te passen. Door scripts te inspecteren in zowel hun geobfusceerde als genormaliseerde vorm, kan de proxy regels handhaven en afwijkingen markeren - zelfs wanneer aanvallers obfuscatielagen rouleren of dynamische payloads injecteren.
- Scriptbronnen beperken en valideren: Het gebruik van Content Security Policy (CSP)-headers om strak te controleren van welke locaties scripts kunnen worden geladen, is een andere fantastische manier om je site te beschermen tegen ongewenste aanvallen. Een CSP-regel gebruiken om alleen je eigen domeinen en bekende CDN's op de whitelist te zetten en al het andere te blokkeren, is een geweldige eerste stap om JavaScript dat op je site draait te beveiligen. Het combineren van CSP met subresource integrity (SRI)-controles - die kunnen detecteren of een bestand is gewijzigd en voorkomen dat het wordt uitgevoerd - kan ervoor zorgen dat je alleen laadt wat je van plan bent te laden.
- Blijf op de hoogte en train je team: Het bedreigingslandschap evolueert ongelooflijk snel, en nieuwe obfuscatietrucs en aanvalstechnieken duiken voortdurend op. Investeer in het trainen van je beveiligingsteams, samen met je ontwikkelteams, over deze trends en beste praktijken om je ertegen te beschermen. Volg threat intelligence-rapporten en werk je eigen detectiepatronen dienovereenkomstig bij. Zorg ervoor dat je een incidentresponsplan hebt dat specifiek is voor client-side incidenten - als je bijvoorbeeld plotseling een geobfusceerde skimmer op je site detecteert, wie waarschuw je dan? Voorbereiding op deze scenario's zorgt voor een respons die de schade kan minimaliseren als er goed mee wordt omgegaan.
Slotgedachten
In het huidige browserecosysteem is JavaScript van derden zowel een noodzaak als een risico voor websites. Obfuscatietechnieken kunnen legitieme code dienen, maar worden ook vaak door aanvallers gebruikt om schadelijke payloads te verbergen - waardoor het moeilijker dan ooit is om potentiële bedreigingen te detecteren, analyseren en erop te reageren. De mogelijkheid om JavaScript te deobfusceren en het gedrag ervan te monitoren is niet langer optioneel. Het is absoluut cruciaal.
Bij cside hebben we onze technologie gebouwd om teams zichtbaarheid te geven in wat er werkelijk gebeurt binnen scripts van derden. Naarmate client-side aanvallen blijven evolueren, is investeren in payload-zichtbaarheid en realtime monitoring de beste verdediging die je vandaag kunt inzetten. Als je klaar bent om de controle over je JavaScript-risico van derden te nemen, neem dan contact met ons op en verken meer van onze threat intelligence-blog om op de hoogte te blijven van aanvalspatronen.
