SMTP-gegevens onveilig opgeslagen in scripts of oude mailclients

> Onderdeel van: Uitgaande e-mail opgeschort — wat nu?

Je mailboxwachtwoord kan ook lekken doordat het ergens onveilig is opgeslagen — bijvoorbeeld in een PHP-script op je website, in een back-up die per ongeluk publiek staat, of in een oude mailclient die je niet meer gebruikt. Zodra zo'n bestand wordt uitgelezen, heeft de aanvaller een geldige login om SMTP-mail mee te versturen.

Wanneer past dit op jou?

Eén of meer van deze zaken klopt:

• Je website verstuurt e-mail via SMTP (bijvoorbeeld via een plug-in als WP Mail SMTP, FluentSMTP, Easy WP SMTP).
• Je hebt ooit een ontwikkelaar toegang gegeven die SMTP-gegevens in een script of .env  -bestand heeft gezet.
• Je hebt back-ups van je site of databases die mogelijk publiek toegankelijk zijn.
• Je gebruikt nog mailclients op apparaten die je al lang niet meer aanraakt.
• Wachtwoord wijzigen helpt, maar binnen een paar dagen lekt het weer.

Stappenplan

Stap 5.1 — Controleer of SMTP-credentials in scripts staan

Veel WordPress-installaties gebruiken een SMTP-plug-in om e-mails te versturen via een mailbox. Het wachtwoord wordt opgeslagen in de database. Bij andere CMS-en kan het in een configuratiebestand staan zoals:

• wp-config.php  
• .env   (Laravel, Symfony, andere moderne frameworks)
• configuration.php   (Joomla)
• app/etc/env.php   (Magento)
• Maatwerk PHP-bestanden die mail()   of een SMTP-library aanroepen

Doorzoek je website-bestanden op het mailadres of "smtp", "password" of "wachtwoord" om te zien waar credentials staan. Doe dit via FTP of de bestandsbeheerder.

Stap 5.2 — Controleer op publieke back-ups

Zoek in de hoofdmap (public_html  , httpdocs  , www  ) en submappen naar:

• Bestanden eindigend op .sql  , .sql.gz  , .zip  , .tar.gz  , .bak  
• Mappen zoals /backup/  , /old/  , /test/  , /dev/  
• Bestanden met namen als database.sql  , site-backup.zip  , dump.sql  

Dit soort bestanden hoort niet publiek op je website te staan. Verwijder ze, of verplaats ze naar een privémap buiten de webroot. Een aanvaller die jouwdomein.nl/backup.sql   opent, leest mogelijk al je inloggegevens.

Stap 5.3 — Verwijder oude mailclients en sessies

Heb je nog een oude laptop, telefoon, tablet of werkcomputer staan waarop deze mailbox ooit was ingesteld? Verwijder daar het account uit de mailclient, of beter: wis het apparaat als je het toch niet meer gebruikt.

Log ook overal uit van de webmail:

1. Log in op de webmail.
2. Zoek de optie "Actieve sessies" of "Recente activiteit" (afhankelijk van je webmail).
3. Beëindig alle sessies behalve die van jezelf.

Stap 5.4 — Stap over op een veiligere verzendmethode (aanbevolen)

In plaats van het mailbox-wachtwoord in scripts te zetten, kun je beter:

• Een app-specifiek wachtwoord gebruiken (apart wachtwoord per dienst), zodat het wachtwoord van de mailbox zelf niet lekt.
• Een API-gebaseerde mailservice gebruiken voor transactionele mail vanuit je website (zoals SendGrid, Mailgun, Postmark, of een SMTP-relay). Daarbij gebruikt je website een API-key in plaats van het mailbox-wachtwoord.

Stap 5.5 — Wijzig het wachtwoord en werk overal bij

Zodra je weet waar de credentials nog staan opgeslagen:

1. Wijzig het mailboxwachtwoord (zie Artikel 1).
2. Werk het nieuwe wachtwoord bij in elke SMTP-instelling op je website.
3. Test of de website nog steeds e-mail kan versturen.

Hoe weet je of dit de oorzaak was?

Goede signalen:

• ✅ Je vond een back-up of script met SMTP-credentials in een publiek toegankelijke map.
• ✅ Je had nog een oud apparaat met een actieve mailbox-instelling.
• ✅ De spam kwam terug nadat je het wachtwoord had gewijzigd zonder de SMTP-instellingen bij te werken.

Klaar?

Alle scripts schoon, back-ups verwijderd, wachtwoord vernieuwd en overal bijgewerkt? Ga naar Stap 7 — Melden dat het is opgelost.