Wat is DNS-vergiftiging? Uitleg over DNS-cachevergiftiging

DNS-cachevergiftiging (DNS-spoofing) maakt misbruik van kwetsbaarheden in uw DNS en servers. Lees wat het is en hoe u deze cyberaanval kunt oplossen.

Een DNS-cachevergiftigingsaanval, ook wel bekend als DNS-spoofing , is een van die bedreigingen waarover niet zo vaak wordt gesproken als over phishing of malware. Dit negeren is de grootste fout die men kan maken. DNS vormt de basis van vrijwel alles wat online gebeurt. Wanneer het dus wordt gecompromitteerd, verspreiden de gevolgen zich snel. De gevolgen zijn altijd ingrijpend: het vertrouwen in domeinen wordt aangetast, e-mailverificatie werkt niet meer, de beveiliging van het dataverkeer wordt ondermijnd en de reputatie van het merk krijgt een deuk. 

Als iemand knoeit met de manier waarop mailservers of gebruikers je domein omzetten, heb je meestal te maken met identiteitsfraude, diefstal van inloggegevens, phishing of e-mails die gewoon niet meer aankomen. 

Dit is wat er werkelijk achter de schermen gebeurt, en waarom het zo moeilijk is om dit te ontdekken.

Wat is DNS-cachevergiftiging?

De hele taak van DNS bestaat uit het omzetten van domeinnamen naar IP-adressen. Bij cache poisoning wordt juist die omzettingsstap aangevallen. Een aanvaller voert vervalste DNS-gegevens in bij een eindpunt, browser of systeem. Dus wanneer een slachtoffer een bepaalde website probeert te bezoeken, komt het niet op de echte site terecht, maar ergens anders. Vaak gaat het om een pagina die er precies hetzelfde uitziet en speciaal is gemaakt om informatie te verzamelen. 

DNS-cache lijkt op een man-in-the-middle-aanval. Een resolver neemt vervalste gegevens op, slaat deze op en begint vervolgens het verkeerde IP-adres uit te geven voor een domein dat op het eerste gezicht nog steeds legitiem lijkt. Vanaf dat moment wordt iedereen die vertrouwt op de vergiftigde resolver doorgestuurd naar het IP-adres van de aanvaller, en dat gaat door totdat het in de cache opgeslagen record verloopt. De aanvaller hoeft de DNS-server niet eens rechtstreeks aan te raken. Eén vervalst antwoord dat in de cache van de resolver terechtkomt, is voldoende om iedereen stroomafwaarts om te leiden.
Laten we eens een voorbeeld bekijken van hoe dat in de praktijk werkt.

Hoe werkt DNS-vergiftiging?

Het komt neer op een race. De aanvaller moet ervoor zorgen dat zijn valse antwoord de resolver bereikt voordat het echte antwoord dat doet. Hieronder wordt stap voor stap uitgelegd hoe dat in zijn werk gaat:

1. De gebruiker start een DNS-verzoek: Een browser of applicatie stuurt een DNS-verzoek naar een recursieve resolver met de vraag naar het IP-adres van een domein (bijvoorbeeld bank.com).
2. De resolver controleert zijn cache: Als het antwoord in de cache staat en de TTL nog niet is verstreken, geeft de resolver het onmiddellijk terug. Zo niet, dan stuurt hij de query door naar de autoritatieve DNS-servers.
3. De aanvaller injecteert een vervalste reactie: Voordat het legitieme, gezaghebbende antwoord binnenkomt, verstuurt de aanvaller een vervalst DNS-antwoord dat een kwaadaardig IP-adres bevat. Dit is mogelijk door het transactie-ID en de bronpoort die in de oorspronkelijke query zijn gebruikt te raden of te kraken met een brute-force-aanval, een techniek die bekendstaat als de Kaminsky-aanval.
4. De resolver slaat het vervalste record op: Als het vervalste antwoord van de aanvaller als eerste binnenkomt en overeenkomt met het verwachte transactie-ID en de poort, accepteert de resolver het frauduleuze IP-adres en slaat het op in de cache.
5. Gebruikers worden omgeleid: Alle daaropvolgende verzoeken voor dat domein, afkomstig van elke gebruiker die de besmette resolver raakt, retourneren het IP-adres van de aanvaller, waardoor ze naar een frauduleuze site worden geleid totdat de TTL van de cache verloopt of de cache handmatig wordt geleegd.

De aanvaller moet handelen voordat de TTL voor de in de cache opgeslagen gegevens afloopt. Traditionele DNS beschikt niet over ingebouwde cryptografische validatie, waardoor resolvers niet kunnen controleren of een antwoord authentiek is, tenzij DNSSEC en veilige resolverpraktijken zijn geïmplementeerd. Totdat het vervalste record verloopt, blijft de resolver het valse IP-adres aan de getroffen gebruikers en systemen verstrekken.

Hoe aanvallers DNS-caches vergiftigen

Er is niet slechts één manier om dit voor elkaar te krijgen. Aanvallers maken gebruik van een aantal beproefde technieken om vervalste DNS-records in de cache van een resolver te smokkelen:

Waarom zijn DNS-vergiftigingsaanvallen zo effectief?

Bij het ontwerp van DNS stond beschikbaarheid centraal, niet authenticatie. Het oorspronkelijke protocol bevatte nooit een manier om te controleren of een antwoord authentiek is. Tenzij DNSSEC is geïmplementeerd en daadwerkelijk wordt gevalideerd, vertrouwen resolvers de antwoorden dus uiteindelijk puur en alleen omdat het transactie-ID en de poort toevallig overeenkomen.

Die kloof leidt in de praktijk tot verschillende problemen:

• In de cache opgeslagen records verspreiden op grote schaal onjuiste gegevens. Eén besmette resolver kan ongemerkt het verkeerde antwoord verstrekken aan duizenden gebruikers, organisaties of downstream-resolvers, en dat allemaal voordat de TTL afloopt.
• Gebruikers vertrouwen op bekende domeinnamen. De browser geeft nog steeds een URL weer die er correct uitziet, dus er is vaak geen zichtbare aanwijzing dat er iets mis is, vooral wanneer de site van de aanvaller visueel sterk lijkt op de echte site.
• De zichtbaarheid van resolvers is doorgaans beperkt. De meeste organisaties hebben weinig inzicht in hoe de recursieve resolvers die door medewerkers, klanten of partners worden gebruikt, zich daadwerkelijk gedragen, wat de detectie vertraagt.
• Het venster voor vraag-antwoord is kwetsbaar. Het is smal, maar niet smal genoeg. Resolver-systemen met voorspelbaar gedrag of zwakke willekeurigheid bieden aanvallers net genoeg ruimte om de race te winnen.

Risico’s en gevolgen van DNS-vergiftiging

DNS-cachevergiftiging is een klassieke aanval waarbij de identiteit wordt misbruikt: de aanvaller doet zich voor als een legitiem domein en misleidt gebruikers zodat ze op een frauduleuze site terechtkomen. Dit werkt vooral goed omdat het traditionele DNS nooit is ontworpen met het oog op cryptografische validatie, waardoor er standaard niets is dat onjuiste gegevens in de cache filtert. Zonder DNSSEC hebben resolvers simpelweg geen manier om een legitiem antwoord te onderscheiden van een vervalst antwoord.

Dit is waarom dat belangrijk is:

1. Merkvertrouwen en klantvertrouwen

Wanneer klanten van uw legitieme domein worden omgeleid naar een vals domein, geven ze niet de DNS de schuld, maar u. Die associatie kan het vertrouwen in de loop van de tijd stilletjes ondermijnen, en de schade is des te groter in sectoren als de financiële sector, de gezondheidszorg, het onderwijs, de detailhandel en de overheid, waar de integriteit van het domein rechtstreeks verband houdt met klantrelaties en de naleving van regelgeving.

2. Verspreiding van malware

Zodra gebruikers, medewerkers of geautomatiseerde systemen op een door een aanvaller gecontroleerde bestemming terechtkomen, volgt er vaak malware. Van daaruit kan deze zich verspreiden over eindpunten en netwerken en in het geheim gevoelige gegevens wegsluizen, waaronder intellectueel eigendom, klantgegevens en financiële informatie, gevoelige informatie waarvan het verlies hoge kosten met zich meebrengt.

3. Diefstal van inloggegevens en financiële fraude

Frauduleuze websites zijn bedoeld om gegevens te verzamelen. Wachtwoorden, bankgegevens gegevens, bedrijfsinloggegevens: alles wat gebruikers invoeren, wordt verzameld. Van daaruit is het een korte weg naar het misbruik van accounts, ongeautoriseerde transacties en fraude die uiteindelijk gericht is tegen de organisatie of haar klanten.

4. Verstoring van de e-mail- en domeinbeveiliging

DNS-records vormen de basis waarop e-mailverificatie is gebouwd. Wanneer DNS-gegevens dus ongeautoriseerd of onjuist zijn, blijft dit niet beperkt tot die gegevens alleen. Het heeft een domino-effect op SPF-, DKIM-, DMARC-, BIMI-, MTA-STS- en TLS-RPT-records, wat leidt tot lacunes in het inzicht, problemen met de afleverbaarheid, het risico op spoofing en nalevingsrisico’s. Zodra de integriteit van het DNS-systeem wordt aangetast, wordt de gehele keten van e-mailverificatie onbetrouwbaar.

5. Gevolgen voor naleving en incidentrespons

Voor organisaties die moeten voldoen aan PCI DSS, de AVG, HIPAA of overheidsrichtlijnen op het gebied van cyberbeveiliging, kan een incident met DNS-vergiftiging leiden tot reële risico’s op het gebied van regelgeving. Bovendien neemt de werklast bij het reageren op dergelijke incidenten niet geleidelijk toe. Wanneer vergiftigde DNS-records tegelijkertijd meerdere domeinen, diensten of klantomgevingen raken, wordt het opruimen al snel een ingewikkelde aangelegenheid.

Waarom DNS-cachevergiftiging belangrijk is voor MSP’s en MSSP’s

Voor MSP’s en MSSP’s die meerdere klantdomeinen beheren, kunnen DNS-gerelateerde aanvallen en verkeerde configuraties al snel tot hoge operationele kosten leiden. Eén enkel besmet of verkeerd geconfigureerd domein kan al aanleiding geven tot supporttickets, klachten over de bezorging van e-mails, zorgen over phishing en vertrouwenskwesties bij klanten binnen de gehele beheerde portefeuille. Dankzij gecentraliseerde domeinmonitoring, rapportage over authenticatie en op rollen gebaseerde toegang kunnen dienstverleners problemen sneller opsporen en klantdomeinen beheren zonder te hoeven schakelen tussen losstaande tools.

Praktijkvoorbeelden van DNS-vergiftigingsaanvallen

Er zijn DNS-vergiftigingsaanvallen waargenomen in diverse sectoren en in verschillende aanvalsscenario’s. De volgende voorbeelden illustreren veelvoorkomende patronen, gevolgen en geleerde lessen:

Hoe DNS-cachevergiftiging te detecteren

De meeste mensen die door een besmette DNS-cache worden omgeleid, merken daar niets van. Daarom is dit aan de gebruikerskant moeilijk op te sporen, dus is het meestal aan degene die de infrastructuur in de gaten houdt om dit te detecteren. Een paar zaken om op te letten:

• Onverwachte omleidingen op websites. Iemand typt een domeinnaam in die hij of zij altijd bezoekt en komt op een onbekende plek terecht.
• Waarschuwingen over niet-overeenkomende SSL/TLS-certificaten. Als de browser een certificaatfoutmelding geeft, negeer deze dan niet. Dit betekent meestal dat de verbinding niet terechtkomt waar deze hoort te komen.
• Vervalste inlogpagina’s. Op het eerste gezicht ziet de pagina er prima uit, maar de URL, het ontwerp of de certificaatgegevens kloppen niet helemaal. Het loont de moeite om er elke keer nog eens goed naar te kijken.
• DNS-antwoorden die per resolver verschillen. Vraag hetzelfde domein op via de resolver van uw bedrijf en vervolgens via een openbare resolver, bijvoorbeeld 1.1.1.1 of 8.8.8.8. Als de antwoorden verschillen, is er iets mis.
• Ongewone vermeldingen in DNS-logbestanden. Vreemde TTL-waarden, responsbronnen die niet aan de verwachtingen voldoen, of een plotselinge piek in het aantal verzoeken voor één bepaald domein.
• Verkeer dat zonder duidelijke reden afneemt. Als de statistieken of de succespercentages bij authenticatie dalen en er geen duidelijke oorzaak is, is het de moeite waard om DNS te controleren voordat u dit uitsluit.
• Waarschuwingen uit uw beveiligingsstack. Als SIEM-, EDR- of netwerkmonitoringtools DNS-activiteit of verbindingen met bekende schadelijke IP-bereiken signaleren, mag u daar niet zomaar op zitten blijven.
• Afwijkingen in DMARC-rapporten. Een piek in het aantal mislukte authenticaties kan erop wijzen dat er geknoeid is met de SPF-, DKIM- of DMARC-records die aan uw domein zijn gekoppeld.

Wat te doen als je DNS-cachevergiftiging vermoedt

Begin met het vergelijken van DNS-antwoorden van verschillende resolvers, met behulp van de PowerDMARC DNS Record Checker of command-line tools zoals nslookup en dig. Vervolgens:

1. Leeg de DNS-cache op de betrokken systemen. Windows: ipconfig /flushdns. macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder. Linux: sudo systemd-resolve –flush-caches.
2. Schakel over naar een betrouwbare recursieve resolver, zoals 1.1.1.1 of 8.8.8.8, terwijl u uw primaire resolver onderzoekt.
3. Controleer de DNS-records voor elk cruciaal domein, met name die welke SPF, DKIM, DMARC, MTA-STS, TLS-RPT en BIMI ondersteunen, met behulp van de PowerDMARC Domain Analyzer.
4. Controleer de DNSSEC-validatiestatus van uw domeinen met behulp van de PowerDMARC DNSSEC Checker.
5. Controleer de geaggregeerde DMARC-rapporten op afwijkingen in de authenticatie die zouden kunnen wijzen op een storing op DNS-niveau.
6. Breng de betrokken gebruikers en belanghebbenden op de hoogte als het incident gepaard ging met het openbaar worden van inloggegevens of kwaadwillige omleidingen die verband hielden met uw domein.

Strategieën ter voorkoming en beperking van DNS-vergiftiging

1. Implementeer DNSSEC waar dit wordt ondersteund

DNSSEC voegt cryptografische handtekeningen toe aan DNS-records, zodat resolvers kunnen controleren of een antwoord daadwerkelijk afkomstig is van de juiste gezaghebbende bron en onderweg niet is gemanipuleerd. DNS zelf verifieert de antwoorden nog steeds niet, maar DNSSEC vult die leemte op en zorgt ervoor dat vervalste antwoorden veel minder snel door de mazen van het net glippen. Je kunt je eigen configuratie controleren met behulp van de PowerDMARC DNSSEC Checker.

2. Zorg ervoor dat DNS-resolvers en de infrastructuur up-to-date blijven

Bekende DNS-kwetsbaarheden worden voortdurend misbruikt, dus up-to-date blijven is belangrijker dan het op het eerste gezicht lijkt. Regelmatig patchbeheer, configuratiecontroles en het gebruik van gerenommeerde, goed onderhouden recursieve resolvers verkleinen allemaal het aanvalsoppervlak. Twee instellingen die het waard zijn om nog eens extra te controleren: willekeurige toewijzing van bronpoorten en entropie van query-ID’s. Beide maken het aanzienlijk moeilijker om transactie-ID’s te raden.

3. Gebruik betrouwbare recursieve resolvers

Stel eindpunten en netwerken in op beveiligingsgerichte DNS-resolvers zoals Cloudflare (1.1.1.1), Google (8.8.8.8) of Quad9 (9.9.9.9). Deze aanbieders voeren DNSSEC-validatie uit, ondersteunen versleutelde DNS-protocollen (DoH en DoT) en filteren actief domeinen die bekend staan als schadelijk, waardoor een groot deel van het risico wordt weggenomen zonder dat dit u extra moeite kost.

4. Problemen met verkeerd geconfigureerde of verlaten DNS-records oplossen

Verouderde of verkeerd geconfigureerde DNS-records, zoals losstaande DNS-vermeldingen vermeldingen, creëren kwetsbaarheden die aanvallers graag misbruiken, waaronder het overnemen van subdomeinen, wat de risico's die cache poisoning al met zich meebrengt alleen maar vergroot. Regelmatige controles van uw DNS-records met behulp van de PowerDMARC DNS Record Checker helpen hier enorm.

5. E-mailauthenticatiegegevens controleren en versterken

SPF, DKIM, DMARC, BIMI, MTA-STS en TLS-RPT zijn allemaal afhankelijk van DNS om te kunnen functioneren. Eén onbevoegde wijziging in uw DNS-zone kan de e-mailauthenticatie ongemerkt verstoren zonder dat er een duidelijke waarschuwing wordt gegeven. Juist daarom moet dit een doorlopende controle zijn in plaats van een eenmalige instelling. De PowerDMARC Domain Analyzer is ontwikkeld om uw volledige authenticatiestatus in één keer te controleren.

6. De beveiliging van e-mailverkeer versterken met MTA-STS en TLS-RPT

MTA-STS vereist dat verzendende mailservers TLS gebruiken bij het bezorgen van e-mail aan uw domein. Het voorkomt DNS-cachevergiftiging niet direct, maar het vermindert wel het risico op downgrade-aanvallen die vaak gepaard gaan met gecompromitteerde DNS. Combineer het met TLS-RPT en u krijgt inzicht in bezorgfouten op de transportlaag en beleidsschendingen. Dit blijkt een nuttig signaal te zijn wanneer u probeert vast te stellen of DNS de oorzaak is van een e-mailstoring.

7. Update van de beveiligingssoftware voor eindpunten

Als een eindpunt door DNS-vergiftiging al op een schadelijke website terecht is gekomen, moet u snel handelen. Werk de antivirus- en eindpuntbeveiligingssoftware bij en voer vervolgens een volledige scan uit om alles op te sporen en te verwijderen wat zich mogelijk heeft geïnstalleerd. Dit is van nature een reactieve maatregel, maar het is een noodzakelijke stap voor eindgebruikers en IT-teams die reageren op een actief incident.

Naast deze strategieën is het handig om een aantal betrouwbare DNS- en domeinanalysetools bij de hand te hebben voor doorlopende controle. De toolkit van PowerDMARC biedt hiervoor de nodige ondersteuning met de DNS Record Checker, DNSSEC Checker, Domain Analyzer, MTA-STS Checkeren de TLS-RPT Checker.

Hoe PowerDMARC bijdraagt aan het versterken van de domein- en e-mailbeveiliging

DNS-beveiliging en e-mailverificatie zijn nauw met elkaar verbonden. SPF, DKIM, DMARC, BIMI, MTA-STS en TLS-RPT zijn allemaal afhankelijk van nauwkeurige, betrouwbare DNS-records. Als deze records ontbreken, verkeerd zijn geconfigureerd of moeilijk te controleren zijn, lopen organisaties een verhoogd risico op spoofing, bezorgingsproblemen en nalevingsrisico's, die allemaal worden versterkt wanneer de integriteit van het DNS-systeem in het gedrang komt.

PowerDMARC biedt beveiligingsteams en MSP’s een gecentraliseerd platform voor het beheer van e-mailauthenticatie over verschillende domeinen heen. Het platform biedt duidelijke rapportages, snelle probleemdetectie, gehoste authenticatiediensten en tools om het beheer van DNS-gebaseerde protocollen te vereenvoudigen, zonder dat er bij elke update handmatige DNS-wijzigingen nodig zijn.

• DMARC-monitoring en -rapportage: inzicht in verzendbronnen, authenticatiefouten en pogingen tot spoofing, inclusief afwijkingen die kunnen wijzen op een storing op DNS-niveau.
• Gehoste SPF en geautomatiseerd SPF-beheer: lost problemen met de limiet voor SPF-opzoekingen op en vermindert de noodzaak van handmatige DNS-wijzigingen bij het toevoegen van nieuwe verzendbronnen.
• MTA-STS en TLS-RPTin de cloud: versterkt de beveiliging van e-mailverkeer en biedt rapportagemogelijkheden over TLS bezorgingsfouten en beleidsproblemen.
• Hosted BIMI: Draagt bij aan het vergroten van het vertrouwen in het merk en de herkenbaarheid in de inbox door het beheer van BIMI-records en certificaatvereisten.
• Domeingroepering en op rollen gebaseerde toegang: onmisbaar voor ondernemingen en MSP’s die meerdere domeinen of klantenportefeuilles vanaf één platform beheren.
• Door AI aangestuurde dreigingsinformatie: identificeert spoofingpatronen, ongeautoriseerde afzenders en afwijkingen in de authenticatie aan de hand van realtime gegevens uit het wereldwijde klantenbestand van PowerDMARC.

PowerDMARC biedt bovendien deskundige wereldwijde ondersteuning om beveiligingsteams, beheerders en MSP’s te helpen bij het met vertrouwen configureren, monitoren en oplossen van problemen met authenticatierecords. 

Start je gratis proefperiode van 15 dagen en krijg een duidelijker beeld van de e-mailverificatiestatus van uw domein.

Veelgestelde vragen over DNS-cachevergiftiging

Hoe detecteer je DNS-vergiftiging?

Let op onverwachte omleidingen op websites, waarschuwingen over SSL/TLS-certificaten, inconsistente DNS-antwoorden bij verschillende resolvers, ongebruikelijke DNS-logboekvermeldingen en afwijkingen in de geaggregeerde DMARC-rapporten. Door de zoekresultaten te vergelijken met de PowerDMARC DNS Record Checker of command-line-tools zoals dig en nslookup, kun je snel vaststellen of een resolver een onverwacht IP-adres retourneert.

Wat is een praktijkvoorbeeld van DNS-vergiftiging?

Een veelvoorkomend patroon richt zich op gebruikers van cryptovaluta-beurzen: aanvallers manipuleren een DNS-resolver en leiden hen om naar een visueel identieke phishing-site die inloggegevens en toegang tot wallets verzamelt. Een ander patroon is manipulatie op ISP-niveau, waarbij resolvers vervalste antwoorden invoegen om gebruikers onopgemerkt om te leiden naar advertentie- of waarschuwingspagina’s.

Wat is het verschil tussen DNS-vergiftiging en DNS-spoofing?

Bij DNS-cachevergiftiging worden vervalste records in de cache van een resolver geïnjecteerd, zodat zoekopdrachten schadelijke resultaten opleveren totdat de TTL is verstreken. DNS-spoofing is de bredere categorie, die naast cachevergiftiging ook andere methoden omvat, zoals het onderscheppen van DNS-verkeer via een man-in-the-middle-aanval. In de praktijk worden de twee termen door elkaar gebruikt.

Kan DNSSEC DNS-vergiftiging voorkomen?

Ja, mits het volledig is geïmplementeerd en van begin tot eind is gevalideerd. DNSSEC voegt cryptografische handtekeningen toe aan DNS-records, zodat resolvers die deze handtekeningen valideren, vervalste antwoorden kunnen opsporen en afwijzen. Dit werkt alleen als zowel de domeineigenaar de zone-records ondertekent als de resolver deze valideert. Een onvolledige of verkeerd geconfigureerde implementatie kan een vals gevoel van veiligheid geven.

Voorkomt MTA-STS DNS-cachevergiftiging?

Nee. MTA-STS dwingt TLS-versleuteling af voor de bezorging van e-mail en vermindert het risico op downgrade-aanvallen, maar biedt geen directe bescherming tegen DNS-cachepoisoning. In combinatie met TLS-RPT biedt het rapportage over bezorgingsfouten op transportniveau. Beschouw het als een aanvullende beveiligingsmaatregel voor de veiligheid van e-mailtransport, niet als een verdedigingsmechanisme tegen DNS-aanvallen.

Waarom is DNS-beveiliging belangrijk voor e-mailverificatie?

SPF, DKIM, DMARC, BIMI, MTA-STS en TLS-RPT zijn allemaal afhankelijk van DNS-records om te kunnen functioneren. Als een aanvaller DNS-antwoorden kan manipuleren, kunnen deze beveiligingsmaatregelen worden uitgeschakeld of omzeild, waardoor de deur wordt opengezet voor spoofing, phishing en problemen met de afleverbaarheid. De integriteit van het DNS-systeem vormt de basis voor effectief beheer van e-mailbeveiliging.

• Over
• Laatste berichten

Ahona Rudra

Expert op het gebied van domein- en e-mailbeveiliging bij PowerDMARC

Ahona is marketingmanager bij PowerDMARC en heeft meer dan vijf jaar ervaring met het schrijven over cybersecurity, gespecialiseerd in domein- en e-mailbeveiliging. Ahona heeft een masterdiploma in journalistiek en communicatie, en heeft sinds 2019 haar carrière in de beveiligingssector verder uitgebouwd.

Laatste berichten van Ahona Rudra (Bekijk alle berichten)

• SSL- versus TLS-protocollen: wat is het verschil? - 13 augustus 2026
• Wat is URL-manipulatie (URL-herschrijving)? Hoe aanvallers betrouwbare links kapen om phishing te verbergen - 10 augustus 2026
• Beveiligingswaarschuwing via e-mail voor Microsoft-accounts: hoe u oplichting kunt herkennen en uw domein kunt beschermen - 9 augustus 2026