From 9588c355ab770baaebdda7912bd5040735f00e65 Mon Sep 17 00:00:00 2001 From: Translator Date: Thu, 21 Aug 2025 02:33:32 +0000 Subject: [PATCH] Translated ['', 'src/generic-methodologies-and-resources/basic-forensic- --- .../anti-forensic-techniques.md | 99 ++++++++++++++++--- .../linux-forensics.md | 80 ++++++++++----- 2 files changed, 142 insertions(+), 37 deletions(-) diff --git a/src/generic-methodologies-and-resources/basic-forensic-methodology/anti-forensic-techniques.md b/src/generic-methodologies-and-resources/basic-forensic-methodology/anti-forensic-techniques.md index bb645e8a3..02ccbadf6 100644 --- a/src/generic-methodologies-and-resources/basic-forensic-methodology/anti-forensic-techniques.md +++ b/src/generic-methodologies-and-resources/basic-forensic-methodology/anti-forensic-techniques.md @@ -11,13 +11,13 @@ Entrambi gli attributi hanno 4 timestamp: **Modifica**, **accesso**, **creazione **Esplora file di Windows** e altri strumenti mostrano le informazioni da **`$STANDARD_INFORMATION`**. -### TimeStomp - Strumento anti-forense +### TimeStomp - Strumento Anti-forense Questo strumento **modifica** le informazioni sui timestamp all'interno di **`$STANDARD_INFORMATION`** **ma** **non** le informazioni all'interno di **`$FILE_NAME`**. Pertanto, è possibile **identificare** **attività** **sospette**. ### Usnjrnl -Il **USN Journal** (Update Sequence Number Journal) è una funzionalità del NTFS (sistema di file Windows NT) che tiene traccia delle modifiche al volume. Lo strumento [**UsnJrnl2Csv**](https://github.com/jschicht/UsnJrnl2Csv) consente di esaminare queste modifiche. +Il **USN Journal** (Registro del Numero di Sequenza di Aggiornamento) è una funzionalità del NTFS (sistema di file Windows NT) che tiene traccia delle modifiche al volume. Lo strumento [**UsnJrnl2Csv**](https://github.com/jschicht/UsnJrnl2Csv) consente di esaminare queste modifiche. ![](<../../images/image (801).png>) @@ -48,7 +48,7 @@ Un altro modo per identificare file modificati sospetti sarebbe confrontare il t I timestamp **NTFS** hanno una **precisione** di **100 nanosecondi**. Quindi, trovare file con timestamp come 2010-10-10 10:10:**00.000:0000 è molto sospetto**. -### SetMace - Strumento anti-forense +### SetMace - Strumento Anti-forense Questo strumento può modificare entrambi gli attributi `$STARNDAR_INFORMATION` e `$FILE_NAME`. Tuttavia, a partire da Windows Vista, è necessario un OS live per modificare queste informazioni. @@ -100,7 +100,7 @@ Questo salverà informazioni sulle applicazioni eseguite con l'obiettivo di migl ### Disabilitare Timestamp - Ultimo Tempo di Accesso -Ogni volta che una cartella viene aperta da un volume NTFS su un server Windows NT, il sistema prende il tempo per **aggiornare un campo di timestamp su ciascuna cartella elencata**, chiamato ultimo tempo di accesso. Su un volume NTFS molto utilizzato, questo può influire sulle prestazioni. +Ogni volta che una cartella viene aperta da un volume NTFS su un server Windows NT, il sistema impiega tempo per **aggiornare un campo di timestamp su ciascuna cartella elencata**, chiamato ultimo tempo di accesso. Su un volume NTFS molto utilizzato, questo può influire sulle prestazioni. 1. Aprire l'Editor del Registro (Regedit.exe). 2. Navigare a `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem`. @@ -109,7 +109,7 @@ Ogni volta che una cartella viene aperta da un volume NTFS su un server Windows ### Eliminare la Cronologia USB -Tutti i **USB Device Entries** sono memorizzati nel Registro di Windows sotto la chiave di registro **USBSTOR** che contiene sottochiavi create ogni volta che si collega un dispositivo USB al PC o Laptop. Puoi trovare questa chiave qui `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USBSTOR`. **Eliminando questa** eliminerai la cronologia USB.\ +Tutti gli **USB Device Entries** sono memorizzati nel Registro di Windows sotto la chiave di registro **USBSTOR** che contiene sottochiavi create ogni volta che si collega un dispositivo USB al PC o Laptop. Puoi trovare questa chiave qui `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USBSTOR`. **Eliminando questa** eliminerai la cronologia USB.\ Puoi anche utilizzare lo strumento [**USBDeview**](https://www.nirsoft.net/utils/usb_devices_view.html) per essere sicuro di averle eliminate (e per eliminarle). Un altro file che salva informazioni sugli USB è il file `setupapi.dev.log` all'interno di `C:\Windows\INF`. Questo dovrebbe essere eliminato. @@ -143,7 +143,7 @@ Per disabilitare le copie shadow [passaggi da qui](https://support.waters.com/KB ### Disabilitare i registri eventi di Windows - `reg add 'HKLM\\SYSTEM\\CurrentControlSet\\Services\\eventlog' /v Start /t REG_DWORD /d 4 /f` -- All'interno della sezione servizi disabilitare il servizio "Windows Event Log" +- All'interno della sezione servizi disabilitare il servizio "Registro eventi di Windows" - `WEvtUtil.exec clear-log` o `WEvtUtil.exe cl` ### Disabilitare $UsnJrnl @@ -154,7 +154,7 @@ Per disabilitare le copie shadow [passaggi da qui](https://support.waters.com/KB ## Logging Avanzato & Manomissione delle Tracce (2023-2025) -### Logging ScriptBlock/Module di PowerShell +### Logging di ScriptBlock/Modulo PowerShell Le versioni recenti di Windows 10/11 e Windows Server mantengono **artifacts forensi PowerShell ricchi** sotto `Microsoft-Windows-PowerShell/Operational` (eventi 4104/4105/4106). @@ -182,7 +182,7 @@ WriteProcessMemory(GetCurrentProcess(), GetProcAddress(GetModuleHandleA("ntdll.dll"), "EtwEventWrite"), patch, sizeof(patch), NULL); ``` -Public PoCs (e.g. `EtwTiSwallow`) implementano la stessa primitiva in PowerShell o C++. +Public PoCs (e.g. `EtwTiSwallow`) implement the same primitive in PowerShell o C++. Poiché la patch è **locale al processo**, gli EDR che girano all'interno di altri processi potrebbero non rilevarla. Rilevamento: confrontare `ntdll` in memoria rispetto a quello su disco, o hookare prima della modalità utente. @@ -209,11 +209,88 @@ Mitigazioni: abilitare la blocklist dei driver vulnerabili di Microsoft (HVCI/SA --- -## Riferimenti +## Linux Anti-Forensics: Auto-patch e Cloud C2 (2023–2025) -- Sophos X-Ops – “AuKill: A Weaponized Vulnerable Driver for Disabling EDR” (marzo 2023) +### Auto-patching dei servizi compromessi per ridurre la rilevazione (Linux) +Gli avversari "auto-patchano" sempre più spesso un servizio subito dopo averlo sfruttato per prevenire ulteriori sfruttamenti e sopprimere le rilevazioni basate su vulnerabilità. L'idea è di sostituire i componenti vulnerabili con gli ultimi binari/JAR legittimi upstream, in modo che gli scanner segnalino l'host come patchato mentre la persistenza e il C2 rimangono. + +Esempio: Apache ActiveMQ OpenWire RCE (CVE‑2023‑46604) +- Dopo lo sfruttamento, gli attaccanti hanno prelevato JAR legittimi da Maven Central (repo1.maven.org), eliminato i JAR vulnerabili nell'installazione di ActiveMQ e riavviato il broker. +- Questo ha chiuso il RCE iniziale mantenendo altri punti di accesso (cron, modifiche alla configurazione SSH, impianti C2 separati). + +Esempio operativo (illustrativo) +```bash +# ActiveMQ install root (adjust as needed) +AMQ_DIR=/opt/activemq +cd "$AMQ_DIR"/lib + +# Fetch patched JARs from Maven Central (versions as appropriate) +curl -fsSL -O https://repo1.maven.org/maven2/org/apache/activemq/activemq-client/5.18.3/activemq-client-5.18.3.jar +curl -fsSL -O https://repo1.maven.org/maven2/org/apache/activemq/activemq-openwire-legacy/5.18.3/activemq-openwire-legacy-5.18.3.jar + +# Remove vulnerable files and ensure the service uses the patched ones +rm -f activemq-client-5.18.2.jar activemq-openwire-legacy-5.18.2.jar || true +ln -sf activemq-client-5.18.3.jar activemq-client.jar +ln -sf activemq-openwire-legacy-5.18.3.jar activemq-openwire-legacy.jar + +# Apply changes without removing persistence +systemctl restart activemq || service activemq restart +``` +Forensic/hunting tips +- Rivedere le directory di servizio per sostituzioni binarie/JAR non programmate: +- Debian/Ubuntu: `dpkg -V activemq` e confrontare gli hash/percorsi dei file con i mirror del repository. +- RHEL/CentOS: `rpm -Va 'activemq*'` +- Cercare versioni JAR presenti su disco che non sono di proprietà del gestore di pacchetti, o collegamenti simbolici aggiornati fuori banda. +- Timeline: `find "$AMQ_DIR" -type f -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort` per correlare ctime/mtime con la finestra di compromissione. +- Cronologia della shell/telemetria dei processi: prove di `curl`/`wget` a `repo1.maven.org` o altri CDN di artefatti immediatamente dopo l'iniziale sfruttamento. +- Gestione delle modifiche: convalidare chi ha applicato la “patch” e perché, non solo che una versione patchata è presente. + +### Cloud‑service C2 con bearer tokens e anti‑analysis stagers +Il tradecraft osservato ha combinato più percorsi C2 a lungo termine e imballaggi anti-analisi: +- Loader ELF PyInstaller protetti da password per ostacolare il sandboxing e l'analisi statica (ad es., PYZ crittografato, estrazione temporanea sotto `/_MEI*`). +- Indicatori: colpi di `strings` come `PyInstaller`, `pyi-archive`, `PYZ-00.pyz`, `MEIPASS`. +- Artefatti di runtime: estrazione in `/tmp/_MEI*` o percorsi personalizzati `--runtime-tmpdir`. +- C2 supportato da Dropbox utilizzando token OAuth Bearer hardcoded +- Marcatori di rete: `api.dropboxapi.com` / `content.dropboxapi.com` con `Authorization: Bearer `. +- Caccia in proxy/NetFlow/Zeek/Suricata per HTTPS in uscita verso domini Dropbox da carichi di lavoro del server che normalmente non sincronizzano file. +- C2 parallelo/di backup tramite tunneling (ad es., Cloudflare Tunnel `cloudflared`), mantenendo il controllo se un canale è bloccato. +- IOCs host: processi/unità `cloudflared`, configurazione in `~/.cloudflared/*.json`, uscita 443 verso gli edge di Cloudflare. + +### Persistenza e “rollback di indurimento” per mantenere l'accesso (esempi Linux) +Gli attaccanti abbinano frequentemente l'auto-patching con percorsi di accesso durevoli: +- Cron/Anacron: modifiche allo stub `0anacron` in ciascuna directory `/etc/cron.*/` per esecuzione periodica. +- Caccia: +```bash +for d in /etc/cron.*; do [ -f "$d/0anacron" ] && stat -c '%n %y %s' "$d/0anacron"; done +grep -R --line-number -E 'curl|wget|python|/bin/sh' /etc/cron.*/* 2>/dev/null +``` +- Rollback dell'indurimento della configurazione SSH: abilitazione degli accessi root e modifica delle shell predefinite per account a bassa privilegio. +- Caccia per l'abilitazione del login root: +```bash +grep -E '^\s*PermitRootLogin' /etc/ssh/sshd_config +# valori di flag come "yes" o impostazioni eccessivamente permissive +``` +- Caccia per shell interattive sospette su account di sistema (ad es., `games`): +```bash +awk -F: '($7 ~ /bin\/(sh|bash|zsh)/ && $1 ~ /^(games|lp|sync|shutdown|halt|mail|operator)$/) {print}' /etc/passwd +``` +- Artefatti beacon casuali e con nomi brevi (8 caratteri alfabetici) lasciati su disco che contattano anche C2 cloud: +- Caccia: +```bash +find / -maxdepth 3 -type f -regextype posix-extended -regex '.*/[A-Za-z]{8}$' \ +-exec stat -c '%n %s %y' {} \; 2>/dev/null | sort +``` + +I difensori dovrebbero correlare questi artefatti con esposizioni esterne ed eventi di patching dei servizi per scoprire l'auto-remediazione anti-forense utilizzata per nascondere lo sfruttamento iniziale. + +## References + +- Sophos X-Ops – “AuKill: A Weaponized Vulnerable Driver for Disabling EDR” (March 2023) https://news.sophos.com/en-us/2023/03/07/aukill-a-weaponized-vulnerable-driver-for-disabling-edr -- Red Canary – “Patching EtwEventWrite for Stealth: Detection & Hunting” (giugno 2024) +- Red Canary – “Patching EtwEventWrite for Stealth: Detection & Hunting” (June 2024) https://redcanary.com/blog/etw-patching-detection +- [Red Canary – Patching for persistence: How DripDropper Linux malware moves through the cloud](https://redcanary.com/blog/threat-intelligence/dripdropper-linux-malware/) +- [CVE‑2023‑46604 – Apache ActiveMQ OpenWire RCE (NVD)](https://nvd.nist.gov/vuln/detail/CVE-2023-46604) + {{#include ../../banners/hacktricks-training.md}} diff --git a/src/generic-methodologies-and-resources/basic-forensic-methodology/linux-forensics.md b/src/generic-methodologies-and-resources/basic-forensic-methodology/linux-forensics.md index 3481a64b0..8058002b4 100644 --- a/src/generic-methodologies-and-resources/basic-forensic-methodology/linux-forensics.md +++ b/src/generic-methodologies-and-resources/basic-forensic-methodology/linux-forensics.md @@ -6,12 +6,12 @@ ### Informazioni di Base -Prima di tutto, è consigliato avere una **USB** con **binaries e librerie ben noti** (puoi semplicemente prendere ubuntu e copiare le cartelle _/bin_, _/sbin_, _/lib,_ e _/lib64_), poi monta la USB e modifica le variabili di ambiente per utilizzare quei binaries: +Prima di tutto, è consigliato avere una **USB** con **binaries e librerie ben noti** (puoi semplicemente prendere ubuntu e copiare le cartelle _/bin_, _/sbin_, _/lib,_ e _/lib64_), poi monta la USB e modifica le variabili d'ambiente per utilizzare quei binaries: ```bash export PATH=/mnt/usb/bin:/mnt/usb/sbin export LD_LIBRARY_PATH=/mnt/usb/lib:/mnt/usb/lib64 ``` -Una volta configurato il sistema per utilizzare binari buoni e conosciuti, puoi iniziare a **estrarre alcune informazioni di base**: +Una volta che hai configurato il sistema per utilizzare binari buoni e noti, puoi iniziare a **estrarre alcune informazioni di base**: ```bash date #Date and time (Clock may be skewed, Might be at a different timezone) uname -a #OS info @@ -42,10 +42,10 @@ Durante l'ottenimento delle informazioni di base, dovresti controllare cose stra Per ottenere la memoria del sistema in esecuzione, è consigliato utilizzare [**LiME**](https://github.com/504ensicsLabs/LiME).\ Per **compilarlo**, devi utilizzare lo **stesso kernel** che la macchina vittima sta utilizzando. -> [!NOTE] +> [!TIP] > Ricorda che **non puoi installare LiME o qualsiasi altra cosa** nella macchina vittima poiché apporterà diverse modifiche ad essa -Quindi, se hai una versione identica di Ubuntu puoi usare `apt-get install lime-forensics-dkms`\ +Quindi, se hai una versione identica di Ubuntu, puoi usare `apt-get install lime-forensics-dkms`\ In altri casi, devi scaricare [**LiME**](https://github.com/504ensicsLabs/LiME) da github e compilarlo con le intestazioni del kernel corrette. Per **ottenere le intestazioni esatte del kernel** della macchina vittima, puoi semplicemente **copiare la directory** `/lib/modules/` sulla tua macchina, e poi **compilare** LiME utilizzando quelle: ```bash make -C /lib/modules//build M=$PWD @@ -64,11 +64,11 @@ LiME può anche essere utilizzato per **inviare il dump tramite rete** invece di #### Spegnimento Prima di tutto, è necessario **spegnere il sistema**. Questo non è sempre un'opzione poiché a volte il sistema sarà un server di produzione che l'azienda non può permettersi di spegnere.\ -Ci sono **2 modi** per spegnere il sistema, un **spegnimento normale** e uno **spegnimento "stacca la spina"**. Il primo permetterà ai **processi di terminare come al solito** e al **filesystem** di essere **synchronizzato**, ma permetterà anche al possibile **malware** di **distruggere le prove**. L'approccio "stacca la spina" può comportare **alcuna perdita di informazioni** (non molte informazioni andranno perse poiché abbiamo già preso un'immagine della memoria) e il **malware non avrà alcuna opportunità** di fare qualcosa al riguardo. Pertanto, se **sospetti** che ci possa essere un **malware**, esegui semplicemente il **comando** **`sync`** sul sistema e stacca la spina. +Ci sono **2 modi** per spegnere il sistema, un **spegnimento normale** e uno **spegnimento "stacca la spina"**. Il primo permetterà ai **processi di terminare come al solito** e al **filesystem** di essere **synchronizzato**, ma permetterà anche al possibile **malware** di **distruggere le prove**. L'approccio "stacca la spina" può comportare **una certa perdita di informazioni** (non molte informazioni andranno perse poiché abbiamo già preso un'immagine della memoria) e il **malware non avrà alcuna opportunità** di fare qualcosa al riguardo. Pertanto, se **sospetti** che ci possa essere un **malware**, esegui semplicemente il **comando** **`sync`** sul sistema e stacca la spina. #### Prendere un'immagine del disco -È importante notare che **prima di collegare il computer a qualsiasi cosa relativa al caso**, è necessario essere certi che verrà **montato come sola lettura** per evitare di modificare qualsiasi informazione. +È importante notare che **prima di collegare il computer a qualsiasi cosa relativa al caso**, è necessario essere certi che verrà **montato in sola lettura** per evitare di modificare qualsiasi informazione. ```bash #Create a raw copy of the disk dd if= of= bs=512 @@ -143,7 +143,7 @@ Linux offre strumenti per garantire l'integrità dei componenti di sistema, fond ### Rilevatori di Malware/Rootkit -Leggi la pagina seguente per conoscere gli strumenti che possono essere utili per trovare malware: +Leggi la seguente pagina per conoscere gli strumenti che possono essere utili per trovare malware: {{#ref}} malware-analysis.md @@ -172,9 +172,9 @@ find /sbin/ –exec rpm -qf {} \; | grep "is not" # Find exacuable files find / -type f -executable | grep ``` -## Recuperare Binaries Eseguiti Cancellati +## Recuperare Binarie Eseguite Cancellate -Immagina un processo che è stato eseguito da /tmp/exec e poi cancellato. È possibile estrarlo. +Immagina un processo che è stato eseguito da /tmp/exec e poi cancellato. È possibile estrarlo ```bash cd /proc/3746/ #PID with the exec file deleted head -1 maps #Get address of the file. It was 08048000-08049000 @@ -196,6 +196,32 @@ cat /var/spool/cron/crontabs/* \ #MacOS ls -l /usr/lib/cron/tabs/ /Library/LaunchAgents/ /Library/LaunchDaemons/ ~/Library/LaunchAgents/ ``` +#### Hunt: Abuso di Cron/Anacron tramite 0anacron e stub sospetti +Gli attaccanti spesso modificano lo stub 0anacron presente in ciascuna directory /etc/cron.*/ per garantire l'esecuzione periodica. +```bash +# List 0anacron files and their timestamps/sizes +for d in /etc/cron.*; do [ -f "$d/0anacron" ] && stat -c '%n %y %s' "$d/0anacron"; done + +# Look for obvious execution of shells or downloaders embedded in cron stubs +grep -R --line-number -E 'curl|wget|/bin/sh|python|bash -c' /etc/cron.*/* 2>/dev/null +``` +#### Hunt: SSH hardening rollback and backdoor shells +Le modifiche a sshd_config e alle shell degli account di sistema sono comuni dopo l'exploitation per preservare l'accesso. +```bash +# Root login enablement (flag "yes" or lax values) +grep -E '^\s*PermitRootLogin' /etc/ssh/sshd_config + +# System accounts with interactive shells (e.g., games → /bin/sh) +awk -F: '($7 ~ /bin\/(sh|bash|zsh)/ && $1 ~ /^(games|lp|sync|shutdown|halt|mail|operator)$/) {print}' /etc/passwd +``` +#### Hunt: Cloud C2 markers (Dropbox/Cloudflare Tunnel) +- I beacon dell'API di Dropbox utilizzano tipicamente api.dropboxapi.com o content.dropboxapi.com su HTTPS con token di autorizzazione: Bearer. +- Cerca in proxy/Zeek/NetFlow per egress inaspettati di Dropbox dai server. +- Cloudflare Tunnel (`cloudflared`) fornisce C2 di backup su 443 in uscita. +```bash +ps aux | grep -E '[c]loudflared|trycloudflare' +systemctl list-units | grep -i cloudflared +``` ### Servizi Percorsi in cui un malware potrebbe essere installato come servizio: @@ -207,12 +233,12 @@ Percorsi in cui un malware potrebbe essere installato come servizio: - **/etc/systemd/system**: Una directory per gli script del gestore di sistema e servizi. - **/etc/systemd/system/multi-user.target.wants/**: Contiene collegamenti ai servizi che dovrebbero essere avviati in un livello di esecuzione multi-utente. - **/usr/local/etc/rc.d/**: Per servizi personalizzati o di terze parti. -- **\~/.config/autostart/**: Per applicazioni di avvio automatico specifiche per l'utente, che possono essere un nascondiglio per malware mirati all'utente. +- **\~/.config/autostart/**: Per applicazioni di avvio automatico specifiche dell'utente, che possono essere un nascondiglio per malware mirati all'utente. - **/lib/systemd/system/**: File di unità predefiniti a livello di sistema forniti dai pacchetti installati. ### Moduli del Kernel -I moduli del kernel Linux, spesso utilizzati dal malware come componenti rootkit, vengono caricati all'avvio del sistema. Le directory e i file critici per questi moduli includono: +I moduli del kernel Linux, spesso utilizzati dai malware come componenti rootkit, vengono caricati all'avvio del sistema. Le directory e i file critici per questi moduli includono: - **/lib/modules/$(uname -r)**: Contiene moduli per la versione del kernel in esecuzione. - **/etc/modprobe.d**: Contiene file di configurazione per controllare il caricamento dei moduli. @@ -220,10 +246,10 @@ I moduli del kernel Linux, spesso utilizzati dal malware come componenti rootkit ### Altre Posizioni di Avvio Automatico -Linux utilizza vari file per eseguire automaticamente programmi al momento del login dell'utente, potenzialmente ospitando malware: +Linux utilizza vari file per eseguire automaticamente programmi al login dell'utente, potenzialmente ospitando malware: - **/etc/profile.d/**\*, **/etc/profile**, e **/etc/bash.bashrc**: Eseguiti per qualsiasi login utente. -- **\~/.bashrc**, **\~/.bash_profile**, **\~/.profile**, e **\~/.config/autostart**: File specifici per l'utente che vengono eseguiti al loro login. +- **\~/.bashrc**, **\~/.bash_profile**, **\~/.profile**, e **\~/.config/autostart**: File specifici dell'utente che vengono eseguiti al loro login. - **/etc/rc.local**: Viene eseguito dopo che tutti i servizi di sistema sono stati avviati, segnando la fine della transizione a un ambiente multiutente. ## Esaminare i Log @@ -231,23 +257,23 @@ Linux utilizza vari file per eseguire automaticamente programmi al momento del l I sistemi Linux tracciano le attività degli utenti e gli eventi di sistema attraverso vari file di log. Questi log sono fondamentali per identificare accessi non autorizzati, infezioni da malware e altri incidenti di sicurezza. I file di log chiave includono: - **/var/log/syslog** (Debian) o **/var/log/messages** (RedHat): Catturano messaggi e attività a livello di sistema. -- **/var/log/auth.log** (Debian) o **/var/log/secure** (RedHat): Registrano i tentativi di autenticazione, accessi riusciti e falliti. +- **/var/log/auth.log** (Debian) o **/var/log/secure** (RedHat): Registrano tentativi di autenticazione, accessi riusciti e falliti. - Usa `grep -iE "session opened for|accepted password|new session|not in sudoers" /var/log/auth.log` per filtrare eventi di autenticazione rilevanti. - **/var/log/boot.log**: Contiene messaggi di avvio del sistema. -- **/var/log/maillog** o **/var/log/mail.log**: Registra le attività del server di posta, utile per tracciare i servizi legati alla posta elettronica. +- **/var/log/maillog** o **/var/log/mail.log**: Registra le attività del server di posta, utile per tracciare servizi legati alla posta elettronica. - **/var/log/kern.log**: Memorizza messaggi del kernel, inclusi errori e avvisi. - **/var/log/dmesg**: Contiene messaggi del driver del dispositivo. -- **/var/log/faillog**: Registra i tentativi di accesso falliti, utile per le indagini su violazioni della sicurezza. +- **/var/log/faillog**: Registra tentativi di accesso falliti, utile per indagini su violazioni della sicurezza. - **/var/log/cron**: Registra le esecuzioni dei job cron. - **/var/log/daemon.log**: Traccia le attività dei servizi in background. -- **/var/log/btmp**: Documenta i tentativi di accesso falliti. +- **/var/log/btmp**: Documenta tentativi di accesso falliti. - **/var/log/httpd/**: Contiene log di errore e accesso di Apache HTTPD. - **/var/log/mysqld.log** o **/var/log/mysql.log**: Registra le attività del database MySQL. -- **/var/log/xferlog**: Registra i trasferimenti di file FTP. +- **/var/log/xferlog**: Registra trasferimenti di file FTP. - **/var/log/**: Controlla sempre per log inaspettati qui. -> [!NOTE] -> I log di sistema Linux e i sottosistemi di audit potrebbero essere disabilitati o eliminati in un'intrusione o in un incidente di malware. Poiché i log sui sistemi Linux contengono generalmente alcune delle informazioni più utili sulle attività dannose, gli intrusi li eliminano regolarmente. Pertanto, quando si esaminano i file di log disponibili, è importante cercare lacune o voci fuori ordine che potrebbero essere un'indicazione di eliminazione o manomissione. +> [!TIP] +> I log di sistema Linux e i sottosistemi di audit possono essere disabilitati o eliminati in un incidente di intrusione o malware. Poiché i log sui sistemi Linux contengono generalmente alcune delle informazioni più utili sulle attività malevole, gli intrusi li eliminano di routine. Pertanto, quando si esaminano i file di log disponibili, è importante cercare lacune o voci fuori ordine che potrebbero essere un'indicazione di eliminazione o manomissione. **Linux mantiene una cronologia dei comandi per ogni utente**, memorizzata in: @@ -301,13 +327,13 @@ More examples and info inside the github: [https://github.com/snovvcrash/usbrip] ## Rivedere gli Account Utente e le Attività di Accesso -Esaminare il _**/etc/passwd**_, _**/etc/shadow**_ e i **log di sicurezza** per nomi o account insoliti creati e/o utilizzati in prossimità di eventi non autorizzati noti. Inoltre, controllare possibili attacchi di brute-force sudo.\ +Esaminare il _**/etc/passwd**_, _**/etc/shadow**_ e i **log di sicurezza** per nomi o account insoliti creati e/o utilizzati in prossimità di eventi non autorizzati noti. Inoltre, controllare possibili attacchi di brute-force su sudo.\ Inoltre, controllare file come _**/etc/sudoers**_ e _**/etc/groups**_ per privilegi inaspettati concessi agli utenti.\ Infine, cercare account con **nessuna password** o **password facilmente indovinabili**. ## Esaminare il File System -### Analizzare le Strutture del File System nell'Investigazione di Malware +### Analisi delle Strutture del File System nell'Investigazione di Malware Quando si indagano incidenti di malware, la struttura del file system è una fonte cruciale di informazioni, rivelando sia la sequenza degli eventi che il contenuto del malware. Tuttavia, gli autori di malware stanno sviluppando tecniche per ostacolare questa analisi, come modificare i timestamp dei file o evitare il file system per l'archiviazione dei dati. @@ -316,10 +342,10 @@ Per contrastare questi metodi anti-forensi, è essenziale: - **Condurre un'analisi approfondita della timeline** utilizzando strumenti come **Autopsy** per visualizzare le timeline degli eventi o `mactime` di **Sleuth Kit** per dati dettagliati sulla timeline. - **Indagare su script inaspettati** nel $PATH del sistema, che potrebbero includere script shell o PHP utilizzati dagli attaccanti. - **Esaminare `/dev` per file atipici**, poiché tradizionalmente contiene file speciali, ma potrebbe ospitare file relativi al malware. -- **Cercare file o directory nascosti** con nomi come ".. " (punto punto spazio) o "..^G" (punto punto controllo-G), che potrebbero nascondere contenuti dannosi. +- **Cercare file o directory nascosti** con nomi come ".. " (punto punto spazio) o "..^G" (punto punto controllo-G), che potrebbero nascondere contenuti malevoli. - **Identificare file setuid root** utilizzando il comando: `find / -user root -perm -04000 -print` Questo trova file con permessi elevati, che potrebbero essere abusati dagli attaccanti. -- **Rivedere i timestamp di cancellazione** nelle tabelle inode per individuare cancellazioni di massa di file, che potrebbero indicare la presenza di rootkit o trojan. -- **Ispezionare inode consecutivi** per file dannosi vicini dopo averne identificato uno, poiché potrebbero essere stati collocati insieme. +- **Rivedere i timestamp di cancellazione** nelle tabelle degli inode per individuare cancellazioni di massa di file, che potrebbero indicare la presenza di rootkit o trojan. +- **Ispezionare inode consecutivi** per file malevoli vicini dopo averne identificato uno, poiché potrebbero essere stati collocati insieme. - **Controllare le directory binarie comuni** (_/bin_, _/sbin_) per file recentemente modificati, poiché questi potrebbero essere stati alterati da malware. ````bash # List recent files in a directory: @@ -328,7 +354,7 @@ ls -laR --sort=time /bin``` # Sort files in a directory by inode: ls -lai /bin | sort -n``` ```` -> [!NOTE] +> [!TIP] > Nota che un **attaccante** può **modificare** il **tempo** per far **apparire** i **file** **legittimi**, ma non può **modificare** l'**inode**. Se scopri che un **file** indica che è stato creato e modificato allo **stesso tempo** degli altri file nella stessa cartella, ma l'**inode** è **inaspettatamente più grande**, allora i **timestamp di quel file sono stati modificati**. ## Confronta file di diverse versioni del filesystem @@ -367,4 +393,6 @@ git diff --no-index --diff-filter=D path/to/old_version/ path/to/new_version/ - [https://git-scm.com/docs/git-diff#Documentation/git-diff.txt---diff-filterACDMRTUXB82308203](https://git-scm.com/docs/git-diff#Documentation/git-diff.txt---diff-filterACDMRTUXB82308203) - **Libro: Malware Forensics Field Guide for Linux Systems: Digital Forensics Field Guides** +- [Red Canary – Patching for persistence: How DripDropper Linux malware moves through the cloud](https://redcanary.com/blog/threat-intelligence/dripdropper-linux-malware/) + {{#include ../../banners/hacktricks-training.md}}