In breve: su Linux i file modificati si trovano con find e una finestra temporale, ad esempio dal 17 ottobre 2026, il primo tentativo di attacco a PHP2Shell osservato secondo i media. Verifichi non solo l'ora di modifica del contenuto (mtime), ma anche quella dei metadati (ctime), perché la prima si falsifica facilmente. Il risultato diventa affidabile solo con il confronto con somme di controllo dei pacchetti, Git o un backup.
Perché le marcature temporali sono un buon punto di partenza, ma non una prova
Chi porta del codice su un server modifica dei file. Nuove webshell, file di configurazione adattati, righe aggiunte in script esistenti: tutto ciò lascia marcature temporali. La ricerca di modifiche nella finestra temporale giusta è quindi una delle vie più rapide ai primi ritrovamenti.
Per PHP2Shell come inizio della finestra si presta il 17 ottobre 2026, il giorno del primo tentativo di attacco osservato secondo i media. Le patch sono uscite il 21 ottobre. Chi ha aggiornato il proprio server solo dopo cerca fino al giorno del proprio aggiornamento e oltre. Come riconoscere le webshell tra i ritrovamenti lo descrive Riconoscere e rimuovere una webshell. Qui si tratta del metodo di ricerca in sé.
Le tre marcature temporali di un file
Linux memorizza per ogni file più momenti. Per la ricerca di modifiche due sono decisivi.
| Marcatura temporale | Significato | Falsificabile? |
|---|---|---|
| mtime | ultima modifica del contenuto | sì, ad es. con touch, da chiunque possa scrivere il file |
| ctime | ultima modifica di contenuto o metadati come i permessi | non con mezzi semplici |
| atime | ultimo accesso in lettura | spesso disattivato o impreciso, poco adatto alla ricerca |
Gli aggressori retrodatano volentieri la mtime alla data dei file vicini, perché un nuovo file non dia nell'occhio. La ctime, però, cambia insieme. Un file con mtime vecchia e ctime recente è quindi un forte indizio di manipolazione.
Nel confronto faccia attenzione ai fusi orari. find e ls mostrano l'ora locale del server, mentre molti file di log e servizi lavorano in UTC. Chi affianca ritrovamenti dal file system e dai log dovrebbe convertire tutte le indicazioni nello stesso fuso orario, altrimenti gli eventi sembrano non combaciare. Le patch sono uscite il 21 ottobre intorno alle 14:00 UTC, quindi alle 16:00 ora tedesca.
Trovare file modificati su Linux con find
Tutti i comandi leggono soltanto. Adatti percorso e data.
# Contenuto modificato dal 17.10.2026, ordinato, con mtime, ctime e proprietario
find /var/www -type f -newermt "2026-10-17" -printf '%TY-%Tm-%Td %TH:%TM %CY-%Cm-%Cd %CH:%CM %u %p\n' | sort
# Metadati modificati dal 17.10.2026 (trova anche i file retrodatati)
find /var/www -type f -newerct "2026-10-17" -printf '%C+ %T+ %p\n' | sort
# Escludere il rumore noto: cache, log, sessioni
find /var/www -type f -newerct "2026-10-17" \
-not -path "*/cache/*" -not -path "*/logs/*" -not -path "*/sessions/*" -printf '%C+ %p\n' | sort
# Guardare anche fuori dalla directory web
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
Per ogni risultato confronti entrambe le marcature temporali. Se la ctime è nettamente più recente della mtime e nessuno in quel periodo ha modificato permessi o copiato file, il file va nell'elenco. Faccia attenzione anche al proprietario: un file dell'utente del server web tra file dell'utente di deploy salta all'occhio.
Non dimentichi file e directory nascosti. I nomi che iniziano con un punto molti file manager e un semplice ls non li mostrano. Gli aggressori lo sfruttano volentieri, così come nomi molto simili a quelli di file veri.
# File e cartelle nascosti nella directory web, esclusi quelli noti come .htaccess e .git
find /var/www -name ".*" -not -name ".htaccess" -not -name ".well-known" -not -path "*/.git/*" -printf '%C+ %u %p\n' | sort
Confrontare con una fonte attendibile
Le marcature temporali mostrano dove qualcosa si è mosso. Se fosse una modifica legittima lo mostra solo il confronto con una fonte di cui ci si fida.
- Gestione dei pacchetti: per i file di sistema
dpkg --verify(Debian/Ubuntu) orpm -Va(famiglia RHEL) verificano i file rispetto alle somme di controllo dei pacchetti installati. I file di configurazione divergono legittimamente, i file di programma no. - Git: se l'applicazione si trova in un repository,
git -C /var/www/projekt status --porcelainmostra ogni scostamento dall'ultimo commit. - Somme di controllo del CMS: molti sistemi possono confrontare i propri file core con le somme di controllo ufficiali, vedi Confrontare i file core del CMS con l'originale.
- Backup precedente all'incidente: un confronto in prova elenca le differenze senza copiare nulla.
# Elencare soltanto le differenze tra lo stato del backup e il sistema live (prova, non copia nulla)
rsync -rcn --out-format="%n" /backup/www-2026-10-15/ /var/www/
Il confronto con il backup presuppone che il backup sia nato prima dell'incidente e non sia stato a sua volta modificato. Perché i backup conservati separatamente siano qui decisivi lo spiega Backup secondo la regola 3-2-1.
Salvi i risultati di ogni ricerca con la data in un file fuori dal server. Da questi elenchi nasce in seguito la cronologia dell'incidente, e documentano cosa ha verificato e quando.
Se non ci sono né backup né repository
In molti siti più piccoli non esiste una base di confronto pulita: niente Git, niente backup precedente all'incidente, plugin aggiornati a mano da anni. Senza alcun punto di riferimento, però, non è del tutto.
Scarichi dal produttore il CMS e le estensioni esattamente nelle versioni installate e confronti questi file con il server. Ciò che lì diverge o manca merita uno sguardo. Restano le Sue personalizzazioni, gli upload e la configurazione; qui aiuta la ricerca per marcature temporali, integrata da uno sguardo a proprietario e permessi. I file che sono gli unici in una directory ad avere un altro gruppo, altri permessi o una ctime nettamente più recente dei vicini vanno nell'elenco.
Detto onestamente: senza base di confronto resta un'incertezza residua. Nei sistemi con dati sensibili una ricostruzione da fonti pulite è allora spesso più affidabile della ricerca di ogni singolo file modificato. Per il futuro la lezione è semplice: un repository per il codice e backup regolari conservati separatamente.
Fonti di errore tipiche nella ricerca
- Esclusioni troppo generose: le cartelle di cache e di upload sono nascondigli apprezzati.
- Verificata solo la mtime: i file retrodatati sfuggono.
- Deployment nella finestra temporale: un normale rollout modifica centinaia di file e copre i singoli ritrovamenti. Confronti con il repository.
- File già aperti o copiati: le copie senza conservazione delle marcature temporali distruggono tracce. Conservi con strumenti che mantengono le marcature temporali.
- Cercato solo nella directory web: gli aggressori depositano strumenti anche in
/tmp,/dev/shmo nella home dell'utente del server web. - Modifiche ai permessi trascurate: un file i cui permessi consentono improvvisamente la scrittura a tutti è un ritrovamento, anche se il contenuto è invariato.
Come i ritrovamenti si compongano in uno svolgimento lo mostra Creare la cronologia di un incidente.
Come aiuta concretamente PHP SOS?
- Cercare in modo sistematico: esaminiamo directory web e percorsi di sistema alla ricerca di modifiche nella finestra temporale rilevante e valutiamo insieme mtime e ctime.
- Verificare rispetto agli originali: confrontiamo con pacchetti, repository, somme di controllo del CMS e i Suoi backup.
- Valutare i ritrovamenti: distinguiamo le modifiche regolari dalle manipolazioni e conserviamo le prove.
- Bonificare: con la rimozione del malware ripristiniamo uno stato pulito e lo documentiamo.
Domande frequenti
Come trovo tutti i file modificati da una certa data?
Con find e l'opzione -newermt, ad esempio find /var/www -type f -newermt "2026-10-17". Per le modifiche ai metadati usi -newerct. Entrambi i comandi leggono soltanto e non modificano nulla.
Qual è la differenza tra mtime e ctime?
mtime è il momento dell'ultima modifica del contenuto e si può retrodatare con mezzi semplici. ctime è il momento dell'ultima modifica di contenuto o metadati e non si falsifica così facilmente. Se i due differiscono molto, vale la pena guardare con attenzione.
Come escludo dalla ricerca i file di cache?
Con -not -path per le cartelle note di cache, log e sessioni. Non escluda però in modo troppo generoso, perché gli aggressori depositano volentieri file proprio dove molte modifiche sono normali.
Quale verifica è la più affidabile?
Il confronto con una fonte attendibile: somme di controllo della gestione dei pacchetti, un repository Git o un backup precedente all'incidente. Le marcature temporali sono un buon punto di partenza, ma non una prova.