Manomissione MFA: Multi-Factor Authentication (T1556.006)

In un ingaggio red team, la manomissione MFA arriva dopo aver ottenuto credenziali valide con privilegi sufficienti. La catena tipica inizia con un account compromesso via phishing o MFA fatigue (T1621), prosegue con escalation verso un ruolo che possa toccare le policy di identità, e culmina nella modifica silenziosa del secondo fattore.

Su Azure AD / Entra ID, il tool di riferimento è AADInternals (open source), sviluppato da Nestori Syynimaa. Con un token di accesso valido su un tenant target, il comando Set-AADIntUserMFA consente di disabilitare l'MFA su un utente specifico:

Set-AADIntUserMFA -UserPrincipalName "vittima@target.onmicrosoft.com" -State Disabled

Un'alternativa più stealth è la registrazione di un nuovo metodo MFA controllato dall'attaccante tramite Set-AADIntUserMFAApps, che aggiunge un authenticator senza rimuovere quelli esistenti — l'utente legittimo non si accorge di nulla, ma l'attaccante riceve i prompt.

Su ambienti on-prem, uno scenario documentato è l'abuso di SLOWPULSE (malware attribuito a operazioni contro Pulse Secure VPN): l'impianto modifica il flusso di autenticazione RADIUS/ACE inserendo una logica che, se viene fornita una password magica, bypassa la verifica 2FA. In laboratorio, la simulazione può essere condotta patchando manualmente un binario di autenticazione con Ghidra (open source) o IDA Free (freemium) per identificare la funzione di verifica e alterare il branch condizionale.

Una tecnica low-tech ma efficace su endpoint Windows è la modifica di C:\Windows\System32\drivers\etc\hosts per redirigere l'FQDN del server MFA verso 127.0.0.1. Se il client MFA è configurato fail open, il login procede. Il comando (da prompt amministrativo):

echo 127.0.0.1 mfa.corp.local >> C:\Windows\System32\drivers\etc\hosts

Su Linux, il target sono i moduli PAM: rimuovere o commentare la riga auth required pam_google_authenticator.so in /etc/pam.d/sshd elimina il secondo fattore per SSH. La modifica va accompagnata da timestamp forgiati con touch -r per non alterare mtime evidenti.

Per ambienti AWS, l'obiettivo è la policy IAM: rimuovere condizioni aws:MultiFactorAuthPresent da policy critiche o disabilitare i dispositivi MFA virtuali con aws iam deactivate-mfa-device. Ogni azione va tracciata nel report red team con timestamp preciso, perché sono tutte operazioni ad alto rischio di alert immediato in ambienti con SIEM configurato correttamente.

La detection di T1556.006 richiede correlazione tra eventi di modifica configurazione MFA ed eventi di autenticazione anomali. Il pattern chiave è: cambio policy → login successivo senza challenge MFA → attività su risorse sensibili.

Su Azure AD / Entra, i log da monitorare sono AuditLogs e SignInLogs. Gli eventi rilevanti includono Update conditional access policy, Delete conditional access policy, User registered security info e Admin registered security info for user. Un alert prioritario è la registrazione di un nuovo metodo MFA da un IP geograficamente incoerente con la sede abituale dell'utente, o effettuata da un admin su un account che non gli è stato assegnato in ticket. Query KQL su Log Analytics tipo:

AuditLogs | where OperationName == "Update conditional access policy" | extend Excluded = tostring(TargetResources[0].modifiedProperties)

aiutano a isolare esclusioni di utenti aggiunte silenziosamente.

Su Windows on-prem, gli EventID di riferimento nel canale Security sono 4738 (user account changed), 5136 (directory service object modified) su attributi legati a MFA/smartcard, e 4670 (permissions on object changed). Il canale Microsoft-Windows-PowerShell/Operational con EventID 4104 cattura script che invocano cmdlet AADInternals o moduli MSOnline che modificano MFA.

Su Linux, la detection ruota attorno ad auditd con regole su /etc/pam.d/: una watch rule tipo -w /etc/pam.d/ -p wa -k pam_mod genera eventi SYSCALL ogni volta che un file PAM viene scritto. Correlare con sessioni SSH riuscite nei minuti successivi che non mostrano challenge del modulo TOTP è un indicatore forte.

Su AWS, CloudTrail deve essere filtrato per eventi DeactivateMFADevice, DeleteVirtualMFADevice e modifiche a policy IAM che rimuovono la condizione aws:MultiFactorAuthPresent. Un evento DeactivateMFADevice seguito entro pochi minuti da ConsoleLogin riuscito dallo stesso principal è pattern quasi diagnostico.

Su SaaS (Okta, Duo, Zoom), monitorare eventi di reset factor, factor deactivation e policy exemption. Okta System Log espone eventi come user.mfa.factor.deactivate e policy.rule.update.

I falsi positivi più comuni derivano da attività legittime dell'help desk (reset MFA su richiesta utente), rollout pianificati di nuovi metodi (passaggio da SMS a FIDO2) e onboarding massivo. La tuning strategy passa da whitelist di account service dell'help desk, correlazione con ticket ITSM tramite API, e baseline per ora della giornata — modifiche notturne o weekend meritano severity elevata anche se l'operatore è autorizzato.

L'analisi forense di una manomissione MFA richiede di ricostruire chi ha modificato cosa, quando, e quale accesso ne è derivato. La timeline si costruisce partendo dai log di identity provider e scendendo verso gli endpoint.

In ambiente Microsoft 365 / Azure AD, il Unified Audit Log è la fonte primaria. Vanno esportati con Search-UnifiedAuditLog in PowerShell (richiede modulo Exchange Online Management) coprendo la finestra sospetta e filtrando su operazioni StrongAuthenticationMethod, Update user, Update policy, Add member to role. Ogni record contiene ActorIpAddress, ClientAppUsed e ExtendedProperties che permettono di distinguere azioni via portale, Graph API o PowerShell — le ultime due sono più sospette se non giustificate da automazione nota. Il Sign-in log correlato mostra se le autenticazioni successive dell'utente target abbiano usato authenticationDetails con authenticationStepResultDetail pari a MFA requirement satisfied by claim in the token o MFA not required — il secondo caso, dopo una modifica policy, è la firma dell'abuso.

Su endpoint Windows, gli artefatti chiave sono il registro HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Notify per provider di credenziali modificati, i file di configurazione dei client MFA on-prem (es. Duo, RSA) in *C:\Program Files* e ovviamente C:\Windows\System32\drivers\etc\hosts. Il MFT (analizzabile con MFTECmd di Eric Zimmerman, open source) rivela timestamp di modifica del file hosts anche se l'attaccante ha alterato l'mtime visibile — gli attributi $STANDARD_INFORMATION e $FILE_NAME mostreranno divergenze.

Gli eventi PowerShell registrati in Microsoft-Windows-PowerShell/Operational con EventID 4104 (script block logging) sono determinanti per provare l'uso di AADInternals: il modulo appare esplicitamente nel testo del blocco. Se lo script block logging non era attivo, resta la ricerca di artefatti in AppData\Local\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt per l'utente compromesso.

Su Linux, l'analisi si concentra su /etc/pam.d/ e sui log auditd. Il tool ausearch -k pam_mod estrae tutti gli accessi in scrittura correlati, e aureport --file fornisce contesto sui processi coinvolti. Il file /var/log/secure o /var/log/auth.log mostra le sessioni SSH successive: l'assenza di righe pam_google_authenticator o pam_duo dove prima comparivano è una regressione da segnalare.

Per AWS, CloudTrail va scaricato integralmente per la finestra di interesse e caricato in Athena o Splunk. Eventi DeactivateMFADevice con sourceIPAddress esterno al range aziendale, o eseguiti da ruoli assunti via AssumeRole con path insoliti, meritano ricostruzione completa della catena di identità.

Il panorama degli attori che manipolano MFA post-compromise è dominato da gruppi orientati alla persistenza in ambienti cloud e ibridi. Scattered Spider (G1015), noto anche come UNC3944 e Octo Tempest, è l'esempio più documentato nei dati MITRE per questa tecnica: dopo aver ottenuto credenziali via social engineering — tipicamente chiamando l'help desk fingendosi dipendenti — il gruppo registra i propri token MFA sull'account vittima, ottenendo così controllo persistente indipendente dal reset della password originale.

Lo stile operativo di Scattered Spider è particolarmente insidioso perché ibrida ingegneria sociale telefonica di alto livello (accento nativo inglese, conoscenza dei processi interni della vittima) con esecuzione tecnica rapida in Azure AD e Okta. Gli obiettivi storici includono aziende di telecomunicazioni, BPO, hospitality e casino, con impatto significativo sui settori retail e assicurativo. La motivazione è finanziaria, spesso con deployment finale di ransomware (BlackCat/ALPHV in molte incident note).

Sul fronte tooling, i dati MITRE citano due strumenti direttamente rilevanti. AADInternals (S0677) è un framework PowerShell open source pensato per ricerca, ma ampiamente adottato da attori offensivi per la sua capacità di interagire con API Azure AD non documentate. Il cmdlet Set-AADIntUserMFA è specifico per disabilitare MFA su utenti target senza passare dal portale admin, riducendo l'evidenza nei log di UI. L'adozione da parte di gruppi criminali è documentata da vari vendor di IR.

SLOWPULSE (S1104) rappresenta un modello diverso: malware su misura per apparati Pulse Secure VPN, in grado di bypassare RADIUS e ACE 2FA riconoscendo una password magica fornita dall'attaccante. Attribuito da Mandiant a operazioni sospettate di origine cinese contro target governativi e della difesa, mostra come attori state-sponsored investano in impianti dedicati per aggirare MFA su infrastrutture perimetrali strategiche piuttosto che sull'identity cloud.

Il pattern geografico è polarizzato: attori nation-state (Cina, Russia, Iran, Nord Corea) tendono a colpire MFA su apparati on-prem e VPN, dove la manomissione può restare invisibile per mesi; attori criminali anglofoni come Scattered Spider si concentrano su cloud identity provider, dove la velocità di monetizzazione è maggiore.

Il trend in evoluzione è duplice. Da un lato l'aumento di attacchi al fallback MFA (SMS, chiamate vocali) tramite SIM swap, che spinge i difensori verso FIDO2 e passkey resistenti al phishing. Dall'altro l'emergere di attacchi ad Adversary-in-the-Middle con framework come Evilginx (open source) che rubano token di sessione post-MFA, spostando il problema dalla manomissione del fattore al furto del cookie autenticato.

MITRE ATT&CK T1556.006 (Multi-Factor Authentication), gruppi G1015, software S0677 e S1104, mitigazioni M1018, M1032, M1047, detection DET0190 con analytics AN0543-AN0549. MITRE D3FEND per mapping tecniche difensive Credential Hardening e Authentication Event Thresholding. Documentazione ufficiale AADInternals (Nestori Syynimaa), moduli PAM Linux, AWS IAM CLI reference, Microsoft Graph audit schema. Contenuto arricchito con conoscenza professionale di cybersecurity per comandi operativi, sintassi di tool open source e pattern di detection su piattaforme cloud e on-prem.