Modifica Firewall Cloud: Disable or Modify Cloud Firewall (T1686.001)

In un ingaggio red team autorizzato su ambiente cloud, la simulazione di T1686.001 parte dalla verifica dei permessi IAM disponibili. Su AWS il permesso critico è ec2:AuthorizeSecurityGroupIngress, spesso concesso in modo eccessivo a ruoli di sviluppo o CI/CD. Un comando tipico per aprire SSH a chiunque su un security group esistente è:

aws ec2 authorize-security-group-ingress --group-id sg-0abc123 --protocol tcp --port 22 --cidr 0.0.0.0/0

Per Azure, l'equivalente su un Network Security Group è:

az network nsg rule create --resource-group RG --nsg-name NSG --name allow-all --priority 100 --source-address-prefixes '' --destination-port-ranges 22 --access Allow --protocol Tcp*

Su GCP:

gcloud compute firewall-rules create allow-ssh-any --direction=INGRESS --action=ALLOW --rules=tcp:22 --source-ranges=0.0.0.0/0

Lo strumento di riferimento per esercizi strutturati è Pacu (open source), framework di offensive security per AWS mantenuto da Rhino Security Labs. Pacu include il modulo detection__disruption per manipolare GuardDuty e moduli come ec2__enum e iam__enum_permissions per mappare preventivamente le autorizzazioni disponibili. La whitelist di IP in GuardDuty tramite Pacu (documentata nel software S1091) permette di ridurre il rumore delle alert prima di aprire le regole di rete.

Un playbook realistico prevede tre fasi. Prima, enumerazione dei security group e delle regole esistenti con aws ec2 describe-security-groups per identificare gruppi già associati a molte istanze — modificare uno di questi ha impatto ampio con una singola chiamata API. Seconda, valutazione del contesto IAM con ScoutSuite (open source) o Prowler (open source) per identificare ruoli con permessi eccessivi sui security group. Terza, esecuzione della modifica con parametri il più possibile mimetici: aggiungere regole per porte legittime (443, 8080) da CIDR ampi ma non /0, sfruttando finestre temporali di manutenzione dichiarate.

Per laboratori didattici, CloudGoat (open source) di Rhino Security Labs offre scenari dedicati dove esercitare escalation IAM che culminano nella modifica dei security group. Stratus Red Team (open source) di DataDog implementa direttamente la tecnica aws.defense-evasion.security-groups-modification con teardown automatico, ideale per validare le detection SOC senza lasciare artefatti persistenti. Ogni esercizio deve concludersi con ripristino delle regole originali documentato nel report di ingaggio.

La detection di T1686.001 si basa quasi interamente sui log del control plane cloud, perché la modifica avviene tramite chiamate API e non lascia tracce sull'host. La strategia DET0424 individua come fonte primaria AWS CloudTrail (equivalenti: Azure Activity Log, GCP Cloud Audit Logs), monitorando eventi come AuthorizeSecurityGroupIngress, RevokeSecurityGroupIngress, CreateSecurityGroup e ModifyNetworkInterfaceAttribute.

Il primo indicatore ad alta priorità è l'aggiunta di regole con CIDR 0.0.0.0/0 o ::/0 su porte sensibili (22, 3389, 3306, 5432, 6379, 27017, 9200). Una query KQL su Azure Sentinel per Network Security Group può filtrare gli eventi Microsoft.Network/networkSecurityGroups/securityRules/write correlando il campo sourceAddressPrefix con valori wildcard. Su AWS, un rilevatore in AWS Config (a pagamento, incluso nelle regole gestite) come restricted-ssh e vpc-sg-open-only-to-authorized-ports fornisce alert nativo, mentre CloudTrail Lake o l'inoltro verso SIEM permette query più sofisticate.

Le quattro dimensioni di tuning previste dalla strategia detection devono essere applicate in combinazione. La whitelist AllowedIPRanges definisce quali CIDR aziendali sono legittimi (VPN corporate, uffici, provider CDN); ogni aggiunta di range esterni scatena alert. Il PortScope definisce le porte attese per ciascun servizio: un web server può giustificare 443, non 22 aperto al mondo. Il RoleContext distingue tra account di automazione (Terraform, CloudFormation) e ruoli umani: modifiche fuori dalle pipeline CI/CD devono avere priorità alta. La TimeWindow correla le modifiche alle regole con traffico di rete successivo tramite VPC Flow Logs, riducendo falsi positivi quando la regola è ampia ma inutilizzata.

I falsi positivi tipici derivano da attività di sviluppo legittime (debug temporaneo), scaling automatico che crea nuovi security group, o deployment via IaC. La mitigazione consiste nel taggare gli account di automazione e nel richiedere che ogni regola aperta abbia un tag di ownership e scadenza; regole senza tag scadenza triggerano alert dopo N ore.

Allineandosi alla mitigazione M1047 (Audit), un controllo periodico automatico deve elencare tutti i security group con regole /0 e verificarne la giustificazione business. Strumenti come Prowler (open source), ScoutSuite (open source) e CloudSploit (open source) generano report ricorrenti. AWS GuardDuty (a pagamento) include finding come Recon:IAMUser/NetworkPermissions utili a correlare enumerazione preventiva e modifica successiva delle regole.

L'analisi forense di una modifica malevola a firewall cloud si svolge interamente nel piano del control plane. La fonte primaria è AWS CloudTrail (equivalenti Azure Activity Log e GCP Audit Logs), configurato idealmente con trail multi-region e log file validation abilitata per garantire integrità crittografica.

La timeline si costruisce estraendo gli eventi AuthorizeSecurityGroupIngress, RevokeSecurityGroupIngress, CreateSecurityGroup, ModifySecurityGroupRules e UpdateSecurityGroupRuleDescriptions. Ogni evento contiene userIdentity (con principalId, arn, accessKeyId, sessionContext), sourceIPAddress, userAgent, requestParameters con le regole aggiunte e responseElements con l'esito. Il campo userAgent aiuta a distinguere tra console web, AWS CLI, SDK Boto3, Terraform o tool offensivi come Pacu (che usa un user agent identificabile se non modificato).

Un workflow di indagine tipico inizia interrogando CloudTrail Lake o esportando i log su S3 e analizzandoli con Athena (a pagamento, pay-per-query). Una query utile filtra tutti gli eventi AuthorizeSecurityGroupIngress con requestParameters.cidrIp = '0.0.0.0/0' nell'intervallo temporale di interesse. Per ciascun evento si ricostruisce il pivot pre-attività: chiamate precedenti dello stesso accessKeyId come DescribeSecurityGroups, DescribeInstances, ListRoles, GetCallerIdentity — pattern tipico di enumerazione. Chiamate a AssumeRole poco prima della modifica indicano potenziale role chaining o compromissione di credenziali temporanee.

Gli artefatti chiave da preservare includono: lo snapshot del security group prima e dopo la modifica (via aws ec2 describe-security-groups eseguito post-incidente e confrontato con lo storico in AWS Config timeline, che mantiene le configurazioni versionate); i VPC Flow Logs per il periodo in cui la regola è stata attiva, che rivelano quali IP esterni hanno effettivamente sfruttato l'apertura e verso quali ENI; i log di AWS GuardDuty per finding correlati come UnauthorizedAccess:EC2/SSHBruteForce o CryptoCurrency:EC2/BitcoinTool.B che seguono l'apertura.

Dal lato identità, i CloudTrail management events delle ultime 90 giornate per il principal coinvolto rivelano se le credenziali sono state usate da IP inusuali (correlazione con IPinfo o MaxMind GeoIP, freemium). Se il principal è una IAM user, il log ConsoleLogin mostra i login recenti; se è un IAM role, si risale al principal originale tramite sessionContext.sessionIssuer.

La timeline finale correla: enumerazione IAM → escalation o abuso permessi → modifica security group → traffico anomalo nei Flow Logs → attività finale (esfiltrazione, mining, lateral movement). La finestra temporale di apertura della regola definisce l'esposizione: anche pochi minuti sono sufficienti per uno scan e un exploit automatizzato.

I dati MITRE ATT&CK per T1686.001 non associano gruppi APT o campagne documentate a questa specifica sottotecnica, ma la tecnica è centrale nell'ecosistema delle minacce cloud-native e va contestualizzata in termini di pattern osservati e capability disponibili.

L'unico software mappato è Pacu (S1091), framework offensive per AWS sviluppato da Rhino Security Labs. Pacu documenta esplicitamente la capacità di aggiungere IP in whitelist su AWS GuardDuty, riducendo la telemetria disponibile prima di procedere a modifiche dei security group. Sebbene sia distribuito come strumento di red teaming legittimo, Pacu è ampiamente disponibile e i suoi moduli sono replicabili in script custom, rendendo la barriera d'ingresso per attaccanti opportunistici molto bassa.

Il pattern operativo dominante osservato nella threat landscape cloud generale — pur non attribuito nei dati forniti — è quello degli attori motivati finanziariamente che sfruttano credenziali IAM compromesse (leak su repository pubblici, phishing di sviluppatori, malware infostealer che raccoglie file ~/.aws/credentials) per aprire security group e monetizzare tramite cryptomining o esfiltrazione dati. La modifica del firewall cloud è spesso l'ultimo passo tecnico prima della monetizzazione, perché consente di raggiungere risorse interne dall'esterno o di stabilire comunicazioni C2 in uscita non filtrate.

Un secondo pattern rilevante è l'uso della tecnica in scenari di living-off-the-cloud: l'attaccante non installa malware, ma usa esclusivamente API cloud native, rendendo la detection dipendente al 100% dai log del provider. Questo eleva il ruolo di CloudTrail, Azure Activity Log e GCP Audit Logs a fonti primarie di threat intelligence, non solo di monitoring.

Dal punto di vista delle mitigazioni, i dati indicano due direttrici. M1018 (User Account Management) applica il principio del least privilege alle policy IAM: il permesso di modificare security group deve essere separato dai ruoli operativi comuni e assegnato a ruoli dedicati con MFA. M1047 (Audit) richiede revisioni periodiche dei permessi per verificare che solo utenti e ruoli attesi possano modificare i firewall cloud.

A livello di trend, l'adozione crescente di Infrastructure as Code (Terraform, CloudFormation, Pulumi) sposta la superficie di attacco verso le pipeline CI/CD: compromettere un runner GitHub Actions o GitLab con permessi di deploy equivale a poter modificare qualsiasi security group. Questo rende essenziale integrare la detection di T1686.001 con il monitoraggio delle pipeline e l'analisi delle differenze tra stato desiderato in IaC e stato effettivo del cloud, individuando drift che indicano modifiche fuori dal processo.

MITRE ATT&CK T1686.001 (Disable or Modify Cloud Firewall), tattica TA0112, software S1091 (Pacu), mitigazioni M1018 e M1047, detection strategy DET0424 con analytic AN1188. MITRE D3FEND per mappatura difensiva. Documentazione ufficiale AWS CloudTrail, AWS Config, Azure Activity Log, GCP Audit Logs. Parti relative a comandi CLI, tool (Prowler, ScoutSuite, CloudGoat, Stratus Red Team, CloudSploit) e workflow forensi derivano da conoscenza professionale dell'autore su piattaforme cloud e strumenti open source verificabili.