In de advertentie- en trackingwereld klinkt het bijna onwerkelijk: een stukje JavaScript dat via een advertentie-technologieplatform werd aangeboden, bleek in staat om crypto-walletadressen vervangen. Wie op een getroffen website een adres kopieerde—bijvoorbeeld Bitcoin, Ethereum of Tron—kon tijdens het betalen onbewust een ander adres plakken dat door de aanvallers was ingebracht.
Adform meldde de kwestie na detectie op 27 juli 2026. Het kwaadaardige onderdeel is inmiddels verwijderd, maar de impact blijft vooral praktisch: ook na de fix kan een browser het gewijzigde bestand nog cachen, waardoor het risico voor gebruikers zonder extra maatregelen kan blijven bestaan.
Wat gebeurde er precies met dat Adform-script?
Volgens Adform ging het om een aangepast JavaScript-bestand dat als onderdeel van de normale trackingcode werd geserveerd. De aanvallers veranderden daarbij een bestaande bron, zodat de browserkant werd omgebouwd tot een tool die adressen herkent en vervolgens terugschrijft naar (naar verluidt) door de aanvallers gekozen varianten.
Het gaat om een gecompromitteerde resource met de naam trackpoint-async.js, gehost vanaf s2.adform[.]net. In plaats van alleen te observeren, greep de code actief in op wat bezoekers op de pagina zagen en invulden.
Adressen vervangen bij kopiëren én bij invoer
Belangrijk is dat het niet alleen draaide op “kopiëren en plakken”. De code probeerde meerdere routes te gebruiken:
- Het programma wachtte op een copy-event, las vervolgens het klembord en verving adressen als die overeenkwamen met bekende Bitcoin-, Ethereum- of Tron-patronen.
- Daarnaast herschreef de code waarden die direct in formuliervelden werden gezet, inclusief input, textarea en velden die op de pagina als bewerkbaar waren gemarkeerd.
- Ook paste de code intercepties toe op gebeurtenissen zoals cut, paste en input, waardoor zelfs programmatic writes konden worden overgenomen.
- Om de gebruikerservaring te beperken werd de cursorpositie na een wijziging hersteld, zodat het minder opvalt bij de bezoeker.
In de analyse die door een onafhankelijke onderzoeker is gedeeld, wordt bovendien genoemd dat de vervangen adressen niet volledig vast leken te staan: er zouden variaties zijn geweest.
Waarom dit lijkt op een supply-chain compromis
Adform benadrukt dat trackingcode in verschillende pagina-situaties kan worden uitgevoerd—op één pagina, op secties, of zelfs onvoorwaardelijk over een hele website. Door juist zo’n gedeelde resource te compromitteren, kregen aanvallers een manier om door te dringen tot meerdere, anders niet-direct verbonden webpagina’s zonder elk doel apart te hacken.
Die gedeelde uitrolroute maakt dit concreet een supply-chain aanval: één component in de keten (de geleverde scriptbron) wordt gemanipuleerd, waarna downstream sites er last van kunnen hebben.
Wat moesten bezoekers doen (en wat moet je nu doen)?
Adform adviseert gebruikers om hun browsercache te wissen. Dat advies is logisch: zelfs nadat de code is verwijderd, kan een browser de gewijzigde versie nog blijven gebruiken zolang die in de cache zit.
Daarnaast is er één heel praktische regel die Adform ook teruggeeft: controleer altijd het walletadres voordat je geld verstuurt. Als je bijvoorbeeld een adres van een website overneemt, kan het onder omstandigheden zijn dat het adres is gewijzigd—en de gebruiker zou dat zonder check pas later merken.
Omdat het om transacties gaat, is “even snel opnieuw kopiëren” alleen niet per se voldoende. In de openbaar gedeelde analyse wordt beschreven dat het adres opnieuw kon worden vervangen, zelfs als iemand het “fout” opmerkte en het opnieuw recopyde.
Had de code ook informatie over gebruikers?
Adform stelt dat er geen aanwijzingen waren dat het script de IP-adressen of bezochte websites van bezoekers had verstuurd. Tegelijkertijd vermeldt het bedrijf dat technische analyse “transmissie mogelijk” maakte.
In de onderzochte sample is namelijk te zien dat de code bij het laden van de pagina een HTTP-aanvraag probeert op te zetten naar een extern adres. Daarbij wordt in elk geval de hostname en padinformatie van de huidige pagina meegenomen.
Of die aanvraag daadwerkelijk de operator heeft bereikt en wat er precies met eventuele verzamelde informatie is gebeurd, is nog niet definitief vastgesteld op basis van wat publiek bekend is.
Scope en tijdlijn: waarom het lastig is om de impact precies te schatten
De openbare tijdlijn is tot nu toe niet volledig afgerond. Adform noemt 27 juli 2026 als de getroffen datum. Tegelijkertijd is er public observatie gedaan door een onafhankelijke onderzoeker die een langere periode aan kwaadaardige activiteit beschrijft.
Dat maakt het moeilijk om een verdedigbare inschatting te maken van de blootstelling: hoeveel pagina’s kregen het gewijzigde script daadwerkelijk, hoeveel bezoekers waren aanwezig en—in het zwaarste scenario—of er ook echt geld is omgeleid.
Ook ontbreekt op dit moment een publieke lijst met indicators of compromise. Daardoor is het voor organisaties die zelf op Adform draaien vooral zaak om hun eigen risico-inschatting te combineren met gebruikersadviezen en technische opschoning.
Wat betekent dit voor organisaties en webteams?
Dit incident laat vooral zien dat moderne webomgevingen kwetsbaar kunnen zijn op het niveau van gedeelde scripts en leverancierscomponenten. Zelfs als een organisatie zelf geen “klassieke” hack lijkt te hebben uitgevoerd, kan een gemanipuleerde afhankelijkheid via advertentie- of trackingketens alsnog ingrijpen.
Concreet zijn dit de aandachtspunten die je kunt meenemen:
- Controleer cached resources en zorg dat gebruikers na een fix veilig verder kunnen (cache wissen is dus niet alleen een aanbeveling, maar een noodzakelijke stap).
- Bekijk welke gedeelde leveranciersscripts op betaal- of adresvelden worden geladen—zeker als je crypto-adressen toont of transacties faciliteert.
- Verifieer data op gevoelige momenten: als adressen op de pagina worden getoond of in velden terechtkomen, helpt het om te controleren of je eigen front-end geen ongewenste mutaties ondergaat.
- Werk incidentcommunicatie praktisch uit: gebruikers hebben vooral iets aan concrete instructies (“cache wissen” en “adres controleren”).
Wil je breder kijken naar hoe supply-chain risico’s zich voordoen in software en gegevensstromen, dan is het ook relevant om eerdere analyses over implicaties van hacks en patches te lezen: Impulsies van hacks en patches: wat je nu doet.
Gerelateerde waarschuwingen: van tracking tot backdoors
Dit type aanval—waar code via een keten wordt gemanipuleerd—past in een bredere trend waarin aanvallers bestaande infrastructuur misbruiken. Eerder kwamen bijvoorbeeld ook incidenten langs waarbij indirecte levering of misbruik van gedeelde componenten tot onverwachte effecten leidde, zoals in analyses over backdoors en gerichte intrusies.
Ter verdieping kun je ook deze artikelen meenemen: Post-breach aanval: wat hackers doen binnen. Dat helpt om te begrijpen hoe aanvallers na een initiële ingang vaak verder uitpakken—ook al begon die ingang in eerste instantie “klein” of indirect.
Conclusie
Adform’s incident draait om één kernmechanisme: een aangepast JavaScript-script kon crypto-walletadressen vervangen op webpagina’s waar het werd geladen. Bezoekers die in de periode rond 27 juli 2026 adressen kopieerden of invoerden, konden een gemanipuleerd adres tegenkomen—met mogelijk financiële gevolgen.
De belangrijkste lessen zijn tegelijk eenvoudig en dringend: wis je browsercache na een fix, controleer walletadressen vóór verzending en behandel gedeelde scripts als een echte supply-chain afhankelijkheid. Daarmee verklein je de kans dat één gemanipuleerde bron het hele betaalproces kan ondermijnen.
Bron: https://thehackernews.com/2026/08/hackers-poison-adform-script-to-swap.html
