Kwaadaardige MCP-servers en e-mailbeveiliging: de nieuwe bedreiging voor de toeleveringsketen
door
Laatst bijgewerkt: 9 leestijd: 9 minuten
Belangrijkste Conclusies
- Aanvallers maken gebruik van npm-pakketten met typosquatting om ontwikkelaars ertoe te verleiden valse Model Context Protocol (MCP)-servers te installeren.
- Deze kwaadaardige servers nemen vooraf geautoriseerde API-sleutels van bedrijven over en sturen gevoelige uitgaande gegevens ongemerkt in BCC naar domeinen die door aanvallers worden beheerd.
- Omdat deze e-mails via uw legitieme infrastructuur worden verzonden, worden ze automatisch door traditionele filters zoals SPF en DKIM doorgelaten.
- Om deze kloof te dichten, zijn een grondige controle van de afhankelijkheid van applicaties, een API-scoping op basis van het ‘minimale-rechtenprincipe’ en continue monitoring van de totale DMARC -volumes vereist.
In september 2025 zette één enkele regel verborgen code in een open-source npm-bibliotheek onze aannames over de veiligheid van de toeleveringsketen op losse schroeven. Hierdoor kwam kwaadaardige e-mailbeveiliging op MCP-servers in beeld als een gevaarlijke nieuwe categorie bedreigingen.
Het pakket, postmark-mcp, heeft meer dan een week lang dagelijks tussen de 3.000 en 15.000 zakelijke e-mails doorgestuurd naar een aanvaller. Er was hier geen sprake van een opvallende zero-day-exploit; alleen een eenvoudige, verborgen regel voor blinde kopieën (BCC) die met volledige beheerdersrechten werd uitgevoerd. De gevolgen waren verwoestend: er lekten wachtwoorden, interne facturen, klantgegevens en actieve authenticatietokens uit.
Dit is het eerste gedocumenteerde geval van een kwaadwillige inbreuk op een MCP-server in de praktijk. Naarmate autonome AI-agenten steeds meer worden ingezet in bedrijfsprocessen, ontstaat er een enorme blinde vlek. Traditionele beveiligingsmaatregelen zoals SPF, DKIM en DMARC zijn ontwikkeld voor een tijdperk van voorspelbare, door mensen aangestuurde e-mailroutering. Het Model Context Protocol (MCP) -paradigma gooit die situatie volledig overhoop en introduceert een laag van bedreigingen van binnenuit die traditionele perimeterfilters simpelweg niet kunnen opvangen.
Wat er gebeurde – Het poststempel-mcp-incident
Postmark (beheerd door ActiveCampaign) is een populaire dienst voor transactionele e-mails die door duizenden bedrijven wordt gebruikt om belangrijke geautomatiseerde meldingen te versturen, zoals wachtwoordherstelberichten en orderbevestigingen. Om de opmars van generatieve AI te ondersteunen, is er een officiële open-source-repository op GitHub gelanceerd waarmee ontwikkelaars de Claude AI-assistent van Anthropic via het Model Context Protocol rechtstreeks aan de infrastructuur van Postmark kunnen koppelen.
Een kwaadwillende actor zag hierin een kans en bracht een pakket uit met een bijna-identieke naam: postmark-mcp. Dit was geen onopzettelijke typefout; de naam kwam exact overeen en was bedoeld om ontwikkelaars te misleiden die snel een npm-installatie wilden uitvoeren.
De lange termijn: vertrouwen opbouwen
De aanvaller speelde een weloverwogen langetermijnspel. Gedurende vijftien opeenvolgende versies (van 1.0.0 tot 1.0.15) werkte het pakket feilloos. Het kwam volledig overeen met de code van de officiële repository, voerde API-aanroepen perfect uit en veroorzaakte geen enkele waarschuwing. Hierdoor kon het moeiteloos door de geautomatiseerde sandbox-controles glippen en het basisvertrouwen van beveiligingsmonitoringsystemen winnen.
De payload activeren
Op 17 september 2025 werd er aanzienlijke schade aangericht met versie 1.0.16. Diep in index.js, op regel 231, voegde de uitgever één regel code toe. Deze aanpassing zorgde ervoor dat aan elke e-mail die via de server werd verzonden een verborgen BCC-adres werd toegevoegd, en dat kopieën werden doorgestuurd naar een door de aanvaller gecontroleerd domein [giftshop.club].
Omdat deze module deel uitmaakte van de gevalideerde applicatielaag, beschikte deze al over geautoriseerde toegang tot actieve API-sleutels. Voor de aanval was geen ingewikkelde uitbreiding van rechten nodig. Het werkte omdat de code binnen een vertrouwde bedrijfspijplijn draaide. Het datalek bleef bestaan tot 25 september 2025, toen de risicomotor van Koi Security afwijkende gedragspatronen signaleerde die afkomstig waren uit de bibliotheek.
De impact
Uit controles achteraf door Koi Security en Snyk bleek dat het pakket ongeveer 1.643 keer was gedownload, wat neerkwam op zo’n 1.500 actieve wekelijkse installaties die dagelijks gegevens lekten.
Toen dit aan het licht kwam, heeft de uitgever het pakket uit npm verwijderd. Maar hier zit de echte uitdaging: het verwijderen van een pakket uit een openbaar register betekent niet dat het ook uit actieve omgevingen wordt verwijderd. Elke actieve cloudcluster of containerpijplijn die versie 1.0.16 draaide, lekte gegevens totdat teams het opspoorden en handmatig verwijderden. Postmark bracht snel een verklaring uit waarin werd verduidelijkt dat zij het pakket niet hadden ontwikkeld, geautoriseerd of onderhouden. Omdat dit een gedragsmatige achterdeur was in plaats van een codefout, werd er geen formele Common Vulnerabilities and Exposures-identificatie toegewezen, waardoor er een unieke, niet-geverifieerde voetafdruk van een MCP-server-toeleveringsketenaanval achterbleef.
Als je denkt dat je team dit pakket ooit heeft gebruikt, behandel het dan als een actueel incident: verwijder het onmiddellijk uit alle omgevingen, vernieuw alle inloggegevens en API-sleutels die er ooit mee in aanraking zijn geweest, en doorzoek je e-maillogboeken op BCC-verkeer dat naar het gemarkeerde domein is verstuurd. Het is ook de moeite waard om de rest van het account van de uitgever te controleren; dezelfde auteur beheerde nog zo’n 31 andere pakketten, die allemaal hetzelfde risico kunnen inhouden.
Waarom zijn MCP-servers een aantrekkelijk doelwit voor e-mailaanvallen?
Het Model Context Protocol (MCP) is hard op weg om het standaardintegratiekader voor AI in het bedrijfsleven te worden. Gartner verwacht dat tegen eind 2026 75% van de leveranciers van API-gateways native MCP-toolsets zal hebben geïntegreerd om de e-mailbeveiliging met behulp van agent-gebaseerde AI te beheren.
Wat houdt een Model Context Protocol-integratie precies in? Zie een MCP-server als een beveiligde API-brug die een AI-assistent (zoals Claude) verbindt met externe gegevensopslagplaatsen, ontwikkelomgevingen en tools van derden. In plaats van een wirwar van aangepaste API’s te beheren, gebruikt een AI-agent dit uniforme protocol om zelfstandig databases te doorzoeken, CRM-systemen te raadplegen of e-mailprocessen te coördineren.
De kernkwetsbaarheid: volledig vertrouwen
Om goed te kunnen functioneren, heeft een MCP-server uitgebreide, langdurige toegangsrechten nodig. Wanneer je een AI-agent koppelt aan een e-mailgateway om de planning of de klantenservice te automatiseren, geef je deze volledige lees- en schrijftoegang. De agent gedraagt zich dan als een medewerker met volledige delegatierechten.
Zoals Idan Dardikman, CTO van Koi Security, het verwoordde: organisaties geven in feite administratieve rechten met volledige toegang (god-mode) uit handen aan backend-tools die zijn ontwikkeld door niet-geverifieerde, onbetrouwbare externe ontwikkelaars.
In tegenstelling tot traditionele aanvallen op de softwaretoeleveringsketen (zoals bij SolarWinds), die gericht zijn op de diepe infrastructuur, is bij risico’s met MCP-servers van derden geen hacking van de infrastructuur nodig. Aanvallers hoeven je alleen maar te misleiden om de module te installeren, waarna de AI-agent deze zelfstandig uitvoert. Omdat er geen menselijke tussenkomst is om een geautomatiseerde workflow te controleren, kan een gecompromitteerde bibliotheek dagenlang gevoelige gegevens wegsluizen zonder dat er ook maar één alarmbel afgaat.
De lacune in e-mailverificatie – Wat DMARC wel en niet kan beschermen
Terwijl risicoteams zich inspannen om zich te verdedigen tegen deze e-mailaanvallen via de toeleveringsketen die door AI worden aangestuurd, gaan velen ervan uit dat protocollen als SPF, DKIM en DMARC het bloeden zullen stelpen. Maar we moeten goed kijken naar wat deze maatregelen nu precies doen en waar de lacunes zitten.
Wat DMARC, SPF en DKIM moesten voorkomen
De kernfuncties van SPF, DKIM en DMARC zijn ontwikkeld om domeinvervalsing tegen te gaan en te voorkomen dat kwaadwillenden e-mailvervalsings- of BEC-campagnes uitvoeren onder de vlag van uw merk.
- SPF controleert of het IP-adres van de verzendende mailserver is geautoriseerd in uw DNS-records.
- DKIM voegt een unieke digitale handtekening toe aan de header om aan te tonen dat een bericht tijdens het verzenden niet is gewijzigd.
- DMARC brengt deze elementen samen en legt regels op voor de manier waarop ontvangende servers met fouten omgaan.
Bij de Postmark-MCP-exploit werden deze controles niet omzeild; ze waren volstrekt irrelevant. Omdat het kwaadaardige pakket was ingebed in een legitieme bedrijfsapp, maakte het gebruik van geldige API-sleutels om berichten via geautoriseerde Postmark-servers te routeren. Elke gestolen e-mail was voorzien van een onberispelijke DKIM-handtekening en doorstond de SPF-controles feilloos. Dit heeft een bittere ironie: die geldige DKIM-handtekening hielp zelfs de eigen ontvangstserver van de aanvaller om te bevestigen dat de gestolen berichten authentiek waren.
Wanneer e-mailverificatie gedeeltelijk helpt
| Protocolcomponent | Weerstand tegen kwaadaardige MCP-servers | Beperking |
|---|---|---|
| SPF en DKIM | Controleert of de infrastructuur correct is. | Wordt volledig toegestaan omdat de aanval afkomstig is van de geautoriseerde applicatielaag. |
| DMARC-handhaving (p=afwijzen) | Voorkomt het vervalsen van externe domeinnamen. | Het is niet mogelijk om te voorkomen dat een geldige interne applicatie een BCC-regel uitvoert of gegevens rechtstreeks openbaar maakt. |
| DMARC-rapportage (RUA / RUF) | Biedt gedetailleerd inzicht in de volumes van uitgaande berichten en externe bronnen. | Vereist continue, geautomatiseerde monitoring en gedragsanalyse om afwijkingen op te sporen. |
Wat e-mailverificatie hier wel en niet kan
DMARC, SPF en DKIM zijn ontwikkeld om spoofing tegen te gaan, niet om gegevenslekken door interne medewerkers te voorkomen
| Kan niet blokkeren | kan onthullen | Kan bevatten |
|---|---|---|
| De kwaadaardige server maakt gebruik van een legitieme API-sleutel, waardoor SPF en DKIM PASS automatisch p=reject niet kunnen voorkomen dat een geldige interne app een BCC toevoegt en gegevens rechtstreeks lekt | De geaggregeerde rapporten van RUA brengen alle verzendbronnen op uw domein in kaart: Een plotselinge piek in het uitgaande transactievolume is het waarschuwingssignaal | De overstap naar p=reject fungeert als een vangnet tegen negatieve gevolgen Het voorkomt dat aanvallers gestolen inhoud misbruiken om uw domein te vervalsen in daaropvolgende phishingcampagnes |
De kracht van DMARC-rapporten om inzicht te bieden
Hoewel het de eerste code-injectie niet zal tegenhouden, biedt een goed uitgewerkte e-mailverificatie-opstelling wel essentieel inzicht. Dit komt neer op gedetailleerde DMARC-rapporten (RUA/RUF).
Als deze records correct zijn geconfigureerd, bieden ze u een duidelijk overzicht van elk IP-adres en elke verzendservice die op uw domein actief is. Aggregate-rapporten (RUA) geven een overzicht van de verzendvolumes per bron, terwijl failure-rapporten (RUF) gedetailleerde informatie over individuele storingen bevatten. Als uw SecOps-team deze stromen continu controleert, kan het plotselinge, onverklaarbare pieken in het uitgaande transactievolume opmerken. Het bijhouden van dergelijke afwijkingen fungeert als een rookmelder en geeft aan dat er bij een integratie gegevens weglekken.
Een vangnet creëren met strikte handhaving
Door uw domein over te zetten naar een strikte DMARC-instelling met p=reject creëert u een essentieel vangnet tegen secundaire gevolgen. Dit voorkomt weliswaar niet dat een interne MCP-server gegevens via BCC verstuurt, maar het zorgt er wel voor dat aanvallers de gestolen gegevens niet kunnen misbruiken. Een ‘reject’-beleid voorkomt dat cybercriminelen gelekte facturen of klantgegevens gebruiken om zeer gerichte, vervalste phishingcampagnes te lanceren tegen uw klanten en partners, waarbij ze uw eigen domein gebruiken.
De echte kloof – het bijhouden van inloggegevens en machtigingen
In wezen ging het bij dit beveiligingslek om een tekortkoming op het gebied van identiteitsbeheer en toegangscontrole, en niet om een probleem met het authenticatieprotocol. De aanval slaagde omdat een niet-geverifieerd stukje software toegang had tot een legitieme API-sleutel met uitgebreide rechten.
Uw belangrijkste verdedigingsmiddel hier is het controleren van codeafhankelijkheden en het goed beheren van inloggegevens. Als u echter autonome AI-tools implementeert zonder een actieve monitoringlaag, bent u volledig blind. Continue DMARC-monitoring biedt het actieve vangnet dat nodig is om afwijkend gedrag op te sporen dat wijst op een actieve aanval.
Hoe u uw organisatie kunt beschermen tegen kwaadaardige MCP-e-mailaanvallen
Voor een goede beveiliging van de e-mailverkeer op een MCP-server zijn de volgende operationele maatregelen noodzakelijk:
1. Controleer de omvang van uw MCP-serveromgeving
Wat je niet bijhoudt, kun je ook niet beveiligen. Maak een gedetailleerd overzicht van alle actieve integraties, plug-ins of koppelingspunten die aan je e-mailconfiguratie zijn gekoppeld.
- Controleer of de integratie afkomstig is uit een officiële leveranciersrepository of uit een niet-geverifieerd community-pakket op npm of PyPI.
- Leg expliciet vast welke gegevens en eindpunten elke integratie kan benaderen.
- Gebruik open-source beveiligingstools zoals mcp-scan om uw omgeving te scannen en te analyseren op afwijkend gedrag.
2. Pas het principe van minimale rechten toe op AI-e-mailintegraties
Geef geautomatiseerde tools geen onbeperkte beheerdersrechten meer.
- Beperk API-sleutels zodanig dat ze alleen de exact benodigde acties toestaan (bijvoorbeeld het versturen van meldingen), terwijl volledige lees- en schrijftoegang tot de mailbox expliciet wordt geblokkeerd.
- Hanteer strikte schema’s voor het rouleren van API-sleutels en trek inloggegevens onmiddellijk in als een afhankelijkheid een waarschuwing genereert.
- Gebruik firewall- en netwerkbeveiligingsbeleidsregels om uitgaande verbindingen vanaf MCP-servers te beperken en alleen bekende API-eindpunten voor zakelijke e-mail op de witte lijst te plaatsen.
3. Schakel DMARC-rapportage in en controleer op afwijkingen
Als u de geaggregeerde DMARC-gegevens niet actief analyseert, ontbreekt er een belangrijk stukje informatie in uw operationele overzicht. Door een speciale DMARC-analysetool in te zetten, krijgt uw team continu inzicht. Zo kunt u gegevensstromen volgen, referentiewaarden voor het datavolume vaststellen en worden gewaarschuwd bij plotselinge pieken in uitgaande transacties, nog voordat er ernstige schade ontstaat.
4. Pas DMARC toe met de instelling p=reject
Als u uw domein op de zwakke instelling `p=none` laat staan, biedt dit geen echte bescherming. Door over te stappen op het strikte handhavingsniveau `p=reject` zorgt u ervoor dat een aanvaller, zelfs als hij erin slaagt e-mailinhoud te stelen via een gecompromitteerde integratie, die gestolen informatie nooit kan gebruiken om vervalste campagnes te lanceren die uw officiële merkdomein nabootsen.
5. Controleer MCP-servers vóór de implementatie
Behandel elke MCP-servermodule met precies dezelfde zorgvuldigheid als elk ander onderdeel van de bedrijfsinfrastructuur dat bevoorrechte toegang vereist. Controleer de reputatie van de uitgever, vergelijk de pakketten met de officiële documentatie van de leverancier en bekijk de onderliggende broncode voordat u deze in productie neemt.
Om risico’s tot een minimum te beperken, moet u onbeoordeelde open-sourcepakketten vermijden en kiezen voor gecertificeerde, door leveranciers geverifieerde integraties. Voor teams die automatisering implementeren, biedt het controleren van geverifieerde leveranciersopties, zoals de PowerDMARC MCP Server, de zekerheid van een veilige, geauthenticeerde integratielaag die speciaal is ontwikkeld voor veilige bedrijfsvoering.
Het bredere perspectief – MCP Security zal de volgende fase van e-mailbedreigingen bepalen
De inbreuk op de postmark-mcp-bibliotheek was bewust eenvoudig opgezet: één ontwikkelaar, een simpele truc om namen te matchen en één regel verborgen code. Toch leidde dit tot een grootschalige datalek. Nu bedrijven in hoog tempo autonome AI-tools gaan gebruiken en MCP de norm wordt in softwarearchitecturen, zullen cybercriminele groeperingen onvermijdelijk veel geavanceerdere aanvallen gaan uitvoeren.
Beveiligingsteams moeten zich voorbereiden op verschillende nieuwe bedreigingen:
- Indirecte prompt-injectie: Aanvallers die kwaadaardige e-mails versturen die bedoeld zijn om een AI-agent die de inbox doorzoekt te manipuleren en hem ertoe te brengen gevoelige gegevens verkeerd door te sturen of interne sleutels te lekken.
- Kwaadaardige workflow-tools: Aanvallers brengen ogenschijnlijk nuttige AI-productiviteitstools op de markt die op de achtergrond stilletjes inloggegevens en tokens verzamelen.
- Hoogwaardige lookalikes: geavanceerde typosquatting-campagnes die gericht zijn op CRM-, HR- en financiële integraties voor bedrijven op netwerken voor ontwikkelaarspakketten.
E-mail is behoorlijk kwetsbaar omdat het zich bevindt op het snijvlak van bedrijfscommunicatie, identiteitsverificatie (het opnieuw instellen van wachtwoorden) en cruciale bedrijfsgegevens. MCP-servers die AI aan deze infrastructuur koppelen, hebben toegang tot alle drie.
Conclusie
Het dreigingslandschap op het gebied van e-mail is inmiddels veel verder gegaan dan louter externe phishing. Het Postmark-MCP-incident toont aan dat organisaties nu te maken hebben met AI-gestuurde bedreigingen in de toeleveringsketen die onopgemerkt opereren binnen vertrouwde interne omgevingen. Deze integratieaanvallen maken gebruik van geldige inloggegevens om verouderde filters te omzeilen, en dat is precies de reden waarom beveiliging tegen kwaadaardige MCP-servers nu op de agenda van elke CISO hoort te staan.
Om uw onderneming te beschermen, moet u een evenwicht vinden tussen strenge toegangsbeperkingen en voortdurende gegevensmonitoring. Door een strikt handhavingsbeleid te combineren met diepgaande rapportage-inzichten kunt u afwijkende verzendvolumes aan het licht brengen en ongeoorloofde integraties opsporen voordat gegevens definitief verloren gaan.
Laat uw geautomatiseerde systemen niet onbewaakt. Bescherm uw domein vandaag nog tegen verborgen bedreigingen op applicatieniveau. Krijg inzicht in alle bronnen die namens uw domein e-mails versturen; begin met monitoren via de DMARC Analyzer van PowerDMARC.
Veelgestelde Vragen
Wacht even, als mijn e-mails de SPF- en DKIM-controles doorstaan, hoe kan het dan om misbruik gaan?
Omdat het verzoek vanuit het huis zelf komt. Het kwaadaardige pakket vervalst je domein niet vanaf een willekeurige malafide server. Het bevindt zich midden in je vertrouwde applicatieomgeving en kaapt je echte, legitieme API-sleutels. Voor de rest van de wereld heeft je server die e-mail op legitieme wijze verzonden, en daarom geven cryptografische perimeterprotocollen er groen licht voor. Het is een probleem van gegevensdiefstal, geen probleem van serververvalsing.
Als DMARC het lekken van gegevens niet kan voorkomen, waarom zou ik het dan inschakelen?
Beschouw de geaggregeerde DMARC-rapportage van RUA als de rookmelder van uw netwerk. Als een MCP-server stilletjes duizenden operationele e-mails via BCC naar een externe inbox begint te sturen, zal uw volume aan transactionele e-mails drastisch stijgen. Als u uw DMARC-gegevensstromen actief in de gaten houdt, springt die plotselinge volumeverandering meteen in het oog, waardoor uw SecOps-team tijdig wordt gewaarschuwd om actieve codeafhankelijkheden te controleren.
Ons team heeft AI-tools nodig om supportmails te verwerken. Hoe kunnen we dit op een veilige manier doen zonder de integraties volledig uit te schakelen?
Je hoeft AI-automatisering niet te blokkeren, je hoeft er alleen maar grenzen aan te stellen. Ten eerste: behandel MCP-servers als infrastructuuronderdelen met een hoog risico: installeer nooit onbewerkte community-scripts zonder dat de code is gecontroleerd. Ten tweede: beperk je API-sleutels met uiterst specifieke, gedetailleerde machtigingen; als een agent alleen ondersteuningsreacties hoeft te versturen, beperk dan zijn API-token zodanig dat het fysiek onmogelijk is om bulkgegevens op te vragen, accounts aan te maken of BCC-regels toe te passen. Tot slot: houd het bij geverifieerde leveranciersintegraties zoals de PowerDMARC MCP-server in plaats van niet-geverifieerde community-klonen.
Hoe kan ik controleren of mijn ontwikkelteam per ongeluk een schadelijke MCP-server heeft geïnstalleerd?
De eerste stap is het uitvoeren van een SCA-scan (Software Composition Analysis) of het gebruik van open-source tools zoals mcp-scan om je actieve omgeving in kaart te brengen. Kijk goed naar openbare pakketregisters zoals npm en PyPI voor niet-geverifieerde community-bibliotheken van derden die uw communicatiepijplijnen beheren. Als een bibliotheek niet rechtstreeks is gepubliceerd en ondertekend door een geverifieerde zakelijke leverancier, zoals de officiële Postmark-repository of de beveiligde PowerDMARC MCP-server, beschouw deze dan als een risico totdat de code handmatig is gecontroleerd.
Content-specialist bij PowerDMARC
Milena is een ervaren schrijfster en content creator met meer dan 7 jaar ervaring in het creëren van boeiende content over IT, cyberbeveiliging, virtuele evenementen en meer. Ze heeft bewezen werk van hoge kwaliteit af te leveren voor internationale tijdschriften en is afgestudeerd aan prestigieuze instellingen zoals New York University Abu Dhabi, UWC China en het Europacollege.
Laatste berichten van Milena Baghdasaryan (Bekijk alle berichten)
