Deleghe Email Malevole: Additional Email Delegate Permissions (T1098.002)

Per simulare questa tecnica in laboratorio servono un tenant Microsoft 365 di test (o un Exchange on-premises in lab) e credenziali con ruolo sufficiente ad eseguire cmdlet di gestione mailbox. L'obiettivo è dimostrare al cliente quanto sia silenzioso il meccanismo di delega e quanto sia facile sfuggire ai controlli se non correttamente configurati.

Il primo scenario replica l'approccio documentato per APT28 e APT29: assegnare il ruolo ApplicationImpersonation a un account sotto controllo. In una sessione PowerShell connessa a Exchange Online tramite il modulo ExchangeOnlineManagement (open source, distribuito da Microsoft via PowerShell Gallery), la sequenza è diretta:

Connect-ExchangeOnline -UserPrincipalName admin@labtenant.onmicrosoft.com

New-ManagementRoleAssignment -Role "ApplicationImpersonation" -User attacker@labtenant.onmicrosoft.com

Con quel ruolo attivo, l'account attacker può utilizzare EWS (Exchange Web Services) per aprire qualunque mailbox del tenant come se fosse il proprietario, senza generare eventi di login separati per ogni casella.

Il secondo scenario è più granulare e riflette le tecniche di manipolazione a livello di cartella. Qui si assegnano permessi alla cartella Inbox di un target usando il cmdlet Set-MailboxFolderPermission:

Set-MailboxFolderPermission -Identity target@labtenant.onmicrosoft.com:\Inbox -User Default -AccessRights Reviewer

Il ruolo Reviewer consente la lettura completa di tutti i messaggi. Assegnarlo all'utente Default significa che qualunque account autenticato nel tenant può leggere quella Inbox — un approccio documentato per scenari BEC in cui l'avversario vuole ridondanza d'accesso.

Per verificare i permessi esistenti prima e dopo la modifica, il cmdlet diagnostico è:

Get-MailboxFolderPermission -Identity target@labtenant.onmicrosoft.com:\Inbox

Un terzo scenario riguarda l'aggiunta di permessi FullAccess diretti, il classico approccio di delega completa:

Add-MailboxPermission -Identity target@labtenant.onmicrosoft.com -User attacker@labtenant.onmicrosoft.com -AccessRights FullAccess -AutoMapping $false

Il flag -AutoMapping $false è cruciale dal punto di vista offensivo: impedisce che la mailbox delegata appaia automaticamente nel profilo Outlook dell'attacker, riducendo la visibilità dell'operazione. Per Google Workspace, la delega va abilitata dalla console Admin sotto Apps > Google Workspace > Gmail > User Settings, attivando la mail delegation per l'unità organizzativa di test.

Tool complementari per il red teamer: MailSniper (open source) consente di enumerare permessi di mailbox e cercare keyword in caselle accessibili, mentre CRT — CrowdStrike Reporting Tool for Azure (open source) aiuta a identificare role assignment sospetti già presenti nel tenant.

La detection di questa tecnica si gioca quasi interamente sui log cloud. La fonte primaria è lo Unified Audit Log di Microsoft 365 (log source m365:unified), che registra ogni modifica ai permessi di mailbox come evento distinto. Per ambienti Exchange on-premises, la seconda fonte è il Windows Security Event Log, soprattutto quando i cmdlet vengono eseguiti tramite PowerShell remoto.

Il primo analytic da implementare (AN1051) monitora l'attività di delega sulle mailbox. Gli eventi da cercare nello Unified Audit Log hanno operation name come Add-MailboxPermission, Set-MailboxFolderPermission e Add-RecipientPermission. In Google Workspace, l'evento equivalente è EMAIL_SETTINGS_CHANGE nel log dell'Admin console. Il tuning è essenziale: va costruita una baseline delle coppie delegato-delegatore legittime (DelegatorToDelegatePairing) per filtrare le assegnazioni autorizzate, tipicamente quelle tra assistente e dirigente o tra membri dello stesso team.

Il livello di permesso assegnato detta la severità dell'alert. Un'assegnazione FullAccess o SendAs deve generare un alert ad alta priorità, specialmente se l'utente ricevente non appartiene al reparto del proprietario della mailbox. Le assegnazioni a livello di cartella meritano attenzione quando il target è la root (Top of Information Store) o l'Inbox, e l'utente è Default o Anonymous — pattern che indica accesso indiscriminato, non una delega a persona specifica.

Il secondo analytic (AN1052) si concentra sul vettore di esecuzione: PowerShell. Correlare l'evento 4104 (Script Block Logging) con la presenza di stringhe come Add-MailboxPermission o New-ManagementRoleAssignment nel corpo dello script permette di catturare sia esecuzioni interattive sia script automatizzati. Il tuning temporale è altrettanto importante: un'assegnazione di permesso seguita entro 24-48 ore da un picco anomalo di mail in uscita (MailflowAnomalyThreshold) dall'account delegato è un indicatore composito molto affidabile di BEC in corso.

Per ridurre i falsi positivi, tre accorgimenti pratici. Primo, escludere gli account di servizio documentati che eseguono deleghe programmatiche (es. sistemi di ticketing o CRM). Secondo, correlare con il rischio dell'account sorgente — un utente il cui sign-in proviene da un IP anomalo o che ha appena subìto un MFA-reset ha probabilità molto più alta di essere compromesso. Terzo, monitorare la revoca: un permesso aggiunto e rimosso entro pochi minuti può indicare un attaccante che ha capito di essere osservato.

L'analisi forense di questa tecnica ruota attorno a un principio: la modifica dei permessi è un evento cloud, ma le sue conseguenze lasciano tracce sia nei log centralizzati sia — talvolta — sugli endpoint. La ricostruzione temporale deve partire dai log e allargarsi a cerchi concentrici.

Lo Unified Audit Log di Microsoft 365 è il cuore della timeline. Ogni operazione di modifica permessi viene registrata con timestamp UTC, identità dell'esecutore, IP sorgente e dettagli del permesso concesso. Il campo ResultStatus conferma se l'operazione è andata a buon fine, mentre il campo Parameters contiene la mailbox target e il livello di accesso. La retention predefinita è di 90 giorni (180 con licenza E5), quindi in indagini su compromissioni prolungate — come i 14 mesi della campagna HomeLand Justice (C0038) — i log potrebbero non coprire l'intero arco temporale. In questi casi, verificare se il SIEM ha ingestito e archiviato gli eventi oltre la finestra nativa.

Per Google Workspace, gli eventi equivalenti si trovano nei Admin Audit Logs accessibili dalla console o via Reports API, con campo EVENT_NAME uguale a CHANGE_EMAIL_SETTING e parametri che specificano il tipo di delega abilitata.

Sul versante endpoint, se l'attaccante ha eseguito i cmdlet Exchange da una workstation compromessa (piuttosto che dalla cloud shell), gli artefatti PowerShell diventano preziosi. Il file di transcript PowerShell — se abilitato via GPO — registra l'intera sessione inclusi i cmdlet Add-MailboxPermission e New-ManagementRoleAssignment. Il percorso predefinito dei transcript è %USERPROFILE%\Documents ma va verificato in base alla policy. Contestualmente, l'EventCode 4104 nel log Security cattura i blocchi di script eseguiti.

La correlazione temporale è il passaggio chiave. Nella campagna SolarWinds Compromise (C0024), APT29 ha utilizzato Set-CASMailbox per aggiungere device ID consentiti per ActiveSync e ha assegnato permessi Mail.Read e Mail.ReadWrite ai Service Principal compromessi. In un'indagine analoga, l'analista dovrebbe allineare sulla timeline: il momento dell'assegnazione del permesso, il primo accesso EWS o Graph API dalla mailbox target, e l'eventuale creazione di regole Inbox (che spesso accompagna la delega per nascondere risposte o notifiche).

Artefatti complementari da raccogliere includono i log di Azure AD Sign-In per identificare l'IP e il device da cui è stato eseguito il cmdlet, i log di Azure AD Audit per verificare se sono stati assegnati anche ruoli a livello di directory (escalation dal piano mail al piano identity), e gli Mailbox Audit Log per tracciare ogni accesso alla casella delegata dopo l'assegnazione del permesso. Quest'ultimo log registra operazioni come FolderBind, MessageBind e SendAs, disegnando il quadro completo di cosa l'attaccante ha letto o inviato.

Il panorama degli attori che sfruttano la delega email è ristretto ma di altissimo profilo, con una concentrazione geografica che punta chiaramente verso operazioni statali russe e iraniane.

APT29 (Russia, SVR) rappresenta il caso d'uso più sofisticato. Nella campagna SolarWinds Compromise (C0024), durata dall'agosto 2019 al gennaio 2021, il gruppo ha utilizzato account Global Administrator compromessi in Azure AD per assegnare diritti ApplicationImpersonation a Service Principal backdoorati, creando un canale di raccolta email persistente e difficile da individuare. L'aggiunta di permessi Mail.Read e Mail.ReadWrite ai Service Principal e l'uso di Set-CASMailbox per autorizzare device ActiveSync malevoli mostrano una padronanza operativa del piano di controllo Microsoft 365 che va oltre la semplice delega. Il pattern di APT29 è caratteristico: l'abuso di identità cloud (Service Principal, OAuth app) piuttosto che account utente tradizionali, il che rende la detection più complessa.

APT28 (Russia, GRU) adotta un approccio più diretto: l'assegnazione del ruolo ApplicationImpersonation a un account compromesso tramite cmdlet PowerShell. Rispetto ad APT29, APT28 tende a operare con meno stratificazione, ma la finalità è identica — accesso trasversale alle mailbox del tenant. La sovrapposizione tecnica tra i due gruppi russi (stesso ruolo abusato, stessa piattaforma target) suggerisce una convergenza dottrinale piuttosto che una condivisione di tool.

Magic Hound (Iran, legato al MRGC/IRGC) porta il pattern in una direzione più orientata alla raccolta intelligence tradizionale. Il gruppo ha ottenuto permessi di lettura su caselle di posta aggiuntive e si è poi autenticato al portale OWA delle vittime per leggere centinaia di comunicazioni riguardanti organizzazioni mediorientali. La campagna HomeLand Justice (C0038), condotta da attori statali iraniani contro le reti governative albanesi tra il 2021 e il 2022, ha visto l'uso dello stesso ruolo ApplicationImpersonation per prendere possesso di mailbox target, ma in un contesto più ampio che includeva ransomware e wiper — un uso ibrido della tecnica dove la raccolta email precede un'azione distruttiva.

Il trend che emerge dall'analisi è chiaro: la delega email è una tecnica di persistence passiva, preferita da attori che necessitano di accesso prolungato e silenzioso a flussi di comunicazione strategici. Il teatro operativo è prevalentemente cloud-oriented (Microsoft 365 è il target dominante), e il ruolo ApplicationImpersonation è il vettore d'elezione. Per l'analista TI, la presenza di modifiche a questo ruolo — specialmente se associate ad account di servizio o Service Principal — deve attivare un'ipotesi di compromissione statale e non solo di BEC opportunistico.

Framework MITRE ATT&CK v16 — tecnica T1098.002, tattiche TA0003 e TA0004, campagne C0038 (HomeLand Justice) e C0024 (SolarWinds Compromise), mitigazioni M1026, M1032, M1042, detection DET0373 (analytic AN1051, AN1052). Integrato con conoscenza professionale per tool e procedure operative.