# DDoS of hackeraanval? Aanvallen juist inschatten

> DDoS of hackeraanval? Typische tekenen vergeleken, eerste controleopdrachten voor de server en wat u in de eerste uren concreet moet doen.

Bron: https://phpsos.de/nl/ratgeber/ddos-oder-exploit/  
Stand: 25-10-2026  
Aanbieder: PHP SOS, PHP-noodhulp en serverbeveiliging. Directe hulp via WhatsApp: https://wa.me/491736494914?text=Hallo%20PHP%20SOS%2C%20wij%20hebben%20hulp%20nodig%20met%20onze%20PHP-server.%20Bedrijf%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6

**Kort gezegd:** Of het om DDoS of een hackeraanval gaat, blijkt uit de sporen. Een DDoS veroorzaakt zeer veel verzoeken en maakt de website traag of onbereikbaar, maar wijzigt niets. Een exploit heeft vaak maar weinig verzoeken nodig en laat nieuwe bestanden, accounts, processen of verbindingen achter. De juiste inschatting bepaalt of u belasting moet afweren of een incident moet indammen.

## Het verschil in eenvoudige woorden

Een **DDoS-aanval** (distributed denial of service) is als een mensenmassa die de ingang van een winkel blokkeert. Niemand komt binnen, maar in de winkel wordt niets gestolen. Doel is uw website of server te overbelasten, zodat echte klanten er niet meer doorheen komen.

Een **exploit** is daarentegen een inbraak door een openstaande deur. De aanvaller gebruikt een zwakke plek, bijvoorbeeld in PHP, in het CMS of in een extensie, om code op uw server uit te voeren. Dat kan geruisloos gebeuren, zonder dat de website trager wordt. De gevolgen lopen uiteen van spampagina's via gegevensdiefstal tot overname van de server.

Voor de directie is het verschil beslissend: een DDoS is een beschikbaarheidsprobleem dat met de aanval eindigt. Een geslaagde exploit is een beveiligingsincident dat blijft totdat het is gevonden, opgeruimd en gedocumenteerd.

## DDoS of hackeraanval: de tekenen vergeleken

De volgende tabel helpt bij de eerste inschatting. Ze vervangt geen analyse, maar toont waar u eerst moet kijken.

| Kenmerk | Eerder DDoS | Eerder exploit of inbraak |
|---|---|---|
| Bereikbaarheid | traag of uitgevallen | vaak normaal |
| Verzoeken in het log | zeer veel, vaak eenvormig | weinig, gerichte verzoeken |
| Bestanden | ongewijzigd | nieuwe of gewijzigde PHP-bestanden |
| Accounts | ongewijzigd | nieuwe beheerders, gewijzigde wachtwoorden |
| Processen | webserver en PHP onder vollast | onbekende processen, mining, spamverzending |
| Netwerk | veel inkomend verkeer | ongebruikelijke uitgaande verbindingen |
| Na het einde | alles zoals voorheen | sporen blijven bestaan |

Let op bij overlappingen: massaal scannen naar een kwetsbaarheid kan eruitzien als een kleine DDoS. Precies dat was rond PHP2Shell te verwachten, toen aanvallers naar kwetsbare servers zochten. Hoge belasting kan dus ook betekenen dat iemand op dat moment probeert in te breken.

## Eerste controles op de server

De volgende opdrachten wijzigen niets aan het systeem en geven een snel overzicht. Zet bij verdenking van een inbraak de logs veilig voordat u grotere ingrepen doet.

```bash
# Belasting en looptijd
uptime

# Verbindingen samengevat en de meest voorkomende tegenstations
ss -s
ss -tn state established | awk 'NR>1 {print $4}' | cut -d: -f1 | sort | uniq -c | sort -rn | head

# Meest voorkomende clientadressen in het toegangslog (pad aanpassen)
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

# PHP-bestanden die in de afgelopen 7 dagen zijn gewijzigd
find /var/www -type f -name '*.php' -mtime -7 -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort

# Processen met de hoogste CPU-belasting
ps aux --sort=-%cpu | head -15
```

In het verbindingsoverzicht toont de vierde kolom het tegenstation. Veel verbindingen van weinig adressen of een stijging tot een veelvoud van de normale waarde wijzen op overbelasting. Nieuwe PHP-bestanden in upload- of cachemappen, processen onder de webservergebruiker met vreemde namen of uitgaande verbindingen naar onbekende bestemmingen wijzen eerder op een inbraak. Een uitgebreide lijst vindt u onder [Tekenen van compromittering na PHP2Shell](https://phpsos.de/nl/php2shell/bin-ich-gehackt-anzeichen/).

## Waarom hoge belasting ook een afleidingsmanoeuvre kan zijn

Het komt voor dat aanvallers een overbelasting veroorzaken terwijl ze tegelijk gericht inbreken. Het team is dan bezig met de bereikbaarheid en de eigenlijke sporen verdwijnen in de logruis. Daarom geldt: ook als een DDoS duidelijk is, controleert u na afloop bestanden, accounts en uitgaande verbindingen.

In het geval van PHP2Shell komt erbij dat er volgens php.net en de beveiligingsbedrijven geen gepubliceerde, bevestigde Indicators of Compromise zijn. De detectie berust op gedragsanalyse. Een server die tijdens de scanperiode vanaf half oktober ongepatcht was, moet daarom ongeacht de waargenomen belasting worden gecontroleerd.

Een andere variant zijn chantagemails waarin met een DDoS-aanval wordt gedreigd als er niet wordt betaald. Bewaar zulke berichten, betaal niet zonder overleg met vakmensen en overweeg een [aangifte bij de Zentrale Ansprechstelle Cybercrime (het centrale contactpunt voor cybercriminaliteit van de Duitse politie)](https://phpsos.de/nl/compliance/anzeige-polizei-zac/). Informeer tegelijk uw hoster, zodat beschermmaatregelen kunnen worden voorbereid. Hoe u de logs daarvoor analyseert, staat in de gids [Webserverlogs na een aanval analyseren](https://phpsos.de/nl/ratgeber/logfiles-auswerten/).

## Wat u in de eerste uren moet doen

**Bij verdenking van DDoS:**

- Hoster of datacenter informeren; daar zijn vaak filters vóór de server aanwezig.
- Een voorgeschakelde beschermdienst of een [WAF met virtuele patching](https://phpsos.de/nl/leistungen/waf-virtuelles-patching/) activeren of aanscherpen.
- Rate limits in de webserver instellen en dure pagina's zoals zoeken of winkelmandje extra beschermen.
- Logs bewaren, zodat de aanval later na te gaan is.

**Bij verdenking van een inbraak:**

- Niets verwijderen en de server niet opnieuw opzetten voordat logs en getroffen bestanden zijn veiliggesteld.
- PHP naar een verholpen versie bijwerken en alle workers herstarten, als dat nog niet is gebeurd.
- Als de update niet direct mogelijk is, de website tijdelijk van het netwerk halen, zoals het BSI (de Duitse federale dienst voor informatiebeveiliging) adviseert.
- Toegangsgegevens vernieuwen vanaf een schoon apparaat, niet vanaf de mogelijk getroffen server.
- Laten controleren of persoonsgegevens getroffen kunnen zijn; dan kunnen meldtermijnen lopen.

In beide gevallen helpt een korte, zakelijke notitie voor hoster en dienstverleners: sinds wanneer het probleem bestaat, welke websites zijn getroffen, wat u hebt waargenomen en wat er al is gewijzigd. Leg bovendien vast wie welke beslissing heeft genomen. Deze tijdlijn bespaart tijd bij de analyse en is later waardevol voor verzekering, gegevensbescherming en interne nabespreking. Is onduidelijk of er wel een aanval is, behandel de situatie dan voorzorgshalve als incident totdat het tegendeel is aangetoond.

## Hoe helpt PHP SOS concreet?

- We schatten de situatie op afstand in aan de hand van belasting, logs, bestanden en verbindingen en zeggen u waarmee u waarschijnlijk te maken hebt.
- Bij overbelasting stellen we filters, rate limits en voorgeschakelde beschermregels in tot de aanval afneemt.
- Bij verdenking van een inbraak nemen we de gestructureerde [incident response](https://phpsos.de/nl/leistungen/incident-response/) over: veiligstellen, indammen, oorzaak vinden, opruimen.
- Aan het eind documenteren we wat er is gebeurd en welke maatregelen zijn doorgevoerd, tot het incident is afgesloten.


## Veelgestelde vragen

**Kan een DDoS-aanval gegevens stelen?**  
Een zuivere DDoS-aanval richt zich op de bereikbaarheid, niet op gegevens. Ze wijzigt geen bestanden en leest geen databases. Ze kan echter tegelijk met een inbraakpoging optreden, daarom loont toch een blik op bestanden en accounts.

**Waaraan herken ik dat mijn website is gehackt?**  
Typische aanwijzingen zijn nieuwe of gewijzigde PHP-bestanden, onbekende beheerdersaccounts, doorverwijzingen naar vreemde sites, onverwachte uitgaande verbindingen en processen die niet bij uw toepassing passen. Eén enkel teken is geen bewijs, meerdere samen zijn een serieus signaal.

**Helpt een CDN of een WAF tegen beide soorten aanvallen?**  
Tegen volumegebaseerde aanvallen helpt een voorgeschakelde dienst meestal goed. Tegen exploits werken regels alleen als ze het patroon herkennen. Bij PHP2Shell wijst Cloudflare er zelf op dat regels die alleen op de aanvraaggegevens zijn gebaseerd niet volstaan.

**Moet ik een DDoS-aanval melden?**  
Dat hangt af van het individuele geval en uw branche. Zonder toegang tot persoonsgegevens geldt de meldplicht van de AVG in de regel niet, maar er kunnen branchespecifieke plichten bestaan. Stem dit af met uw functionaris voor gegevensbescherming of een advocaat.

## Bronnen

- [BSI: situatie en aanbevelingen (Duitse federale dienst voor informatiebeveiliging)](https://www.bsi.bund.de/)
- [TechTarget: PHP2Shell, 22M exposed servers at risk](https://www.techtarget.com/cybersecurity/news/366652444/PHP2Shell-22M-exposed-servers-at-risk-as-emergency-patches-released)
- [php.net: beveiligingsmeldingen](https://www.php.net/)