Deturpamento di Siti Web Esterni: External Defacement (T1491.002)

La simulazione di un External Defacement in laboratorio richiede un ambiente controllato con un web server sacrificabile — mai testare su asset esposti a Internet. L'obiettivo è validare la capacità del Blue Team di rilevare la modifica dei file nella web root e attivare le procedure di ripristino.

Il percorso d'attacco più realistico parte dall'accesso iniziale al server. Su un ambiente Windows con IIS, dopo aver ottenuto una shell tramite una web shell caricata sfruttando un upload non filtrato, la sostituzione della home page è banale:

copy C:\staging\defaced.html C:\inetpub\wwwroot\index.html /Y

Su Linux con Apache o Nginx, lo scenario equivalente prevede la scrittura diretta nella web root dopo aver ottenuto accesso SSH o RCE:

cp /tmp/defaced.html /var/www/html/index.html

Per simulare uno scenario cloud, è possibile replicare l'attacco su un bucket S3 configurato come sito statico utilizzando la CLI di AWS (open source):

aws s3 cp defaced.html s3://nome-bucket-target/index.html

Questo comando presuppone credenziali IAM con permessi di scrittura sul bucket — scenario coerente con il vettore documentato nella detection AN1625, che descrive l'abuso di ruoli cross-account o policy con privilegi eccessivi.

Per rendere la simulazione più completa, è utile concatenare le fasi. Con Nikto (open source), si può prima identificare la vulnerabilità di upload sul target. Successivamente, si carica una web shell minimale — ad esempio tramite curl — e da lì si esegue la sostituzione. In ambiente lab, DVWA (Damn Vulnerable Web Application, open source) offre un contesto perfetto per esercitarsi sul file upload che precede il defacement.

Un aspetto spesso trascurato nei test è la persistenza del defacement: l'avversario reale modifica non solo la pagina principale ma anche i template del CMS, i file di configurazione del tema, o inietta JavaScript nei footer condivisi. In un esercizio red team, dopo la sostituzione della index, provate a modificare anche un file CSS o JS condiviso per verificare se il Blue Team rileva solo il cambiamento macroscopico o anche le alterazioni sottili.

Per il reporting, documentate la catena completa: vettore di accesso iniziale, privilege escalation eventuale, modifica dei file, e tempo trascorso prima della detection. Questo dato è il vero deliverable dell'esercizio.

Il defacement esterno è una tecnica di Impact — quando lo rilevi, l'intrusione è già avvenuta. L'obiettivo del SOC non è quindi prevenire la modifica del file, ma ridurre al minimo il tempo di esposizione del contenuto alterato e ricostruire rapidamente il vettore d'accesso.

La detection primaria si basa sul monitoraggio dell'integrità dei file nella web root. Su Windows, la combinazione di Sysmon e i Security Event Log è il punto di partenza. L'analytic AN1622 indica di monitorare WinEventLog:Security, WinEventLog:Sysmon e connessioni di rete (NSM:Connections). In pratica, configurate Sysmon con una regola che tracci le scritture nella directory C:\inetpub\wwwroot — ogni EventID 11 (FileCreate) o EventID 2 (FileCreationTimeChanged) in quella path merita un alert ad alta severità se il processo scrivente non è il processo di deploy autorizzato.

Su Linux (AN1623), il cuore della detection è auditd. Create una regola audit sulla web root:

-w /var/www/html -p wa -k web_defacement

Questa regola genera un evento SYSCALL ogni volta che un file nella web root viene scritto o i suoi attributi vengono modificati. Il tuning critico è escludere i deploy automatizzati legittimi — pipeline CI/CD, rsync schedulati, aggiornamenti CMS — filtrando per UID del service account autorizzato e per finestre temporali di deploy previste.

Per ambienti cloud (AN1625), la log source è AWS CloudTrail. Cercate eventi PutObject o CopyObject sul bucket che ospita il sito statico, correlando con l'identità IAM che esegue l'operazione. Un alert efficace scatta quando il PutObject su file HTML/JS/CSS proviene da un ruolo IAM mai usato prima per operazioni sul bucket, o da un IP sorgente non appartenente ai range della pipeline di deploy.

I falsi positivi più comuni derivano da aggiornamenti legittimi del CMS, deploy applicativi, e editor di contenuto che modificano pagine in orario non standard. Per gestirli, mantenete una whitelist dei processi e degli utenti autorizzati a scrivere nella web root, e implementate un meccanismo di hash comparison: calcolate l'hash dei file di produzione dopo ogni deploy autorizzato e generate un alert quando l'hash corrente diverge da quello noto senza un deploy corrispondente nel sistema CI/CD. Tool come OSSEC (open source) offrono funzionalità di file integrity monitoring nativamente integrate con il sistema di alerting.

Su macOS (AN1624), il monitoraggio passa attraverso l'Unified Log — scenario meno frequente ma rilevante per ambienti di sviluppo web che pubblicano contenuti dalla directory ~/Sites.

L'analisi forense di un External Defacement ha un vantaggio raro: il momento dell'impatto è quasi sempre noto con precisione, perché qualcuno — un utente, un servizio di monitoraggio, un giornalista — nota il cambiamento e lo segnala. Questo punto temporale fisso diventa l'ancora della vostra timeline.

Su Windows (artefatti correlati ad AN1622), partite dal filesystem della web root. Esaminate i timestamp MACE (Modified, Accessed, Created, Entry Modified) del file index.html o equivalente in C:\inetpub\wwwroot utilizzando strumenti come MFTECmd di Eric Zimmerman (open source). Il timestamp di modifica del file defacciato vi dà il momento esatto dell'azione. Cercate poi nel journal NTFS ($UsnJrnl) tutte le operazioni di scrittura nella web root nelle ore precedenti — spesso troverete la web shell caricata poco prima.

I log Sysmon sono fondamentali: l'EventID 1 (Process Create) vi rivela quale processo ha scritto il file — se è w3wp.exe (il worker process di IIS) che genera cmd.exe o powershell.exe, avete la conferma di una web shell. Correlate con l'EventID 3 (Network Connection) dello stesso processo per identificare l'IP dell'attaccante.

Su Linux (AN1623), la timeline si costruisce incrociando più fonti. I log di auditd con le syscall open, write, rename sulla web root forniscono il dettaglio dell'operazione. I log di accesso del web server (access.log di Apache o Nginx) rivelano le richieste HTTP anomale che hanno preceduto la modifica — cercate POST su path insoliti, upload di file con estensioni doppie (.php.jpg), o richieste verso file appena creati nella web root. Utilizzate Plaso/log2timeline (open source) per consolidare queste fonti in un'unica supertimeline.

Per ambienti IaaS (AN1625), l'analisi si sposta su CloudTrail. Ricostruite la sequenza: chi ha effettuato il PutObject sul bucket, da quale IP, con quale ruolo IAM, e come quel ruolo è stato assunto (AssumeRole events). Spesso il trail porta a credenziali API esfiltrate da un server applicativo o da un repository Git pubblico.

Un elemento chiave è la preservazione del contenuto defacciato stesso. Salvate una copia forense della pagina modificata — contiene spesso firme dell'hacktivist, tag di gruppi, o codice JavaScript aggiuntivo che può rivelare infrastruttura di C2 o redirect verso kit di exploit, confermando lo scenario in cui il defacement è il precursore di un attacco Drive-by Compromise.

Il panorama threat intelligence dell'External Defacement è dominato da operazioni con forte connotazione geopolitica legate al teatro est-europeo. I due gruppi documentati operano in contesti di conflitto ibrido dove il defacement è uno strumento di guerra informativa.

Ember Bear (G1003) è associato al defacement di diversi siti web di organizzazioni ucraine. Il gruppo utilizza questa tecnica come componente di operazioni di destabilizzazione più ampie, dove la manomissione dei siti istituzionali serve a erodere la fiducia dei cittadini nelle istituzioni e a proiettare un'immagine di vulnerabilità del paese target. Il defacement per Ember Bear non è fine a sé stesso — si inserisce in un pattern operativo che combina distruzione di dati e operazioni informative.

Sandworm Team (G0034) ha condotto un'operazione di defacement su scala massiva, colpendo circa 15.000 siti web appartenenti a organizzazioni governative, non governative e del settore privato georgiano nel 2019. La portata dell'operazione — quindicimila siti in una singola campagna — indica capacità industriali di compromissione e automazione dell'attacco, probabilmente attraverso la compromissione di provider di hosting condiviso o piattaforme CMS centralizzate piuttosto che l'attacco individuale di ciascun sito.

Il pattern geografico è inequivocabile: entrambi i gruppi colpiscono paesi nell'orbita di interesse strategico russo — Ucraina e Georgia — e utilizzano il defacement come moltiplicatore psicologico all'interno di campagne ibride più ampie. Per il TI analyst, questo suggerisce che nuove ondate di defacement di massa contro organizzazioni di paesi in tensione geopolitica con la Russia dovrebbero essere valutate non come atti di vandalismo isolato, ma come possibili indicatori anticipatori di operazioni distruttive imminenti (wiper, attacchi alla supply chain).

Il tool overlap tra i due gruppi e l'assenza di software specifici documentati per questa tecnica indicano che il defacement viene eseguito con strumenti generici — web shell commodity, script di sostituzione file, tool di accesso remoto standard — rendendo l'attribuzione basata sui tool particolarmente difficile. L'attribuzione passa piuttosto dall'analisi del contesto geopolitico, della vittimologia e dell'infrastruttura di rete utilizzata nelle fasi precedenti della kill chain.

Per il monitoraggio continuo, concentratevi sulle organizzazioni pubbliche di paesi in aree di tensione geopolitica attiva e correlate eventuali defacement di massa con indicatori di compromissione noti per Sandworm Team ed Ember Bear nelle fasi di accesso iniziale e movimento laterale.

Framework MITRE ATT&CK v16 — Tecnica T1491.002 (External Defacement), Tattica TA0040 (Impact). Gruppi: G1003 (Ember Bear), G0034 (Sandworm Team). Mitigazione M1053 (Data Backup). Detection: DET0590, analytics AN1622–AN1625. Tool di detection citati: Sysmon, auditd, OSSEC, MFTECmd, Plaso/log2timeline. Integrato con conoscenza professionale per tool e procedure operative.