Kort sagt: När servern skickar spam finns oftast en av tre orsaker: ett insmugglat eller missbrukat PHP-skript, en postlåda med stulet lösenord eller en felkonfigurerad e-postserver. Säkra några av de väntande e-postmeddelandena, läs deras rubrikrader och e-postloggen, så hittar ni i de flesta fall källan. Därefter stoppar ni utskicken, stänger orsaken och begär först sedan borttagning från spärrlistor.
När kunder hittar era fakturor i skräppostmappen
Det börjar sällan med ett säkerhetsmeddelande. Oftast hör kunder av sig som inte längre får era offerter, eller så fylls postlådan med returmeddelanden om e-post som aldrig någon har skrivit. Ibland spärrar hostern utskicken och anger ovanlig e-posttrafik som skäl.
För företaget får det snabbt kännbara följder. Står serverns adress på en spärrlista avvisar andra e-postservrar också era riktiga e-postmeddelanden: fakturor, orderbekräftelser, lösenordslänkar från butiken. Domänens rykte skadas, och skadan växer för varje timme utskicken pågår.
Spamutskick hör till de kända följderna av en komprometterad server. Efter PHP2Shell, sårbarheterna CVE-2026-109618 och CVE-2026-109619 med kodkörning utan inloggning, är det ytterligare ett skäl att titta närmare. Spam är dock ingen specifik PHP2Shell-ledtråd; bekräftade Indicators of Compromise finns inte. Fler allmänna tecken beskrivs i Är jag redan komprometterad?.
Tre typiska orsaker när servern skickar spam
| Orsak | Typisk bild | Var ni tittar |
|---|---|---|
| Insmugglat PHP-skript | E-post utan inloggning, levererad lokalt via sendmail |
rubrikrader, PHP-mail-logg, nya PHP-filer |
| Missbrukat formulär | E-post via ett kontakt- eller rekommendationsformulär till främmande mottagare | formulärets åtkomstlogg, rubrikrader |
| Kapad postlåda | Utskick med giltig inloggning på e-postservern | e-postlogg med inloggningsnamn, inloggningsplatser |
| Öppen e-postserver | Främmande avsändare använder er server som vidarebefordran | e-postserverns konfiguration, extern kontroll |
De två första orsakerna berör webbplatsen, den tredje e-postkontona, den fjärde serverkonfigurationen. Indelningen är viktig, eftersom motåtgärderna är helt olika.
Läs e-postkön
På servrar med Postfix visar kön vad som just ska skickas. Kommandona nedan läser bara:
# Visa köns innehåll (motsvarar mailq)
postqueue -p | tail -30
# Visa rubrikraderna för ett enskilt e-postmeddelande (sätt in kö-ID ur listan)
sudo postcat -q -h QUEUE-ID
# Lyckade inloggningar på e-postservern med användarnamn
sudo grep 'sasl_username=' /var/log/mail.log | awk -F'sasl_username=' '{print $2}' | sort | uniq -c | sort -rn | head
Rubrikraderna avslöjar ofta redan källan. Kommer e-postmeddelandet från en inloggad postlåda syns inloggningsnamnet i e-postloggen. Hopar sig där ett enskilt konto med inloggningar från främmande länder har lösenordet för den postlådan med stor sannolikhet blivit känt. Levererades e-postmeddelandet däremot lokalt kommer det oftast från ett skript på servern.
Körs en annan e-postserver på er server, till exempel Exim, heter kommandona annorlunda, men principen är densamma: titta på kön, läs rubrikraderna, räkna inloggningar i loggen. Vid delad hosting utan skalåtkomst ber ni hostern skriftligen om ett utdrag ur e-postloggen och några exempel på e-postmeddelanden med fullständiga rubrikrader. Många hostar lämnar de uppgifterna på förfrågan, eftersom de själva har intresse av att få utskicken att upphöra.
Säkra några fullständiga e-postmeddelanden innan ni håller kvar eller tömmer kön. De är bevis för den senare analysen och för samtal med hostern eller spärrlistornas operatörer.
Hitta det ansvariga PHP-skriptet
Sker utskicken via PHP hjälper PHP:s e-postkonfiguration. Enligt PHP-manualen loggar mail.log varje anrop av funktionen mail() med fullständig skriptsökväg, radnummer, mottagare och rubrikrader. mail.add_x_header skriver dessutom en rubrikrad X-PHP-Originating-Script med användar-ID och filnamn i varje e-postmeddelande.
; I php.ini eller i FPM-poolen, starta därefter om alla workers
mail.add_x_header = On
mail.log = /var/log/php/mail.log
Loggfilen måste vara skrivbar för PHP-processen. Rubrikraden avslöjar ett filnamn för mottagarna; stäng av den igen efter analysen om ni inte vill ha den varaktigt.
Finns en okänd fil som avsändare, till exempel i uppladdnings- eller cachemappen, är det ett tecken på en webbshell. Hur ni placerar sådana filer beskrivs i Känn igen och ta bort webbshells. Är det däremot ett känt kontaktformulär har det sannolikt missbrukats, till exempel eftersom mottagare eller rubrikrader tas över från formulärinmatning. Det är ett fel i koden, inget intrång, men måste åtgärdas lika snabbt.
Inte allt spam använder funktionen mail(). Skadlig kod kan också bygga upp en anslutning direkt till främmande e-postservrar. Då syns utskicken varken i kön eller i PHP-mail-loggen, men väl som utgående anslutningar på port 25. Hur ni kontrollerar dem står under Kontrollera en servers utgående anslutningar.
Stoppa utskicken och starta om rent
Är källan funnen följer saneringen i den här ordningen:
- Håll kvar utskicken: Spärra den berörda vägen, alltså inaktivera skriptet, spärra postlådan eller håll kvar kön. Säkra väntande e-postmeddelanden som bevis.
- Stäng orsaken: Vid en webbshell ta PHP till en rättad nivå (8.5.12, 8.4.27, 8.3.36, 8.2.35 eller bekräftad backport), starta om alla workers och sanera webbplatsen. Vid ett formulär rätta koden. Vid en postlåda byt lösenord och kontrollera användarens enhet.
- Sök fler spår: Den som skickar spam via en webbshell har ofta skapat fler bakdörrar.
- Begränsa utgången: Tillåt utgående anslutningar på port 25 bara för e-postservern, inte för webbserveranvändaren.
- Rensa spärrlistor: Först nu begär ni borttagning hos spärrlistornas operatörer och beskriver kort vad som har åtgärdats.
Kontrollera vid det här tillfället SPF, DKIM och DMARC för er domän. Dessa DNS-poster avgör vilka servrar som får skicka i er domäns namn och försvårar för obehöriga att missbruka er avsändaradress.
Hur hjälper PHP SOS konkret?
- Vi utvärderar kö, rubrikrader och e-postloggar och tar reda på om skript, formulär, postlåda eller konfiguration är orsaken.
- Vi stoppar utskicken kontrollerat och säkrar bevis för hostern och spärrlistorna.
- Vi sanerar webbplatsen inom ramen för skadeprogramborttagningen och stänger ingångsvägen.
- Vi begränsar utgående e-posttrafik på servernivå och följer med vid borttagningen från spärrlistor.
Vanliga frågor
Hur märker jag att min server skickar spam?
Typiskt är returmeddelanden om e-post som ingen har skrivit, besked från hostern, en full e-postkö och kunder som plötsligt hittar era e-postmeddelanden i skräppostmappen. Även poster med er serveradress på offentliga spärrlistor är ett tydligt tecken.
Hur hittar jag PHP-skriptet som skickar spam?
PHP kan logga varje anrop av funktionen mail() med skriptsökväg om mail.log är satt. Med mail.add_x_header skriver PHP dessutom skriptnamnet i huvudet på varje e-postmeddelande. I redan skickade eller väntande e-postmeddelanden hjälper en titt i rubrikraderna.
Ska jag tömma e-postkön direkt?
Inte innan ni har säkrat några e-postmeddelanden som bevis. Rubrikraderna visar ofta vilket skript eller vilken postlåda som utlöste utskicket. Att hålla kvar är oftast bättre än att radera, tills källan är känd.
Hur kommer jag av spärrlistorna igen?
Åtgärda först orsaken, begär sedan borttagning hos respektive spärrlistas operatör. De flesta kräver en förklaring av vad som har åtgärdats. Den som begär för tidigt och fortsätter skicka spam listas på nytt.