Scansione delle Vulnerabilità: Vulnerability Scanning (T1595.002)

Per simulare in laboratorio ciò che gruppi come Ember Bear e APT41 fanno contro target reali, servono strumenti in grado di coprire le tre fasi tipiche: discovery delle porte, fingerprinting dei servizi e identificazione delle vulnerabilità.

La prima fase è la scansione massiva. MASSCAN (open source) è lo stesso tool documentato per Ember Bear e permette di enumerare rapidamente porte aperte su ampi range. Su un segmento di lab autorizzato:

masscan 10.0.0.0/24 -p80,443,8443,8080 --rate=1000 -oJ scan_results.json

L'output JSON alimenta la fase successiva. Per estrarre banner e versioni software, Nmap (open source) resta il riferimento con i suoi script NSE:

nmap -sV --script=vulners,http-server-header -iL targets.txt -oX nmap_vuln.xml

Lo script vulners correla le versioni rilevate con database CVE pubblici, restituendo un primo elenco di potenziali falle. APT41 ha utilizzato Acunetix (a pagamento) per SQL injection scanning e JexBoss (open source) per le applicazioni Java. In un contesto red team autorizzato, l'equivalente open source per web application scanning è Nuclei (open source) di ProjectDiscovery, che utilizza template YAML community-driven:

nuclei -l urls.txt -t cves/ -severity critical,high -o nuclei_results.txt

Per replicare l'approccio della campagna Cutting Edge (C0029), dove gli attaccanti hanno usato Interactsh (open source) per identificare VPN Ivanti vulnerabili a CVE-2024-21893, si può lanciare un server Interactsh locale e integrarlo con Nuclei per la verifica out-of-band delle vulnerabilità:

interactsh-client

Il client genera un dominio di callback univoco da iniettare nei payload di test. Quando il target vulnerabile effettua la richiesta DNS o HTTP verso quel dominio, la vulnerabilità è confermata — esattamente come nel caso Ivanti.

Per simulare lo scanning di vulnerabilità Log4Shell (CVE-2021-44228), come documentato per Magic Hound e Aquatic Panda, si può usare il template Nuclei dedicato oppure costruire un payload JNDI che punta al proprio listener Interactsh. La chiave è sempre operare solo contro target nel perimetro dell'ingaggio autorizzato.

Infine, una nota sulla credibilità della simulazione: i gruppi APT reali lanciano queste scansioni da infrastruttura distribuita (VPS, cloud temporanei). Per un red team realistico, considera di eseguire gli scan da istanze cloud dedicate piuttosto che dalla rete interna del laboratorio.

Il vulnerability scanning avviene prevalentemente prima del contatto diretto con la rete interna, quindi la detection è indiretta: si intercettano i sintomi della scansione quando colpiscono i servizi esposti. La log source principale è il Network Traffic, come indicato nella detection ufficiale.

Il segnale più affidabile è l'anomalia nei pattern di connessione verso i servizi perimetrali. Un singolo IP sorgente che interroga decine di porte o endpoint in pochi secondi genera un profilo di traffico molto diverso dal normale. Su firewall e IDS perimetrali, cerca connessioni con queste caratteristiche: alto rapporto SYN/RST (scansioni incomplete), richieste HTTP con user-agent associati a scanner noti (Acunetix, Nuclei, MASSCAN, Nmap Scripting Engine), e sequenze rapide di richieste verso path tipici di vulnerability check come /wp-login.php, /.env, /actuator/health.

Su Suricata (open source) o Snort (open source), le regole della categoria emerging-scan catturano buona parte di queste firme. La correlazione è fondamentale: un singolo alert di scansione ha poco valore, ma un cluster di alert dallo stesso IP sorgente in una finestra temporale ristretta indica ricognizione attiva.

Per i web server esposti, i log di accesso sono una miniera. Con un SIEM come Elastic Security (freemium) o Splunk (freemium), costruisci una detection rule che conta le risposte HTTP 404 e HTTP 500 per IP sorgente in finestre di 5 minuti. Un threshold di 50+ errori in quel lasso è un indicatore robusto di scanning automatizzato. Affianca questo dato con il conteggio di URI distinti richiesti: gli scanner ciclano attraverso centinaia di path predefiniti.

La gestione dei falsi positivi è critica perché i vulnerability scanner legittimi (pentest interni, scanner del provider cloud) generano traffico identico. Mantieni una whitelist aggiornata degli IP dei tuoi scanner autorizzati e dei servizi di security assessment. Tagga gli alert provenienti da IP non in whitelist con priorità elevata.

Come hardening proattivo — coerente con la mitigazione M1056 — monitora la tua superficie esposta prima che lo facciano gli avversari. Piattaforme come Shodan (freemium) e Censys (freemium) permettono di vedere ciò che un attaccante vede. Integra il monitoraggio OSINT con SpiderFoot (open source) per rilevare informazioni trapelate che potrebbero guidare una scansione mirata.

L'analisi forense di un vulnerability scanning si gioca quasi interamente su fonti esterne e log perimetrali, perché l'attaccante non ha ancora raggiunto l'endpoint. L'obiettivo è ricostruire quando e come la ricognizione è avvenuta, per collegare la scansione all'exploit successivo.

La prima fonte sono i log dei web server esposti. Apache, Nginx e IIS registrano ogni richiesta: cerca sequenze di GET/POST verso path noti di vulnerability check, con tempi inter-richiesta inferiori al secondo. L'user-agent è spesso rivelatore — molti scanner lasciano firme identificabili anche quando tentano di camuffarsi. Correla il timestamp della prima richiesta anomala con l'IP sorgente per stabilire l'inizio della ricognizione.

I log del firewall perimetrale e dell'IDS/IPS forniscono il secondo livello. Esporta gli eventi di tipo scan detected o port sweep e allineali alla timeline dei log web. Se l'IP sorgente compare prima nel firewall (tentativo su porte multiple) e poi nei log HTTP (richieste applicative mirate), hai un pattern chiaro di escalation dalla scansione generica al vulnerability scanning specifico.

Per la campagna Cutting Edge (C0029), gli artefatti chiave da cercare sono le richieste DNS verso domini Interactsh (tipicamente con suffisso .oast. ) nei log DNS del resolver aziendale o del proxy. La presenza di queste query indica che l'attaccante ha utilizzato callback out-of-band per confermare la vulnerabilità delle VPN Ivanti. Similmente, per SharePoint ToolShell Exploitation (C0058), cerca nei log di IIS dei server SharePoint richieste anomale verso endpoint associati a CVE-2025-53770.

I record passive DNS sono preziosi per risalire all'infrastruttura dell'attaccante. Servizi come Farsight DNSDB (a pagamento) o la funzionalità passive DNS di VirusTotal (freemium) permettono di verificare se l'IP sorgente della scansione ha risolto altri domini, rivelando l'ampiezza dell'operazione.

Se dopo la scansione c'è stato un exploit riuscito, l'endpoint compromesso diventa rilevante. Su sistemi Windows, verifica i log EventLog per connessioni in ingresso temporalmente successive alla scansione: EventCode 5156 del Windows Filtering Platform registra le connessioni di rete accettate. Su Linux, i log di auditd con la regola -a always,exit -F arch=b64 -S connect catturano le connessioni in arrivo se configurati.

Costruisci la timeline in tre blocchi: scansione iniziale (log firewall + web server), conferma vulnerabilità (callback DNS o risposte applicative anomale), exploit (artefatti endpoint). Questa sequenza temporale collega la ricognizione all'accesso iniziale in modo probatorio.

La scansione di vulnerabilità è la tecnica di ricognizione più democratica: la usano gruppi state-sponsored di primo livello e collettivi opportunistici con uguale frequenza, ma con targeting e strumenti diversi. Ecco i profili chiave e i pattern da monitorare.

APT28 (G0007) e APT29 (G0016) — i due principali gruppi russi — conducono scansioni su larga scala. Il pattern è quello del "dragnet": sweep massivi alla ricerca di qualsiasi versione vulnerabile, seguiti da exploit rapido. Operano spesso sulle stesse CVE ma con catene di compromissione diverse. La sovrapposizione di targeting con Sandworm Team (G0034), anch'esso russo e documentato per scansioni infrastrutturali, suggerisce un ecosistema coordinato dove la ricognizione può essere condivisa tra unità offensive.

Magic Hound (G0059), attore iraniano, mostra un pattern CVE-driven molto specifico: ProxyShell, Log4Shell, Fortinet VPN. Questo gruppo seleziona vulnerabilità con exploit pubblicamente disponibili e alta diffusione enterprise, poi lancia scansioni mirate. La sovrapposizione con Aquatic Panda (G0143) su Log4Shell (CVE-2021-44228) è significativa — entrambi hanno sfruttato la stessa finestra di opportunità, ma Aquatic Panda ha usato servizi di DNS logging pubblici per il fingerprinting, un approccio più discreto.

Sul fronte cinese, il cluster è denso. APT41 (G0096) si distingue per la scelta di tool specializzati: Acunetix per SQL injection e JexBoss per Java. Earth Lusca (G1006) opera su server pubblici con approccio simile. La campagna Cutting Edge (C0029) — attribuita ad attori China-nexus (UNC5221/UTA0178 e UNC5325) — ha introdotto l'uso di Interactsh per la conferma out-of-band delle vulnerabilità Ivanti, colpendo la base industriale della difesa USA e settori critici globali. La più recente SharePoint ToolShell Exploitation (C0058, luglio 2025) coinvolge Threat Group-3390 e ZIRCONIUM nello sfruttamento di CVE SharePoint parzialmente corrette, confermando la tendenza cinese a colpire infrastrutture Microsoft enterprise.

Winter Vivern (G1035) e Ember Bear (G1003) usano entrambi Acunetix, ma da posture diverse: Winter Vivern lo ospita su istanze remote, Ember Bear lo affianca a MASSCAN per una copertura più ampia. Volatile Cedar (G0123), attore libanese, e Dragonfly (G0035), focalizzato su Citrix ed Exchange, completano un panorama dove TeamTNT (G0139) rappresenta l'eccezione non-statale, con focus su IoT e Docker API.

Il trend emergente è chiaro: la finestra tra disclosure di una CVE e scanning massivo si sta comprimendo, con attori multipli che convergono simultaneamente sugli stessi target.

Framework MITRE ATT&CK v16 — T1595.002, TA0043, M1056. Campagne: C0029 (Cutting Edge), C0058 (SharePoint ToolShell Exploitation). Tool di detection: Suricata, Snort, Elastic Security, Splunk. Monitoraggio superficie: Shodan, Censys, SpiderFoot, Farsight DNSDB. Integrato con conoscenza professionale per tool e procedure operative.