Wat is een Replay Attack?
Een Replay Attack (replay-aanval) is een aanval waarbij een aanvaller legitieme communicatie onderschept, opslaat en later ongewijzigd opnieuw verstuurt, zodat de ontvanger een oud maar geldig bericht uitvoert alsof het nieuw is. De aanvaller hoeft het bericht niet te begrijpen of te kraken: het volstaat dat het ooit echt was. In OT-netwerken kan dat leiden tot onbedoelde besturing van machines, misleiding van SCADA-schermen of foutieve procesdata in de Historian.
NIST omschrijft een replay-aanval als een aanval waarbij de aanvaller eerder opgevangen berichten tussen een legitieme partij en een verificateur opnieuw afspeelt, om zich als een van beide voor te doen. In de industrie gaat het vaak niet om inloggegevens, maar om stuurcommando’s en meetwaarden.
🧠 Hoe verloopt een replay-aanval?
Een replay-aanval bestaat meestal uit drie stappen:
- Opvangen - de aanvaller krijgt toegang tot het netwerk, bijvoorbeeld via een geïnfecteerde engineeringwerkplek, een man-in-the-middle-positie of een gespiegelde switchpoort, en neemt verkeer op met een tool als Wireshark.
- Selecteren - hij zoekt het bericht dat het gewenste effect heeft, zoals een schrijfopdracht naar een register, een start- of stopcommando of een geldige aanmelding.
- Afspelen - op een zelfgekozen moment stuurt hij het bericht opnieuw. Omdat inhoud, adressen en eventuele handtekening kloppen, voert de ontvanger het uit.
Replay verschilt van spoofing: bij spoofing maakt de aanvaller zelf een vervalst bericht, bij replay hergebruikt hij een echt bericht. Bij session hijacking neemt hij een lopende sessie over in plaats van losse berichten te herhalen.
| Scenario | Gevolg van replay |
|---|---|
| Aanvaller herhaalt een eerder “open klep”-commando | Klep opent opnieuw, buiten het bedoelde moment |
| Oude, normale sensorwaarden worden opnieuw verzonden | SCADA en HMI tonen een rustig proces terwijl er iets misgaat |
| Opgenomen schrijfopdrachten naar een PLC worden herhaald | Setpoints of productieparameters veranderen zonder operator |
| Een geldige aanmelding of token wordt opnieuw aangeboden | Toegang tot een systeem zonder kennis van het wachtwoord |
| Een oudere, wel correct ondertekende firmware wordt opnieuw aangeboden | Bekende kwetsbaarheden keren terug (downgrade) |
🏭 Welke bekende voorbeelden zijn er in OT?
Het bekendste voorbeeld is Stuxnet. De oudere variant, gericht op het cascadebeveiligingssysteem van de centrifuges in Natanz, nam ongeveer 21 seconden aan normale proceswaarden op en speelde die tijdens de aanval in een lus af. De besturing en de operators zagen daardoor een stabiel proces, terwijl de druk in de centrifuges opliep.
Ook bij Siemens-besturingen speelt replay een rol. Het protocol S7 Comm van oudere S7-300/400-PLC’s heeft geen enkele bescherming, zodat opgenomen start-, stop- en schrijfopdrachten gewoon herhaald kunnen worden. S7 Comm Plus in de S7-1200 en S7-1500 kreeg een anti-replaymechanisme, dat sinds firmware 4.0 van de S7-1200 en in de S7-1500 wordt gebruikt. Toch lieten onderzoekers in 2017 op Black Hat Europe zien dat zij die bescherming op een S7-1200 met firmware 4.1 konden omzeilen: met opgenomen en nagebootste berichten konden zij de PLC op afstand starten en stoppen en uitgangen wijzigen. In 2019 volgde op Black Hat USA het Rogue7-onderzoek, waarin een nagebootst engineeringstation opdrachten naar S7-1500-PLC’s stuurde.
🔍 Waarom zijn OT-protocollen kwetsbaar?
- Geen authenticatie of integriteitscontrole - klassieke protocollen als Modbus, Modbus TCP, DNP3 zonder Secure Authentication en basis-GOOSE controleren niet wie een bericht stuurt
- Geen versheidsinformatie - zonder tijdstempel, volgnummer of nonce kan een ontvanger een origineel niet van een kopie onderscheiden
- Leesbaar verkeer - data is meestal niet versleuteld, zodat een aanvaller precies ziet welk bericht wat doet
- Ontwerp voor beschikbaarheid - legacysystemen zijn gebouwd om opdrachten snel en betrouwbaar uit te voeren, niet om de herkomst te betwijfelen
- Lange levensduur - besturingen draaien vaak twintig jaar of langer, waardoor onbeveiligde protocollen lang in gebruik blijven
🔐 Welke maatregelen beschermen tegen replay?
Bescherming tegen replay vraagt altijd twee dingen: het bericht moet echt zijn (integriteit en authenticatie) en het moet vers zijn (eenmalig of binnen een tijdvenster). Een handtekening alleen is niet genoeg: een correct ondertekend oud bericht blijft correct ondertekend.
| Mechanisme | Werking | Voorbeeld in de praktijk |
|---|---|---|
| Message Authentication Code (MAC/HMAC) | Cryptografische controlewaarde met een gedeelde sleutel bewijst echtheid en ongewijzigde inhoud | GOOSE met IEC 62351-6, DNP3 Secure Authentication |
| Volgnummer (sequence number) | Ontvanger weigert berichten met een nummer dat al gezien of te oud is | TLS-records, OPC UA SecureChannel |
| Tijdstempel met tijdvenster | Berichten buiten een toegestane klokafwijking worden geweigerd | Kerberos, standaard 5 minuten tolerantie |
| Nonce / challenge-response | Ontvanger stuurt een willekeurige uitdaging die het antwoord eenmalig maakt | DNP3 SAv5 challenge, TLS-handshake |
| Sessiesleutels | Elk verbindingsmoment krijgt nieuwe sleutels, oude berichten passen niet meer | TLS, OPC UA-sessies |
| Versie- en rollbackcontrole | Apparaat weigert firmware ouder dan de geïnstalleerde versie | Code Signing met anti-rollback, secure boot |
Tijdstempels werken alleen als klokken kloppen. Synchroniseer apparaten daarom met beveiligde NTP of PTP: wie de klok kan verzetten, kan een oud bericht weer “geldig” laten lijken.
🔧 Hoe beveiligen moderne industriële protocollen zich?
| Protocol | Replay-bescherming | Aandachtspunt |
|---|---|---|
| OPC UA | Ondertekende berichten met tijdstempels, volgnummers en request-ID’s; ook bij het opzetten van sessies | Alleen met SecurityMode Sign of SignAndEncrypt; None biedt niets |
| OPC UA PubSub | Publisher-ID, tijdstempel, berichtnummer en volgnummer | Uitschakelen van die velden maakt replay weer mogelijk |
| DNP3 Secure Authentication v5 | Challenge-response met HMAC, vastgelegd in IEEE 1815-2012 en gebaseerd op IEC/TS 62351-5 | Authenticeert, maar versleutelt niet |
| GOOSE / IEC 61850 | HMAC via IEC 62351-6; stNum/sqNum alleen met die HMAC betrouwbaar | Veel geïnstalleerde IED’s ondersteunen IEC 62351-6 nog niet |
| Modbus/TCP Security | Modbus TCP binnen TLS met wederzijdse certificaten | Vereist apparatuur die het ondersteunt |
| TLS 1.3 | Volgnummers en sessiesleutels per verbinding | De 0-RTT-modus is replaybaar; niet gebruiken voor stuuropdrachten |
Kies bij nieuwe installaties waar mogelijk voor OPC UA in plaats van OPC Classic, dat voor zijn beveiliging volledig afhankelijk is van DCOM en in de praktijk vaak met minimale beveiligingsinstellingen draait.
🧪 Hoe herkent u een replay-aanval?
| Signaal | Detectiemethode |
|---|---|
| Herhaald commando zonder aanleiding in proces of bediening | Anomaliedetectie, IDS met protocolkennis |
| Meetwaarden die exact een eerder patroon herhalen | Trendanalyse in de Historian, vergelijking met redundante sensoren |
| Identieke pakketten met dezelfde inhoud op een ander moment | Pakketanalyse met Wireshark, inclusief tijdsvergelijking |
| Sprong of terugval in volgnummers (bijvoorbeeld stNum bij GOOSE) | OT-IDS met kennis van IEC 61850 |
| Schrijfopdrachten vanaf een onbekend of ongebruikelijk systeem | Logging van alle commando’s met tijdstempel in de SIEM |
Let op: herhaalde berichten zijn in OT niet altijd verdacht. GOOSE herhaalt elk bericht bewust, en pollende SCADA-systemen lezen elke seconde dezelfde registers. Detectie werkt daarom het best met een baseline van normaal verkeer.
🏗️ Welke aanpak werkt in een bestaande installatie?
Veel installaties kunnen hun protocollen niet op korte termijn vervangen. Een praktische volgorde is:
- Inventariseer welke protocollen stuuropdrachten zonder authenticatie vervoeren, en welke apparaten al beveiligde varianten ondersteunen.
- Segmenteer volgens netwerksegmentatie en het zones-en-conduitsmodel, zodat een aanvaller minder plekken heeft om verkeer op te vangen.
- Beperk schrijfrechten - sta schrijfopdrachten alleen toe vanaf vaste engineering- en SCADA-systemen, bijvoorbeeld met een industriële firewall en deep packet inspection.
- Schakel beveiligde varianten in waar apparatuur het ondersteunt: OPC UA met SignAndEncrypt, DNP3 Secure Authentication, IEC 62351-6 voor GOOSE.
- Bewaak met een OT-IDS en log commando’s centraal, zodat afwijkende herhalingen opvallen.
- Leg eisen vast bij inkoop: IEC 62443-3-3 vraagt met SR 3.1 om integriteit van communicatie, met cryptografische bescherming als uitbreiding vanaf security level 3.
Voor Nederlandse organisaties is dit geen vrijblijvende keuze. De Cyberbeveiligingswet, van kracht sinds 15 augustus 2026, verplicht essentiële en belangrijke entiteiten tot passende maatregelen voor hun netwerken. De Cyber Resilience Act eist dat fabrikanten van producten met digitale elementen de integriteit van verzonden data en commando’s beschermen; die eisen gelden volledig vanaf 11 december 2027. Ook een Zero Trust Architecture helpt: vertrouw geen bericht alleen op basis van het IP-adres waar het vandaan komt.
❓ Veelgestelde vragen
Wat is het verschil tussen een replay-aanval en een man-in-the-middle-aanval?
Bij een man-in-the-middle-aanval zit de aanvaller live tussen twee partijen en kan hij berichten lezen, wijzigen of tegenhouden. Bij een replay-aanval verstuurt de aanvaller een eerder opgevangen, ongewijzigd bericht opnieuw. Een man-in-the-middle-positie wordt vaak gebruikt om het verkeer voor een latere replay-aanval op te nemen.
Beschermt versleuteling tegen een replay-aanval?
Versleuteling alleen beschermt niet tegen een replay-aanval, omdat een versleuteld bericht ook versleuteld opnieuw kan worden afgespeeld. Pas in combinatie met volgnummers, tijdstempels, nonces of sessiesleutels herkent de ontvanger een herhaling. Protocollen als TLS en OPC UA combineren die mechanismen.
Is Modbus gevoelig voor replay-aanvallen?
Standaard Modbus is zeer gevoelig voor replay-aanvallen, omdat het geen authenticatie, geen integriteitscontrole en geen versheidsinformatie heeft. Een opgenomen schrijfopdracht naar een register kan zonder meer opnieuw worden verstuurd. Modbus/TCP Security, dat Modbus TCP binnen TLS transporteert, lost dat op voor apparatuur die het ondersteunt.
Wat is een nonce?
Een nonce is een willekeurig of eenmalig getal dat in een bericht of handshake wordt gebruikt en maar één keer geldig is. Omdat de ontvanger bijhoudt welke nonces al gebruikt zijn, of zelf een nieuwe uitdaging stuurt, faalt een replay-aanval met een oud bericht. Nonces worden onder meer in TLS en DNP3 Secure Authentication gebruikt.
Waarom speelt tijdsynchronisatie een rol bij replay-aanvallen?
Veel replay-bescherming gebruikt tijdstempels met een toegestaan tijdvenster, zoals de standaardtolerantie van 5 minuten bij Kerberos. Als een aanvaller de klok van een apparaat kan verzetten via onbeveiligde NTP, kan een oud bericht weer binnen dat venster vallen. Beveiligde tijdsynchronisatie is daarom onderdeel van de verdediging tegen replay-aanvallen.
Kan een IDS een replay-aanval in OT detecteren?
Een OT-IDS met protocolkennis kan een replay-aanval detecteren door commando’s te herkennen die op een ongebruikelijk moment, vanaf een onbekend systeem of zonder procesaanleiding verschijnen. Omdat OT-verkeer van nature repetitief is, heeft de IDS een baseline van normaal gedrag nodig. Detectie vult preventieve maatregelen zoals authenticatie en volgnummers aan, maar vervangt ze niet.
📌 Samengevat
Een replay-aanval misbruikt het feit dat veel OT-protocollen niet controleren of een bericht echt én nieuw is. Bescherming vraagt om authenticatie plus versheid via volgnummers, tijdstempels of nonces, aangevuld met segmentatie, beperkte schrijfrechten en monitoring van commando’s.
