Kort sagt: Ændrede filer finder I under Linux med find og et tidsvindue, f.eks. fra og med den 17. oktober 2026, det ifølge mediernes rapporter første observerede angrebsforsøg på PHP2Shell. Kontrollér dog ikke kun indholdets ændringstidspunkt (mtime), men også metadatas (ctime), fordi førstnævnte let kan forfalskes. Pålidelig bliver resultatet først ved afstemning med pakkernes kontrolsummer, Git eller en backup.
Hvorfor tidsstempler er en god begyndelse, men intet bevis
Den, der bringer kode ind på en server, ændrer filer. Nye webshells, tilpassede konfigurationsfiler, tilføjede linjer i eksisterende scripts: Alt det efterlader tidsstempler. Søgningen efter ændringer i det rette tidsvindue er derfor en af de hurtigste veje til de første fund.
For PHP2Shell byder den 17. oktober 2026 sig til som begyndelse på vinduet, dagen for det ifølge mediernes rapporter første observerede angrebsforsøg. Patcherne udkom den 21. oktober. Den, der først har opdateret sin server derefter, søger frem til dagen for sin egen opdatering og videre derudover. Hvordan I genkender webshells blandt fundene, beskriver Genkend og fjern webshells. Her handler det om selve søgemetoden.
En fils tre tidsstempler
Linux gemmer flere tidspunkter for hver fil. Til søgningen efter ændringer er to afgørende.
| Tidsstempel | Betydning | Kan forfalskes? |
|---|---|---|
| mtime | seneste ændring af indholdet | ja, f.eks. med touch, af enhver, der må skrive til filen |
| ctime | seneste ændring af indhold eller metadata som rettigheder | ikke med simple midler |
| atime | seneste læseadgang | ofte slået fra eller unøjagtig, lidet egnet til søgningen |
Angribere sætter gerne mtime tilbage til datoen for nabofilerne, så en ny fil ikke falder i øjnene. Men ctime ændrer sig dermed med. En fil med gammel mtime og frisk ctime er derfor et stærkt indicium på manipulation.
Vær ved sammenligningen opmærksom på tidszoner. find og ls viser serverens lokale tid, mange logfiler og tjenester arbejder derimod i UTC. Den, der lægger fund fra filsystemet og logs ved siden af hinanden, bør omregne alle angivelser til samme tidszone, ellers passer hændelser tilsyneladende ikke sammen. Patcherne udkom omtrent den 21. oktober kl. 14:00 UTC, altså kl. 16 tysk tid.
Find ændrede filer under Linux med find
Alle kommandoer læser kun. Tilpas sti og dato.
# Indhold ændret siden 17.10.2026, sorteret, med mtime, ctime og ejer
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 ændret siden 17.10.2026 (finder også filer sat tilbage i tid)
find /var/www -type f -newerct "2026-10-17" -printf '%C+ %T+ %p\n' | sort
# Skjul kendt støj: cache, logs, sessioner
find /var/www -type f -newerct "2026-10-17" \
-not -path "*/cache/*" -not -path "*/logs/*" -not -path "*/sessions/*" -printf '%C+ %p\n' | sort
# Kig også uden for webmappen
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
Sammenlign ved hvert fund begge tidsstempler. Er ctime tydeligt yngre end mtime, og har ingen i dette tidsrum ændret rettigheder eller kopieret filer, hører filen hjemme på listen. Vær også opmærksom på ejere: En fil tilhørende webserverbrugeren mellem filer tilhørende deploy-brugeren falder i øjnene.
Glem ikke skjulte filer og mapper. Navne, der begynder med et punktum, viser mange filhåndteringer og et simpelt ls ikke. Angribere bruger gerne det, ligesom navne, der forveksles let med ægte filer.
# Skjulte filer og mapper i webmappen, uden kendte som .htaccess og .git
find /var/www -name ".*" -not -name ".htaccess" -not -name ".well-known" -not -path "*/.git/*" -printf '%C+ %u %p\n' | sort
Afstem mod en troværdig kilde
Tidsstempler viser, hvor noget har rørt sig. Om det var en legitim ændring, viser først sammenligningen med en kilde, som I stoler på.
- Pakkehåndtering: Til systemfiler kontrollerer
dpkg --verify(Debian/Ubuntu) ellerrpm -Va(RHEL-familien) filerne mod de installerede pakkers kontrolsummer. Konfigurationsfiler afviger legitimt, programfiler ikke. - Git: Ligger applikationen i et repository, viser
git -C /var/www/projekt status --porcelainenhver afvigelse fra den seneste commit. - CMS-kontrolsummer: Mange systemer kan afstemme deres kernefiler mod de officielle kontrolsummer, se Sammenlign CMS-kernefiler med originalen.
- Backup fra før hændelsen: En sammenligning som prøvekørsel opregner forskelle uden at kopiere noget.
# Opregn kun forskelle mellem backup-status og livesystem (prøvekørsel, kopierer intet)
rsync -rcn --out-format="%n" /backup/www-2026-10-15/ /var/www/
Backup-sammenligningen forudsætter, at backuppen opstod før hændelsen og ikke selv blev ændret. Hvorfor adskilt opbevarede sikkerhedskopier er afgørende her, forklarer Backups efter 3-2-1-reglen.
Gem resultaterne af hver søgning med dato i en fil uden for serveren. Af disse lister opstår senere hændelsens tidslinje, og de dokumenterer, hvad I har kontrolleret hvornår.
Hvis der hverken findes backup eller repository
Ved mange mindre websites findes der intet rent sammenligningsgrundlag: ingen Git, ingen backup fra før hændelsen, plugins opdateret i hånden i årevis. Helt uden holdepunkt er I alligevel ikke.
Hent CMS og udvidelser i netop de installerede versioner hos producenten, og sammenlign disse filer med serveren. Det, der dér afviger eller mangler, fortjener et kig. Tilbage bliver jeres egne tilpasninger, uploads og konfiguration; dér hjælper tidsstempelsøgningen, suppleret med et blik på ejere og rettigheder. Filer, der som de eneste i en mappe har en anden gruppe, andre rettigheder eller en tydeligt yngre ctime end deres naboer, hører hjemme på listen.
Ærligt sagt: Uden sammenligningsgrundlag består der en restusikkerhed. Ved systemer med følsomme data er en nyopbygning ud fra rene kilder da ofte mere pålidelig end søgningen efter hver enkelt ændret fil. For fremtiden er lærdommen enkel: et repository til koden og regelmæssige, adskilt opbevarede sikkerhedskopier.
Typiske fejlkilder ved søgningen
- For rundhåndede udeladelser: Cache- og upload-mapper er populære gemmesteder.
- Kun mtime kontrolleret: Filer sat tilbage i tid slipper igennem.
- Deployment i tidsvinduet: En regulær udrulning ændrer hundreder af filer og skjuler enkelte fund. Afstem mod repositoryet.
- Filer allerede åbnet eller kopieret: Kopier uden bevarelse af tidsstempler ødelægger spor. Sikr med værktøjer, der bevarer tidsstempler.
- Kun webmappen gennemsøgt: Angribere lægger også værktøjer i
/tmp,/dev/shmeller i webserverbrugerens hjemmemappe. - Rettighedsændringer overset: En fil, hvis rettigheder pludselig tillader skriveadgang for alle, er et fund, selv om dens indhold er uændret.
Hvordan fundene sættes sammen til et forløb, viser Opret tidslinjen for en hændelse.
Hvordan hjælper PHP SOS konkret?
- Søg systematisk: Vi gennemsøger webmapper og systemstier efter ændringer i det relevante tidsvindue og vurderer mtime og ctime samlet.
- Kontrollér mod originaler: Vi afstemmer mod pakker, repository, CMS-kontrolsummer og jeres backups.
- Vurdér fund: Vi skiller regulære ændringer fra manipulationer og sikrer beviser.
- Ryd op: Med malwarefjernelsen skaber vi en ren status og dokumenterer den.
Ofte stillede spørgsmål
Hvordan finder jeg alle filer, der er ændret siden en bestemt dato?
Med find og tilvalget -newermt, f.eks. find /var/www -type f -newermt "2026-10-17". Til ændringer af metadata bruger I -newerct. Begge kommandoer læser kun og ændrer intet.
Hvad er forskellen på mtime og ctime?
mtime er tidspunktet for den seneste ændring af indholdet og kan sættes tilbage med simple midler. ctime er tidspunktet for den seneste ændring af indhold eller metadata og kan ikke så let forfalskes. Afviger de to stærkt fra hinanden, er et nøjere kig umagen værd.
Hvordan udelukker jeg cachefiler fra søgningen?
Med -not -path for kendte cache-, log- og sessionsmapper. Udeluk dog ikke for rundhåndet, for angribere lægger gerne filer netop dér, hvor mange ændringer er normale.
Hvilken kontrol er mest pålidelig?
Afstemningen mod en troværdig kilde: pakkehåndteringens kontrolsummer, et Git-repository eller en backup fra før hændelsen. Tidsstempler er en god begyndelse, men intet bevis.