Iscriviti al webinar gratuito del 12 Maggio per diventare Forensic Analyst! Scopri di più
Corso Ethical Hacker: accedi alla promozione fino al 30 Aprile! Scopri di più
Quando un avversario compromette un sistema, una delle prime azioni è cercare credenziali archiviate in chiaro — o con protezione debole — all'interno del file system locale e delle condivisioni di rete. La tecnica T1552.001 – Credentials In Files appartiene alla tattica TA0006 (Credential Access), quella fase della kill chain in cui l'attaccante punta a raccogliere nomi utente e password per muoversi lateralmente, elevare i privilegi o mantenere la persistenza.
Il panorama dei file bersaglio è vasto: file .env con token API, configurazioni XML e JSON di applicazioni, script PowerShell con password hardcoded, profili di client FTP e mail, backup di macchine virtuali, credenziali Docker e Kubernetes, chiavi SSH e token AWS salvati in ~/.aws/credentials. Persino i Group Policy Preferences archiviati sui Domain Controller storicamente hanno esposto password in chiaro decrittabili con una chiave pubblica nota.
I numeri confermano la rilevanza operativa: 14 gruppi APT documentati, 18 software tra malware e tool offensivi, 2 campagne tracciate e 4 mitigazioni raccomandate. La tecnica attraversa ogni settore — finance, healthcare, energy, education — e ogni piattaforma: Windows, Linux, macOS, container e ambienti IaaS cloud.
Il modo più rapido per simulare questa tecnica in laboratorio è partire da ciò che fanno davvero gli attaccanti: cercare pattern ricorrenti nei file di configurazione. Su una macchina Windows compromessa, un primo passaggio con findstr consente di scandagliare intere directory alla ricerca di stringhe sospette:
findstr /si "password=" C:\Users\*.xml C:\Users\*.ini C:\Users\*.txt C:\Users\*.cfg
Questo comando cerca ricorsivamente (/s) senza distinzione maiuscole/minuscole (/i) la stringa password= nei file con le estensioni più comuni. In un assessment reale è utile estendere la ricerca ai file .env, .ps1 e .config, dove spesso si annidano credenziali di deployment.
Su Linux la controparte è altrettanto immediata. Con grep si perlustrano le home directory e le configurazioni di sistema:
grep -ri "password|secret|token" /home/ /etc/ /opt/ --include="*.conf" --include="*.env" --include="*.yml" 2>/dev/null
Per i contesti cloud e container — come quelli colpiti da TeamTNT — vale la pena cercare esplicitamente credenziali AWS e Docker:
cat ~/.aws/credentials 2>/dev/null; cat ~/.docker/config.json 2>/dev/null; find / -name ".kubeconfig" 2>/dev/null*
Il tool più utilizzato dai gruppi APT documentati è senza dubbio LaZagne (open source), impiegato da APT33, Leafminer, OilRig e RedCurl. In laboratorio si lancia con un singolo comando:
lazagne.exe all
LaZagne interroga i credential store di browser, client email, client FTP, database, Wi-Fi e chat, restituendo un report unificato. Per un assessment più strutturato, PoshC2 (open source) offre moduli dedicati alla ricerca di password in file locali e remoti, mentre Empire (open source) mette a disposizione moduli specifici per enumerare file contenenti credenziali su host Windows.
Su macOS il vettore principale è il Keychain, ma non va trascurata la ricerca nei plist e nei file di configurazione:
grep -ri "password" ~/Library/Preferences/ 2>/dev/null
Un aspetto spesso ignorato nei test è la verifica dei file di log dei container. In ambienti Kubernetes, i parametri di deployment possono contenere secret passati come argomento da riga di comando, visibili nei log del pod. Il comando kubectl logs
Per simulare lo scenario della campagna SharePoint ToolShell Exploitation (C0058), si può verificare l'accesso ai file web.config e machine.config di un'installazione SharePoint on-premises, dove i valori MachineKey sono spesso archiviati in chiaro.
Scarica la guida gratuita e segui il percorso corretto fin dal primo passo