Lasciatemi rispondere con alcune osservazioni e commenti. Inizierò con l'approccio "whodunit" di aiuto nel determinare chi, cosa, quando, dove e come.
-
Che - un file che hai trovato sul tuo sistema
-
Quando - quale data è stata trovata
-
Come - come è stato caricato
-
Chi - chi lo ha caricato
Conosci già il file perché lo hai trovato. Chiamiamo questo file: malicious.php. Quello che dici di fare è determinare " chi " ha avuto accesso a questo file, ma devi capire come è stato caricato. Guardare a chi ha avuto accesso a questo file è l'approccio sbagliato. Questo perché gli attaccanti di solito usano più punti di attacco. Ad esempio, un sistema potrebbe scansionarti, un altro potrebbe comprometterti, e un altro ancora potrebbe accedere al sistema compromesso. Quindi cerchiamo di capire chi prima utilizza i metodi deduttivi:
$ ls -ltha malicious.php
-rw-r--r-- 1 www-data www-data 0 Mar 27 10:59 malicious.php
In questo caso, vediamo che il file appartiene all'utente www-data nel gruppo www-data. Ciò non significa che un utente malintenzionato lo abbia caricato tramite http utilizzando post o get. Non c'è nulla che impedisca a qualcuno di sfruttare di dire telnet, caricare un file ed eseguire un chown sul file.
ls -ltha --time=atime malicious.php
-rw-r--r-- 1 www-data www-data 0 Apr 27 10:09 malicious.php
ls -ltha --time=ctime malicious.php
-rw-r--r-- 1 www-data www-data 0 Apr 27 11:00 malicious.php
Qui possiamo vedere le differenze nei timestamp. Se qualcuno ha usato dire timestomp (Metasploit) i tempi MAC possono essere cambiati. Quindi possiamo dedurre dai dati sopra, che siamo più o meno all'interno del regno dei 50 minuti. Assicuriamoci che questo utente non abbia mai effettuato l'accesso, per questo possiamo controllare i registri di wtmp, auth, ftp, ecc. Se questo utente non ha mai effettuato l'accesso, possiamo quindi dedurre che questo non è stato caricato in nessun altra moda al di fuori di HTTP.
Quando - abbiamo ridotto il periodo di tempo a un livello fino a un periodo di 51 minuti. I registri che vorrei esaminare sarebbero i log degli errori FIRST seguiti dal log di accesso. La ragione di ciò è semplice, in nessun momento un hacker sa esattamente come ottenere un file sul tuo sistema. Ciò significa che c'è stata una ricognizione di prova ed errore. Questo sarà nei tuoi log degli errori che compaiono come 404 o 403. Vorrei cercarli prima. Ora riduciamo ulteriormente la ricerca. Un'analisi di registro delle visite mostrerà ciò che è normale rispetto a ciò che potrebbe essere un'anomalia. Ad esempio, se la base del traffico va a dire index.html, rimuovere tutte quelle istanze e osservare le anomalie. Una volta determinato, hai determinato il come . Questo è completamente separato dal capire come hanno compomesso il tuo codice che sarebbe una domanda completamente diversa.