Kort sagt: Ändrade filer hittar ni i Linux med find och ett tidsfönster, till exempel från och med den 17 oktober 2026, det enligt medierapporter första observerade angreppsförsöket mot PHP2Shell. Kontrollera därvid inte bara ändringstiden för innehållet (mtime), utan också den för metadata (ctime), eftersom den förra lätt kan förfalskas. Resultatet blir tillförlitligt först genom avstämning mot paketkontrollsummor, Git eller en säkerhetskopia.
Varför tidsstämplar är en bra ingång men inget bevis
Den som för kod till en server förändrar filer. Nya webbshells, justerade konfigurationsfiler, tillagda rader i befintliga skript: allt detta lämnar tidsstämplar. Sökningen efter ändringar i rätt tidsfönster är därför en av de snabbaste vägarna till de första fynden.
För PHP2Shell är den 17 oktober 2026 ett naturligt början på fönstret, dagen för det enligt medierapporter första observerade angreppsförsöket. Patcharna kom den 21 oktober. Den som uppdaterade sin server först därefter söker fram till dagen för den egna uppdateringen och längre. Hur ni känner igen webbshells bland fynden beskrivs i Känn igen och ta bort webbshells. Här handlar det om själva sökmetoden.
En fils tre tidsstämplar
Linux lagrar flera tidpunkter för varje fil. För sökningen efter förändringar är två avgörande.
| Tidsstämpel | Betydelse | Kan förfalskas? |
|---|---|---|
| mtime | senaste ändring av innehållet | ja, t.ex. med touch, av var och en som får skriva filen |
| ctime | senaste ändring av innehåll eller metadata som rättigheter | inte med enkla medel |
| atime | senaste läsåtkomst | ofta avstängd eller ungefärlig, lämpar sig dåligt för sökningen |
Angripare bakdaterar gärna mtime till grannfilernas datum, så att en ny fil inte syns. ctime ändras dock samtidigt. En fil med gammal mtime och färsk ctime är därför ett starkt tecken på manipulation.
Tänk på tidszoner vid jämförelsen. find och ls visar serverns lokala tid, medan många loggfiler och tjänster arbetar i UTC. Den som lägger fynd från filsystem och loggar bredvid varandra bör räkna om alla uppgifter till samma tidszon, annars verkar händelserna inte passa ihop. Patcharna kom ungefär den 21 oktober kl. 14:00 UTC, alltså kl. 16 tysk tid.
Hitta ändrade filer i Linux med find
Alla kommandon läser bara. Anpassa sökväg och datum.
# Innehåll ändrat sedan 17.10.2026, sorterat, med mtime, ctime och ägare
find /var/www -type f -newermt "2026-10-17" -printf '%TY-%Tm-%Td %TH:%TM %CY-%Cm-%Cd %CH:%CM %u %p\n' | sort
# Metadata ändrad sedan 17.10.2026 (hittar även bakdaterade filer)
find /var/www -type f -newerct "2026-10-17" -printf '%C+ %T+ %p\n' | sort
# Dölj känt brus: cache, loggar, sessioner
find /var/www -type f -newerct "2026-10-17" \
-not -path "*/cache/*" -not -path "*/logs/*" -not -path "*/sessions/*" -printf '%C+ %p\n' | sort
# Titta också utanför webbkatalogen
find /etc /usr/local/bin /tmp /var/tmp /dev/shm -xdev -type f -newerct "2026-10-17" -printf '%C+ %p\n' 2>/dev/null | sort
Jämför båda tidsstämplarna vid varje träff. Är ctime tydligt yngre än mtime, och ingen har ändrat rättigheter eller kopierat filer under den tiden, hör filen hemma på listan. Se också på ägaren: en fil som tillhör webbserveranvändaren mellan filer som tillhör deploy-användaren sticker ut.
Glöm inte dolda filer och kataloger. Namn som börjar med en punkt visar många filhanterare och ett enkelt ls inte. Angripare utnyttjar det gärna, liksom namn som är förvillande lika äkta filer.
# Dolda filer och mappar i webbkatalogen, utom kända som .htaccess och .git
find /var/www -name ".*" -not -name ".htaccess" -not -name ".well-known" -not -path "*/.git/*" -printf '%C+ %u %p\n' | sort
Stäm av mot en pålitlig källa
Tidsstämplar visar var något har rört sig. Om det var en legitim ändring visar först jämförelsen med en källa som ni litar på.
- Pakethantering: För systemfiler kontrollerar
dpkg --verify(Debian/Ubuntu) ellerrpm -Va(RHEL-familjen) filerna mot de installerade paketens kontrollsummor. Konfigurationsfiler avviker legitimt, programfiler inte. - Git: Ligger applikationen i ett repository visar
git -C /var/www/projekt status --porcelainvarje avvikelse från den senaste committen. - CMS-kontrollsummor: Många system kan stämma av sina kärnfiler mot de officiella kontrollsummorna, se Jämför CMS-kärnfiler med originalet.
- Säkerhetskopia från före incidenten: En jämförelse som provkörning listar skillnader utan att kopiera något.
# Lista bara skillnader mellan säkerhetskopians nivå och livesystemet (provkörning, kopierar inget)
rsync -rcn --out-format="%n" /backup/www-2026-10-15/ /var/www/
Jämförelsen med säkerhetskopian förutsätter att kopian skapades före incidenten och inte själv har förändrats. Varför separat förvarade kopior är avgörande här förklaras i Säkerhetskopior enligt 3-2-1-regeln.
Spara resultaten av varje sökning med datum i en fil utanför servern. Av de listorna uppstår senare incidentens tidslinje, och de belägger vad ni har kontrollerat och när.
Om varken säkerhetskopia eller repository finns
För många mindre webbplatser finns ingen ren jämförelsegrund: inget Git, ingen säkerhetskopia från före incidenten, plugins uppdaterade för hand i flera år. Helt utan hållpunkt är ni ändå inte.
Ladda ned CMS och tilläggen i exakt de installerade versionerna från tillverkaren och jämför dessa filer med servern. Det som avviker eller saknas förtjänar en titt. Kvar blir era egna anpassningar, uppladdningar och konfiguration; där hjälper sökningen på tidsstämplar, kompletterad med en blick på ägare och rättigheter. Filer som som enda i en katalog har en annan grupp, andra rättigheter eller en tydligt yngre ctime än sina grannar hör hemma på listan.
Ärligt talat: utan jämförelsegrund återstår en osäkerhet. För system med känsliga data är en nyuppbyggnad från rena källor då ofta mer tillförlitlig än sökandet efter varje enskild förändrad fil. För framtiden är lärdomen enkel: ett repository för koden och regelbundna, separat förvarade säkerhetskopior.
Typiska felkällor vid sökningen
- För generösa undantag: Cache- och uppladdningsmappar är omtyckta gömställen.
- Bara mtime kontrollerad: Bakdaterade filer slinker igenom.
- Deployment i tidsfönstret: En vanlig utrullning ändrar hundratals filer och döljer enskilda fynd. Stäm av mot repositoryt.
- Filer redan öppnade eller kopierade: Kopior utan bevarade tidsstämplar förstör spår. Säkra med verktyg som bevarar tidsstämplar.
- Bara webbkatalogen genomsökt: Angripare lägger verktyg också i
/tmp,/dev/shmeller i webbserveranvändarens hemkatalog. - Rättighetsändringar förbisedda: En fil vars rättigheter plötsligt tillåter skrivning för alla är ett fynd, även om innehållet är oförändrat.
Hur fynden sätts samman till ett förlopp visar Ta fram tidslinjen för en incident.
Hur hjälper PHP SOS konkret?
- Söka systematiskt: Vi genomsöker webbkataloger och systemsökvägar efter ändringar i det relevanta tidsfönstret och utvärderar mtime och ctime tillsammans.
- Kontrollera mot original: Vi stämmer av mot paket, repository, CMS-kontrollsummor och era säkerhetskopior.
- Bedöma fynd: Vi skiljer vanliga ändringar från manipulationer och säkrar bevis.
- Sanera: Med skadeprogramborttagningen skapar vi en ren nivå och dokumenterar den.
Vanliga frågor
Hur hittar jag alla filer som ändrats sedan ett visst datum?
Med find och alternativet -newermt, till exempel find /var/www -type f -newermt "2026-10-17". För ändringar av metadata använder ni -newerct. Båda kommandona läser bara och ändrar ingenting.
Vad är skillnaden mellan mtime och ctime?
mtime är tidpunkten för den senaste ändringen av innehållet och kan med enkla medel bakdateras. ctime är tidpunkten för den senaste ändringen av innehåll eller metadata och kan inte förfalskas lika enkelt. Avviker de starkt från varandra lönar det sig att titta noga.
Hur utesluter jag cachefiler ur sökningen?
Med -not -path för kända cache-, logg- och sessionsmappar. Uteslut dock inte för generöst, eftersom angripare gärna lägger filer just där många ändringar är normala.
Vilken kontroll är mest tillförlitlig?
Avstämningen mot en pålitlig källa: kontrollsummor från pakethanteringen, ett Git-repository eller en säkerhetskopia från före incidenten. Tidsstämplar är en bra ingång, men inget bevis.