Firewall di Rete Sotto Attacco: Disable or Modify Network Device Firewall (T1562.013)

In un ingaggio red team, dimostrare che il firewall perimetrale è manipolabile ha un impatto enorme sul report finale. L'obiettivo è replicare il flusso completo: accesso alla console, modifica delle regole, validazione del canale C2 aperto.

Il primo passo è l'enumerazione. Se il target è un firewall Cisco ASA o FortiGate, occorre verificare se l'interfaccia di gestione è raggiungibile. Con Nmap (open source) puoi scansionare le porte di management tipiche:

nmap -sV -p 22,443,8443,9443 <IP-firewall>

Nota le porte 443, 6443, 8443 e 9443: sono esattamente quelle su cui APT38 ha creato eccezioni firewall documentate. In laboratorio, queste diventano il primo bersaglio di enumerazione.

Una volta identificata l'interfaccia di management, il passo successivo dipende dal vendor. Su un Cisco ASA accessibile via SSH, la sequenza per aggiungere una regola permissiva è diretta. Dopo l'autenticazione in modalità enable:

access-list OUTSIDE_IN extended permit tcp any any eq 443 access-group OUTSIDE_IN in interface outside

Su un FortiGate, l'equivalente via CLI passa per la creazione di una policy:

config firewall policy edit 0 set srcintf "wan1" set dstintf "internal" set srcaddr "all" set dstaddr "all" set action accept set schedule "always" set service "ALL" next end

Per ambienti Palo Alto, il PAN-OS CLI richiede un commit esplicito, il che aggiunge un artefatto utile per la detection:

set rulebase security rules RedTeamTest from any to any source any destination any application any action allow commit

Sul fronte automazione, strumenti come paloalto-panos-scripts o Ansible (open source) con i moduli specifici per firewall vendor (es. panos_security_rule per Palo Alto, fortios_firewall_policy per FortiGate) permettono di scriptare l'intera catena. Questo è particolarmente utile per dimostrare che un attaccante con credenziali API può modificare centinaia di regole in secondi.

Per simulare lo scenario Grandoreiro, che blocca specifici tool di sicurezza a livello firewall, su una macchina Windows di laboratorio puoi usare netsh:

netsh advfirewall firewall add rule name="BlockSecTool" dir=out program="C:\Program Files\SecurityTool\agent.exe" action=block

Valida sempre l'apertura del canale con un listener Netcat (open source) o con il framework Cobalt Strike (a pagamento) per confermare che il traffico C2 fluisce attraverso le porte appena aperte.

La detection di modifiche non autorizzate ai firewall di rete è una delle poche aree in cui il segnale è forte — se sai dove cercarlo. La detection DET0306 fornisce una base solida: monitorare cambiamenti di configurazione provenienti da IP non appartenenti alle subnet di management autorizzate, oppure fuori dalle finestre di manutenzione.

Le log source primarie sono i syslog del firewall stesso e i flussi NetFlow/NSM. Ogni vendor genera eventi specifici per le modifiche di configurazione: Palo Alto registra i commit nel System Log con tipo CONFIG, FortiGate emette log di tipo event con sottotipo system, Cisco ASA logga con facility %ASA-5-111008 e %ASA-5-111010 per le modifiche alla running-config.

Il SIEM deve correlare questi eventi con quattro parametri di tuning chiave:

• TrustedAdminIPs: allowlist delle subnet di management (jump box, VPN dedicata). Qualsiasi modifica da IP esterno a questa lista è un alert ad alta severità.
• ConfigChangeWindow: la finestra di manutenzione concordata (es. 02:00–04:00 UTC). Modifiche fuori finestra alzano il livello di attenzione.
• RuleScopeThreshold: il numero di regole modificate o la dimensione dei range di porte. Una singola regola puntuale è diversa da una "allow all" su tutte le subnet interne.
• NewUserPrivilegeThreshold: utenti che modificano regole senza un percorso di privilege elevation osservabile nei log precedenti.

La correlazione più efficace lega il log di modifica firewall a un picco di traffico outbound precedentemente bloccato. Se nelle ore successive a una modifica di regole compare traffico verso destinazioni mai viste, verso porte come 6443 o 9443 — quelle sfruttate da APT38 — il SOC ha un indicatore comportamentale forte.

I falsi positivi principali arrivano da due fonti: automazione legittima (Ansible, Terraform) che modifica regole da service account noti, e cambi di emergenza fuori finestra approvati via ticket. Il tuning richiede integrazione con il sistema ITSM: se esiste un change request aperto, l'alert viene declassato. Senza correlazione ITSM, ogni modifica fuori finestra resta ad alta priorità.

Per la parte preventiva, strumenti come Batfish (open source) permettono di analizzare le configurazioni firewall offline e verificare che non esistano regole eccessivamente permissive prima che entrino in produzione. Oxidized (open source) esegue backup periodici delle configurazioni, e un confronto diff automatizzato tra snapshot consecutivi evidenzia immediatamente regole aggiunte o rimosse.

L'analisi forense su un firewall compromesso segue un flusso diverso rispetto all'endpoint tradizionale: gli artefatti principali risiedono nei log del dispositivo stesso, nei backup di configurazione e nei flussi di rete catturati a monte e a valle.

Il primo elemento da acquisire è lo storico delle configurazioni. Se l'organizzazione utilizza un sistema di configuration management come Oxidized (open source) o RANCID (open source), ogni snapshot rappresenta un punto nella timeline. Il confronto diff tra la configurazione pre-incidente e quella attuale rivela esattamente quali regole sono state aggiunte, modificate o eliminate. Cerca in particolare regole con action permit/allow su range di porte ampi, regole che referenziano any sia come source che come destination, e regole che aprono le porte 443, 6443, 8443, 9443 — coerenti con il profilo operativo di APT38.

Il secondo blocco di evidenze viene dai log di autenticazione del firewall. Ricostruisci chi ha effettuato login sulla console di management, da quale IP e in quale momento. Correla il timestamp del primo login anomalo con la prima modifica di configurazione per stabilire il tempo di permanenza pre-manipolazione. Se l'accesso è avvenuto via API REST anziché CLI o GUI, i log HTTP del management plane conterranno le chiamate specifiche — tipicamente PUT o POST verso endpoint di gestione delle policy.

Il terzo livello riguarda i flussi di rete. Con i dati NetFlow o con PCAP catturati da un sensore NSM come Zeek (open source), verifica se dopo la modifica delle regole è comparso traffico su porte o verso destinazioni precedentemente bloccate. Questo passaggio è cruciale per stabilire la finalità della manipolazione: se il traffico post-modifica punta verso IP di C2 noti, l'intento è chiaro.

Per lo scenario Grandoreiro, l'analisi si sposta sull'endpoint Windows. Il malware manipola Windows Firewall per bloccare specifici processi di sicurezza. Gli artefatti chiave sono:

• Chiave di registro HKLM\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\FirewallRules — ogni regola aggiunta tramite netsh o API COM viene scritta qui
• Log eventi Microsoft-Windows-Windows Firewall With Advanced Security/Firewall con EventID 2004 (regola aggiunta) e EventID 2006 (regola eliminata)
• Prefetch del processo che ha invocato la modifica, utile per stabilire quale binario ha eseguito la manipolazione

La timeline finale deve legare in sequenza: accesso iniziale (login anomalo o exploitation), modifica configurazione, inizio traffico C2/esfiltrazione, e — se presente — successiva cancellazione dei log per coprire le tracce.

La manipolazione dei firewall di rete è una tecnica chirurgica: richiede accesso privilegiato a dispositivi critici, quindi compare tipicamente nelle fasi avanzate di un'intrusione, quando l'attaccante ha già consolidato la propria posizione.

APT38, il gruppo a motivazione finanziaria legato alla Corea del Nord, utilizza questa tecnica in modo caratteristico. Le eccezioni firewall create su porte 443, 6443, 8443 e 9443 rivelano un pattern operativo preciso: la porta 443 garantisce traffico C2 mascherato da HTTPS legittimo, mentre le porte ad alto numero (6443, 8443, 9443) suggeriscono l'uso di servizi custom o reverse proxy per l'esfiltrazione dei dati. Questo schema è coerente con le operazioni di furto finanziario su larga scala per cui il gruppo è noto — l'apertura di canali multipli garantisce ridondanza nel caso uno venga bloccato.

Sul versante malware, Grandoreiro rappresenta un caso d'uso differente ma complementare. Questo trojan bancario non manipola il firewall perimetrale, bensì quello locale dell'endpoint, bloccando specificamente il tool di sicurezza Diebold Warsaw GAS Tecnologia — una soluzione di protezione bancaria diffusa in America Latina. L'approccio è mirato: anziché disabilitare tutto il firewall, Grandoreiro crea regole puntuali che impediscono al software di sicurezza di comunicare, neutralizzandolo di fatto senza generare allarmi grossolani.

Dal punto di vista del profiling, il pattern geografico è significativo. APT38 colpisce istituzioni finanziarie globali, mentre Grandoreiro si concentra sul mercato latinoamericano. Entrambi convergono sulla manipolazione delle regole firewall come enabler di operazioni finanziarie illecite, ma con vettori diversi: APT38 opera a livello di infrastruttura di rete, Grandoreiro a livello endpoint.

Le tre mitigazioni previste — audit periodico delle regole, gestione rigorosa degli account con accesso alla console di management e aggiornamento costante del firmware — riflettono una verità operativa: la maggior parte delle compromissioni di firewall passa da credenziali deboli o da vulnerabilità note non patchate su interfacce di gestione esposte. Monitorare i portali come Shodan e Censys per verificare che le proprie console di management non siano raggiungibili dall'esterno resta una misura proattiva fondamentale.

Il trend emergente vede un aumento dell'uso di API REST per la manipolazione automatizzata delle configurazioni firewall, rendendo la detection basata su log CLI sempre meno sufficiente da sola.

Framework MITRE ATT&CK v16 — Tecnica T1562.013, Tattica TA0005, Gruppo G0082 (APT38), Software S0531 (Grandoreiro), Mitigazioni M1047, M1018, M1051, Detection DET0306 / AN0855. Integrato con conoscenza professionale per tool e procedure operative.