# IT-forensik efter ett angrepp på webbservern

> IT-forensik för servrar: Vi säkrar spår bevissäkert, analyserar loggar och filer och klarlägger med specialistpartner vad som hände vid angreppet.

Källa: https://phpsos.de/sv/leistungen/it-forensik/  
Aktualitet: 2026-10-25  
Leverantör: PHP SOS, PHP-nödhjälp och serversäkerhet. Omedelbar hjälp via WhatsApp: https://wa.me/491736494914?text=Hej%20PHP%20SOS%2C%20vi%20beh%C3%B6ver%20hj%C3%A4lp%20med%20v%C3%A5r%20PHP-server.%20F%C3%B6retag%3A%20%E2%80%A6%20Webbplats%3A%20%E2%80%A6

**Kort sagt:** IT-forensik för servrar besvarar frågan om vad som faktiskt hände vid ett angrepp: när, hur och med vilka följder. Tillsammans med specialiserade forensikpartner säkrar vi spår på ett bevissäkert sätt, analyserar loggar, filsystem och databaser och levererar en spårbar rapport. Den utgör underlag för anmälningar, försäkring och i förekommande fall brottsutredning.

## När ni behöver IT-forensik för er server

Inte varje incident kräver en forensisk undersökning. Det är framför allt meningsfullt när personuppgifter, betalningsuppgifter eller affärshemligheter kan vara berörda, när en polisanmälan eller en rättstvist kan förutses eller när ett försäkringsbolag förväntar sig ett hållbart underlag. Även när frågan är om en anmälan till tillsynsmyndigheten behövs hjälper belagda fakta mer än antaganden.

Efter PHP2Shell tillkommer en särskild omständighet. Sårbarheterna CVE-2026-109618 och CVE-2026-109619 tillåter kodkörning utan inloggning, och det finns inga publicerade, bekräftade Indicators of Compromise. Om en server var berörd går därför inte att bocka av med en checklista, utan bara genom beteendeanalys: Vilka processer körde, vilka filer uppstod, vilka förbindelser gick utåt? Första hållpunkter ger [Är jag redan komprometterad?](https://phpsos.de/sv/php2shell/bin-ich-gehackt-anzeichen/).

## Vad som skiljer forensik från snabb rensning

Rensning vill göra servern ren igen. Forensik vill förstå och belägga. Den ena frågan lyder ”Är servern säker igen?”, den andra ”Vad hände exakt, och vilka data var åtkomliga?”. För anmälningar, försäkring och kundinformation är oftast den andra frågan avgörande. Båda går att förena om ordningen stämmer: först säkra, sedan ändra. Den som först raderar, patchar eller startar om förlorar flyktiga spår och kan i efterhand ofta inte längre visa vad angriparen har sett.

> **Viktigt:**
> Spara alla serverloggar från och med den 20 oktober 2026 och be ert webbhotell att inte rotera eller radera loggar. Saknade loggar är den vanligaste orsaken till öppna frågor i rapporten.

## Vilka spår på en PHP-webbserver som räknas

På en typisk webbserver finns fler spår än många driftansvariga tror. Om de går att använda beror på hur länge de sparas och om de säkrades före ingreppet.

- **Åtkomst- och felloggar** från webbservern och PHP-FPM, inklusive kraschade workers
- **Filsystem:** nya eller ändrade filer, deras tidsstämplar och ägare, körbar kod i uppladdningsmappar
- **Databas:** nya användarkonton, ändrade inställningar, insmugglat innehåll
- **System:** cronjobb, användare, SSH-nycklar, inloggningsloggar, körande processer och nätverksförbindelser
- **Uppströms system:** loggar från CDN, WAF, brandvägg, lastbalanserare och e-postserver

Just de uppströms systemen glöms ofta bort. De ligger utanför webbservern och är därför svårare för en angripare att manipulera. Hos vissa leverantörer sparas de bara en kort tid, så ni bör exportera dem tidigt.

## Hur hjälper PHP SOS konkret?

1. **Klarlägga uppdraget:** Vi fastställer med er vilka frågor som ska besvaras, till exempel ingångsväg, tidsperiod, berörda data eller förflyttning i nätet. Av det följer vilka system som undersöks.
2. **Bevissäker säkring:** Vi och våra specialiserade partner skapar kopior av lagringsmedier, loggar, databaser och, där det går, arbetsminne. Varje säkring får en kontrollsumma, och varje överlämning dokumenteras.
3. **Analysera:** Vi analyserar åtkomst- och felloggar, filändringar, användarkonton, cronjobb, processer och utgående förbindelser. Metodiken för loggar beskrivs i [Analysera webbserverloggar efter ett angrepp](https://phpsos.de/sv/ratgeber/logfiles-auswerten/).
4. **Ta fram tidslinje:** Av fynden uppstår en tidslinje över incidenten där varje påstående hänvisar till ett konkret belägg.
5. **Lämna över rapport:** Ni får en teknisk rapport och en begriplig sammanfattning för ledningen.

## Vad ni får och vad vi behöver

Rapporten innehåller de säkrade bevismedlen med kontrollsummor, dokumentationen av överlämningskedjan, tidslinjen, den fastställda eller sannolika ingångsvägen, de berörda systemen och datatyperna samt rekommendationer. Varje påstående är markerat som belagt, sannolikt eller okänt.

Vi behöver från er:

- **Åtkomst** till de berörda systemen eller ett godkännande att ert webbhotell ställer kopior till vårt förfogande
- **en beslutsbefogad person** som fastställer omfattning och prioriteringar
- **Information** om systemmiljö, leverantörer och kända ändringar under de senaste veckorna
- **befintliga loggar**, även från brandväggar, CDN, WAF eller e-postservrar
- **uppgift** om försäkringsgivare, polis eller jurist redan är inkopplade

Om ni vill göra en polisanmälan finns anvisningar under [Polisanmälan: ZAC, polisens centrala kontaktpunkter för it-brottslighet](https://phpsos.de/sv/compliance/anzeige-polizei-zac/). Vad försäkringsgivare typiskt förväntar sig vid skada förklarar [Cyberförsäkring: Vad som räknas vid skada](https://phpsos.de/sv/compliance/cyberversicherung/).

## Vad vi inte lovar

Forensik kan bara analysera de spår som finns. Om loggar saknas, har skrivits över eller manipulerats av angriparen kvarstår luckor, och vi pekar ut dem. Vi lovar inte att en domstol bedömer våra resultat på något visst sätt, och vi gör ingen rättslig bedömning. Vi pekar inte ut gärningsmän utan beskriver vad spåren visar. Inte heller uttalanden som ”det har säkert inte läckt ut några data” gör vi om inte beläggen bär dem.

Pågår angreppet fortfarande går begränsningen före. Då börjar vi med [incident response](https://phpsos.de/sv/leistungen/incident-response/) och säkrar parallellt så många spår som möjligt.


## Vanliga frågor

**Vad innebär bevissäkring som håller i domstol?**  
Spår säkras så att det i efterhand går att visa att de är oförändrade. Dit hör kontrollsummor, en dokumenterad överlämningskedja och arbete på kopior i stället för på originalet. Om en domstol godtar ett bevismedel avgör dock domstolen.

**Kan IT-forensik klarlägga om kunddata har läckt ut?**  
Ofta går det att avgränsa vilka data en angripare hade åtkomst till och om det finns tecken på utläckage. En säker uteslutning är inte alltid möjlig, särskilt inte om loggar saknas. Resultatet delas därför upp i belagt, sannolikt och okänt.

**Hur länge måste loggar sparas?**  
För utredningen så länge som möjligt, åtminstone tills undersökningen är avslutad. Vid PHP2Shell rekommenderar facktidningarna att spara serverloggar från och med den 20 oktober 2026. Rättsliga lagrings- och raderingsskyldigheter klarar ni ut med ert dataskyddsombud.

**Får jag starta om eller patcha servern innan forensiken?**  
En omstart raderar flyktiga spår i arbetsminnet, en patch ändrar filer. Om ni kan, säkra först eller tala kort med oss. Är faran akut går begränsningen före, och det dokumenteras.

## Källor

- [BSI: Tysklands federala myndighet för informationssäkerhet](https://www.bsi.bund.de/)
- [Polisen: centrala kontaktpunkter för it-brottslighet (ZAC)](https://www.polizei.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)