Kort gezegd: Als de server spam verstuurt, is er meestal een van drie oorzaken: een ingebracht of misbruikt PHP-script, een postvak met een gestolen wachtwoord of een verkeerd geconfigureerde mailserver. Stel enkele van de wachtende mails veilig, lees hun kopregels en het maillog, en u vindt in de meeste gevallen de bron. Daarna de verzending stoppen, de oorzaak dichten en pas dan de verwijdering van blokkadelijsten aanvragen.
Als klanten uw facturen in de spammap vinden
Het begint zelden met een beveiligingsmelding. Meestal melden klanten zich die uw aanbiedingen niet meer ontvangen, of het postvak vult zich met bouncemeldingen over mails die nooit iemand heeft geschreven. Soms blokkeert de hoster de verzending en noemt als reden opvallend mailverkeer.
Voor het bedrijf heeft dat snel merkbare gevolgen. Staat het adres van de server op een blokkadelijst, dan weigeren andere mailservers ook uw echte mails: facturen, orderbevestigingen, wachtwoordlinks uit de webshop. De reputatie van het domein lijdt, en de schade groeit met elk uur waarin de verzending doorgaat.
Spamverzending behoort tot de bekende gevolgen van een compromittering. Na PHP2Shell, de lekken CVE-2026-109618 en CVE-2026-109619 met code-uitvoering zonder aanmelding, is dat een reden temeer om nauwkeuriger te kijken. Een specifieke PHP2Shell-aanwijzing is spam echter niet; bevestigde Indicators of Compromise bestaan niet. Verdere algemene tekenen beschrijft Ben ik al gecompromitteerd?.
Drie typische oorzaken als de server spam verstuurt
| Oorzaak | Typisch beeld | Waar u kijkt |
|---|---|---|
| Ingebracht PHP-script | Mails zonder aanmelding, lokaal via sendmail aangeleverd |
Kopregels, PHP-maillog, nieuwe PHP-bestanden |
| Misbruikt formulier | Mails via een contact- of aanbevelingsformulier aan vreemde ontvangers | Toegangslog van het formulier, kopregels |
| Gekaapt postvak | Verzending met geldige aanmelding bij de mailserver | Maillog met aanmeldnaam, aanmeldlocaties |
| Open mailserver | Vreemde afzenders gebruiken uw server als doorgeefluik | Mailserverconfiguratie, externe controle |
De eerste twee oorzaken betreffen de website, de derde de mailaccounts, de vierde de serverconfiguratie. Het onderscheid is belangrijk, omdat de tegenmaatregelen totaal verschillen.
De mailwachtrij lezen
Op servers met Postfix toont de wachtrij wat er op dit moment moet worden verzonden. De volgende opdrachten lezen alleen:
# Inhoud van de wachtrij tonen (komt overeen met mailq)
postqueue -p | tail -30
# Kopregels van één enkele mail tonen (queue-ID uit de lijst invullen)
sudo postcat -q -h QUEUE-ID
# Geslaagde aanmeldingen bij de mailserver met gebruikersnaam
sudo grep 'sasl_username=' /var/log/mail.log | awk -F'sasl_username=' '{print $2}' | sort | uniq -c | sort -rn | head
De kopregels verraden vaak al de bron. Komt de mail van een aangemeld postvak, dan verschijnt de aanmeldnaam in het maillog. Hoopt zich daar een enkel account op met aanmeldingen uit vreemde landen, dan is het wachtwoord van dat postvak zeer waarschijnlijk bekend geworden. Werd de mail daarentegen lokaal aangeleverd, dan komt ze meestal van een script op de server.
Draait er op uw server een andere mailserver, bijvoorbeeld Exim, dan heten de opdrachten anders, maar het principe blijft gelijk: wachtrij bekijken, kopregels lezen, aanmeldingen in het log tellen. Bij shared hosting zonder shell-toegang vraagt u de hoster schriftelijk om een uittreksel uit het maillog en enkele voorbeeldmails met volledige kopregels. Veel hosters leveren deze gegevens op verzoek, omdat zij er zelf belang bij hebben de verzending te beëindigen.
Stel enkele volledige mails veilig voordat u de wachtrij aanhoudt of leegt. Ze zijn bewijs voor de latere analyse en voor gesprekken met de hoster of de exploitanten van blokkadelijsten.
Het verantwoordelijke PHP-script vinden
Loopt de verzending via PHP, dan helpt de mailconfiguratie van PHP. Volgens de PHP-handleiding logt mail.log elke aanroep van de mail()-functie met volledig scriptpad, regelnummer, ontvanger en kopregels. mail.add_x_header schrijft bovendien een kopregel X-PHP-Originating-Script met de gebruikersidentificatie en de bestandsnaam in elke mail.
; In php.ini of in de FPM-pool, daarna alle workers herstarten
mail.add_x_header = On
mail.log = /var/log/php/mail.log
Het logbestand moet voor het PHP-proces beschrijfbaar zijn. De kopregel verraadt ontvangers een bestandsnaam; schakel haar na de analyse weer uit als u dat niet blijvend wilt.
Vindt u als afzender een onbekend bestand, bijvoorbeeld in de upload- of cachemap, dan is dat een aanwijzing voor een webshell. Hoe u zulke bestanden plaatst, beschrijft Webshells herkennen en verwijderen. Is het daarentegen een bekend contactformulier, dan is het waarschijnlijk misbruikt, bijvoorbeeld doordat ontvangers of kopregels uit formulierinvoer worden overgenomen. Dat is een fout in de code, geen inbraak, maar moet even snel worden verholpen.
Niet elke spam gebruikt de mail()-functie. Schadelijke code kan ook rechtstreeks een verbinding met vreemde mailservers opbouwen. Dan verschijnt de verzending niet in de wachtrij of in het PHP-maillog, maar wel als uitgaande verbindingen op poort 25. Hoe u die controleert, staat onder Uitgaande verbindingen van een server controleren.
Verzending stoppen en netjes weer opstarten
Is de bron gevonden, dan volgt de opschoning in deze volgorde:
- Verzending aanhouden: De betrokken weg blokkeren, dus het script deactiveren, het postvak blokkeren of de wachtrij aanhouden. Wachtende mails als bewijs veiligstellen.
- Oorzaak dichten: Bij een webshell PHP op een verholpen stand brengen (8.5.12, 8.4.27, 8.3.36, 8.2.35 of bevestigde backport), alle workers herstarten en de website opschonen. Bij een formulier de code corrigeren. Bij een postvak het wachtwoord wijzigen en het apparaat van de gebruiker controleren.
- Zoeken naar verdere sporen: Wie spam via een webshell verstuurt, heeft vaak verdere achterdeuren aangelegd.
- Uitgaand verkeer beperken: Uitgaande verbindingen op poort 25 alleen voor de mailserver toestaan, niet voor de webservergebruiker.
- Blokkadelijsten opschonen: Pas nu bij de exploitanten van de blokkadelijsten de verwijdering aanvragen en kort beschrijven wat is verholpen.
Controleer bij deze gelegenheid SPF, DKIM en DMARC van uw domein. Deze DNS-records leggen vast welke servers namens uw domein mogen verzenden, en maken het voor vreemden moeilijker uw afzenderadres te misbruiken.
Hoe helpt PHP SOS concreet?
- Wij analyseren wachtrij, kopregels en maillogs en stellen vast of script, formulier, postvak of configuratie de oorzaak is.
- Wij stoppen de verzending gecontroleerd en stellen bewijs veilig voor hoster en blokkadelijsten.
- Wij ruimen de website op in het kader van de malwareverwijdering en dichten de toegangspoort.
- Wij beperken uitgaand mailverkeer op serverniveau en begeleiden de verwijdering van blokkadelijsten.
Veelgestelde vragen
Waaraan merk ik dat mijn server spam verstuurt?
Typisch zijn bouncemeldingen over mails die niemand heeft geschreven, meldingen van de hoster, een volle mailwachtrij en klanten die uw mails plotseling in de spammap vinden. Ook vermeldingen van uw serveradres op openbare blokkadelijsten zijn een duidelijk teken.
Hoe vind ik het PHP-script dat spam verstuurt?
PHP kan elke aanroep van de mail()-functie met scriptpad loggen als mail.log is ingesteld. Met mail.add_x_header schrijft PHP de scriptnaam bovendien in de kop van elke mail. In reeds verstuurde of wachtende mails helpt een blik in de kopregels.
Moet ik de mailwachtrij meteen legen?
Niet voordat u enkele mails als bewijs hebt veiliggesteld. De kopregels tonen vaak welk script of welk postvak de verzending heeft veroorzaakt. Aanhouden is meestal beter dan wissen, totdat de bron bekend is.
Hoe kom ik weer van blokkadelijsten af?
Eerst de oorzaak wegnemen, daarna bij de betreffende exploitanten van de blokkadelijsten de verwijdering aanvragen. De meeste verlangen een verklaring van wat is verholpen. Wie te vroeg aanvraagt en doorgaat met spam, wordt opnieuw vermeld.