Blue Team Experience: Detection and Mitigation con l’utilizzo di Mimikatz

Le odierne tecniche di attacco verso infrastrutture Microsoft Active Directory sono molto variegate ed efficaci. Tendenzialmente si basano sull’estrema personalizzazione che Active Directory consente e sulla difficoltà oggettiva nel conoscere ed utilizzare correttamente tutti gli strumenti di sicurezza messi a disposizione. Voglio ricordare che, parlando solo dei criteri di gruppo (ovvero le GPO), tra circa 4500 possibili configurazioni circa 1500 sono esclusivamente orientate alla security.

Quando leggiamo sui giornali di “Data Breach”, “Data Exfiltration”, “Data Leak”, “Ransomware” su infrastrutture Microsoft, possiamo sicuramente ipotizzare che parte dell’attacco sia stato effettuato utilizzando il tool Mimikatz.

Abbiamo già avuto modo di parlarne durante l’evento POWERCON2022. In questo articolo proviamo ad approfondire il tema.

Cos’è Mimikatz? Un tool opensource ideato per attività di pentest da Benjamin Delpy e Mr. Slovtsov. Col passare del tempo, dato l’ottimo funzionamento di questo oggetto, è stato sempre più largamente utilizzato da attori malevoli. Esattamente come è accaduto per Cobalt Strike, lo strumento utilizzato come C2 (Command and control).

Uno dei suoi maggiori utilizzi è quello di estrarre gli hash delle password degli utenti se viene eseguito da un utente con determinati privilegi.

In questo articolo affronteremo due temi:

  • Mimikatz: utilizzo e prevenzione
  • Attacchi verso AD: come rilevarli

Il primo tema affronterà i seguenti argomenti:

  • Debug Privilege
  • WDigest
  • LSA Protection
  • Restricted Admin Mode
  • Credential Caching
  • Protected Users Group

Il secondo tema affronterà, invece, le seguenti tecniche d’attacco:

  • Skeleton Key
  • DSRM – Directory Services Restore Mode
  • Malicious SSP (Security Support Provider)
  • Kerberoast
  • Delegation
  • DCShadow

Debug Privilege

Il tool Mimikatz utilizza questo privilegio per interagire con il processo LSASS. L’acronimo sta per Local Security Authority Server Service e nei sistemi operativi Microsoft è responsabile dell’applicazione delle policy di sicurezza.

Questo privilegio determina quali utenti possono collegare un debugger a qualsiasi processo o al kernel. Agli sviluppatori che debuggano le proprie applicazioni non è necessario assegnare questo privilegio utente mentre per gli sviluppatori che debuggano nuovi componenti di sistema ne avranno bisogno per poterlo fare.

La configurazione di default prevede che solo gli amministratori locali abbiano questi privilegi.

Eseguendo Mimikatz con il seguente comando è possibile verificare se questi privilegi sono abilitati:

privilege::debug

Figura 1 – Check to validate debug privilege

Figura 2 – Debug programs privilege — Local Administrators

Prendendo, ad esempio, Windows Server 2016, di default questa configurazione è nello stato “Not Defined”, ovvero abilitata solo per l’amministratore locale.

Figura 3 – Debug programs privilege — Group Policy

Il SeDebugPrivilege può essere disabilitato utilizzando la GPO “Debug Programs” e definendo la policy senza utenti o gruppi.

Nello specifico: Group Policy Management Editor -> Windows Settings -> Security Settings -> Local Policies -> User Rights Assignment -> Debug programs -> Define these policy settings:


Figura 4 – Disable the SeDebugPrivilege

Gli utenti o i gruppi inseriti all’interno della configurazione manterranno la possibilità di utilizzare i Debug Privileges.

Dopo aver applicato la policy, il comportamento di Mimikatz sarà il seguente:

Figura 5 – Mimikatz — Debug Privilege Disabled

Questa configurazione può essere effettuata anche per macchine non a dominio utilizzando una Local Policy:

Local Group Policy Editor > Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment > Debug programs

Figura 6 – Local Group Policy

WDigest

Questo protocollo è stato introdotto con Windows XP. Denominata Digest Authentichation, è stata pensata per unire concetti di Simple Authentication Security Layer (SASL) e HTTP. In buona sostanza, per permettere l’autenticazione via HTTP basata su scambio di chiavi. Anche questo protocollo è abilitato di default su diversi OS e, purtroppo, implica che le password relative agli utenti immagazzinate all’interno del processo LSASS sono in plain-text (in chiaro).

Questa è un’occasione ghiotta per un attaccante che, utilizzando Mimikatz, può recuperarle utilizzando il seguente comando:

sekurlsa::wdigest

Figura 7 – Mimikatz – WDigest

Questo protocollo è disabilitato in Microsoft Windows 8.1, Windows 10, Windows Server 2012 R2 and Windows Server 2016.

Nei sistemi più datati Microsoft ha rilasciato una patch per permettere agli amministratori di abilitare/disabilitare il protocollo WDigest. La KB di riferimento è la 2871997 il cui download lo si può effettuare dal sito ufficiale Microsoft.

Dopo aver installato la patch è possibile verificare all’interno del registro di sistema la presenza della chiave “UseLogonCredential” e “Negotiate“, entrambe settate a 0, all’interno delle configurazioni dei Security Providers, nello specifico per il protocollo in oggetto:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\WDigest

Figura 8 – WDigest – Disabled

A questo punto, se un attaccante tentasse di sfruttare il meccanismo di comunicazione in chiaro delle credenziali tramite Wdigest, riceverebbe il seguente messaggio d’errore:

Figura 9 – Mimikatz – WDigest Disabled

Nei sistemi operative recenti la chiave UseLogonCredential non esiste ma, dopo aver disabilitato il protocollo, se un amministratore locale modificasse il registro creando la chiave e configurandola ad 1 si avrebbe l’evidenza di un attacco. Per questo motivo con un monitoraggio attivo delle modifiche di registro rende possibile identificare e gestire tentativi di attacco.

LSA Protection

Il servizio LSASS (Local Security Authority Server Service) convalida gli utenti per gli accessi locali e remoti ed applica i criteri di sicurezza locali. In Windows 8.1 e versioni successive è presente una protezione aggiuntiva della LSA per impedire ai processi non attendibili di leggere la memoria o di iniettare codice.

Usando il seguente comando Mimikatz è possibile recuperare le password in chiaro leggendo dalla memoria della LSA:

sekurlsa::logonPasswords

Figura 10 – Mimikatz – Interact with LSA

Nei sistemi precedenti alle versioni Windows Server 2012 R2 e Windows 8.1 è possibile abilitare la protezione LSA per impedire a Mimikatz di accedere ad una posizione di memoria specifica del processo LSASS.

Questa protezione può essere attivata creando la chiave del Registro di sistema RunAsPPL e impostando il valore 1 nel seguente percorso:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA

Figura 11 – LSA Protection Enabled

In questo caso, eseguendo Mimikatz e tentando l’accesso a quella porzione di memoria otterremmo il seguente errore:

Figura 12 – Mimikatz – LSA Protection

Restricted Admin Mode

Il Restricted Admin Mode è stato progettato per aiutare la protezione degli account privilegiati (amministratori) assicurandosi che le credenziali riutilizzabili non siano conservate in memoria sul server remoto che, potenzialmente, potrebbe essere compromesso.

Microsoft ha introdotto in Windows Server 2012 R2 una funzionalità di sicurezza aggiuntiva che può impedire l’archiviazione delle credenziali di testo in chiaro degli amministratori locali in LSASS durante una sessione RDP. Anche se la protezione LSA può impedire a Mimikatz di recuperare tali credenziali, si consiglia di utilizzare questa funzione come ulteriore livello di sicurezza nel caso in cui un utente malintenzionato riuscisse a disabilitare la protezione LSA.

Per Windows 7 e Windows Server 2008 R2, Microsoft ha rilasciato gli aggiornamenti KB2984972 per RDC (Remote Desktop Connection) e KB2984976 per RDP (Remote Desktop Protocol). Per Windows 8 e Windows Server 2012, l’aggiornamento è la KB2984976.

Per fare ciò è necessario creare la chiave di registro “DisableRestrictedAdmin” con valore 0 nei sistemi a cui è consentito ricevere sessioni RDP in modalità amministratore con restrizioni e la chiave “DisableRestrictedAdminOutboundCreds” con valore 1 per impedire la network authentication dall’interno del sistema in cui l’amministratore ha eseguito l’RDP.

In assenza di questa seconda chiave le credenziali di Admin in uscita sono abilitate.

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa

Figura 13 – Restricted Admin Mode – Enabled

Questa configurazione può essere applicata tramite la GPO “Restrict delegation of credentials to remote servers” per garantire che tutte le sessioni RDP in uscita utilizzino la modalità “RestrictedAdmin

Figura 14 – Restrict Delegation of Credentials – GPO

La configurazione della policy deve avere l’impostazione “Require Restricted Admin

Figura 15 – Restrict Delegation of Credential – Enabled Restricted Admin

Dopo aver applicato la policy gli amministratori possono utilizzare il protocollo RDP per collegarsi a server e workstation a patto che questi dispongano della chiave di registro richiesta. Il comando da utilizzare è il seguente:

Figura 16 – Restricted Admin Mode Switch – Run

Oppure eseguendolo direttamente da un prompt dei comandi

Figura 17 – Restricted Admin Mode Switch – Command Prompt

Per i sistemi operativi precedenti a Windows 2012 R2 e Windows 8.1 questa configurazione viene resa disponibile nella patch Microsoft KB2871997.

Credential Caching

Nel caso in cui un Domain Controller sia non raggiungibile, per autenticare un utente il sistema operativo controllerà gli hash delle ultime password memorizzati nella cache.

Windows, come configurazione di default, consente la memorizzazione degli hash delle ultime 10 password.

Questi sono ubicati nella seguente chiave di registro:

HKEY_LOCAL_MACHINE\SECURITY\Cache

Una buona pratica è quella di prevenire il local caching delle password modificando la seguente Local Security Policy, impostando il numero di oggetti memorizzato a 0 o, comunque, ad un numero inferiore a quello di default:

Computer Configuration -> Windows Settings -> Local Policy -> Security Options -> Interactive Logon: Number of previous logons to cache -> 0

Figura 18 – Interactive Logon – Do not cache Logons

Bisogna tenere in considerazione che impostando a 0 il numero di oggetti memorizzati in cache, in caso di assenza di comunicazione con il DC, potrebbe essere impossibile effettuare l’azione di logon.

Mimikatz è in grado di recuperare questi hash con il seguente comando:

lsadump::cache

Nel caso in cui un attaccante utilizzasse questa tecnica, dopo aver disabilitato il caching, otterrebbe questo risultato:

Figura 19 – Mimikatz – Credential Caching Disabled

Protected Users Group

Con Windows Server Server 2012 R2 sono state introdotte novità in termini di sicurezza, tra cui il gruppo “Protected Users“, i cui membri che eseguono l’autenticazione in un dominio con livello funzionale 2012 R2 non sono più in grado di:

  • Autenticarsi con la NTLM authentication;
  • Utilizzare i protocolli di crittografia DES or RC4 nella Kerberos pre-authentication;
  • Essere delegati con unconstrained o constrained delegation;
  • Rinnovare i TGT Kerberos oltre le quattro ore iniziali.

La Constrained Delegation (delega vincolata) fornisce agli amministratori di servizio la possibilità di applicare restrizioni limitando l’ambito in cui i servizi possono agire per conto di un utente.

La Unconstrained Delegation (delega svincolata) consente ad un’entità di rappresentare l’utente in qualsiasi altro servizio scelto. Il DC inserisce una copia del TGT dell’utente nel service ticket. Quando il service ticket dell’utente (TGS) viene mandato al server per l’utilizzo del servizio, il server apre il TGS e inserisce il TGT dell’utente nel LSASS per un uso successivo consentendo al server di impersonare l’utente.

Le impostazioni per la scadenza TGT vengono stabilite per ogni account nel gruppo Protected Users. In genere, il DC imposta la durata e il rinnovo dei TGT in base ai criteri di dominio, alla durata massima per il ticket utente e alla durata massima per il rinnovo del ticket utente. Per il gruppo Protected Users, per questi criteri di dominio sono impostati 600 minuti.

Il gruppo Protected Users consente agli amministratori di dominio di proteggere gli utenti con privilegi come gli amministratori locali, poiché qualsiasi account che fa parte di questo gruppo può eseguire l’autenticazione di dominio solo tramite Kerberos. Ciò consente di prevenire il dump dell’hash di password NTLM o credenziali in chiaro nell’LSASS per gli account sensibili, caratteristica evidente negli attacchi ad infrastrutture AD con tool come Mimikatz.

Il security group “Protected Users” può essere trovato in “Active Directory User and Computer”

Figura 20 – Active Directory – Protected Users Security Group

Gli account che vengono inseriti in questo gruppo acquisiscono automaticamente le kerberos policy

Figura 21 – Kerberos Default Policy

L’azione di inserimento all’interno del security group può essere eseguita anche tramite PowerShell con il comando:

Add-ADGroupMember –Identity ‘Protected Users’ –Members Domenico

Figura 22 – Protected Users Group – Add Accounts via PowerShell

Con la KB2871997 Microsoft ha reso possibile l’utilizzo del Protected Users Group anche su Windows Server 2008.

Dopo aver analizzato queste configurazioni spostiamo l’attenzione su alcune tipologie d’attacco particolarmente utilizzate nei moderni attacchi ad infrastrutture Active Directory. Un corretto monitoraggio rappresenta la principale difesa a nostra disposizione. Per questo motivo ogni tecnica spiegata di seguito sarà rappresentata da una breve descrizione, dalle evidenze (principalmente gli eventi di sistema) che li caratterizzano e da una serie di azioni che possono mitigarle.

Skeleton Key

Questa tecnica di attacco è caratterizzata dall’utilizzo di un oggetto (ad esempio Mimikatz, PowerShell Empire, ecc…) caricato in memoria, in quella fase denominata “post exploitation”, che consente ad un attaccante di autenticarsi come un qualsiasi utente di dominio utilizzando una sorta di master password.

Può essere utilizzata a patto di avere i privilegi di Domain Admin e non è rilevabile da sistemi Network-based Intrusion Detection o IPS/IDS.

Eventi

Analizzando gli eventi di sistema, nel caso di utilizzo di questa tecnica, è possibile notare quanto segue:

  • System Event ID 7045: A service was installed in the system. (Type Kernel Mode driver)

Eventi (Gli “Audit privilege use” devono essere abilitati)

  • Security Event ID 4673 –Sensitive Privilege Use
  • Event ID 4611 – A trusted logon process has been registered with the Local Security Authority

Comandi

La ricerca di questi eventi può essere effettuata anche tramite PowerShell. Ad esempio:

  • Get-WinEvent -FilterHashtable @{Logname=’System’;ID=7045} | ?{$_.message -like “*Kernel Mode Driver*”}

Mitigazioni

  • Eseguire il processo “lsass.exe” come processo protetto
  • New-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\ -Name RunAsPPL -Value 1 -Verbose
  • Controllare dopo il riavvio
  • Get-WinEvent -FilterHashtable @{Logname=’System’ ; ID=12} |?{$_.message -like “*protected process*”}

Figura 23 – Skeleton Key – Key

Figura 24 – Skeleton Key – Event Log

DSRM – Directory Services Restore Mode

Ogni Domain Controller utilizza due account amministrativi: l’AD Administrator Account per il login al DC ed è gestito dall’LSASS e l’account amministratore locale (hard-coded) interno immagazzinato nel SAM file.

Quest’ultimo viene utilizzato durate l’azione di promote del Domain Controller per inserire la password del DSRM (Directory Services Restore Mode, utilizzato per il ripristino di Active Directory in caso di problemi), password che raramente viene cambiata. Un attaccante potrebbe utilizzare queste informazioni per creare una persistenza nel DC.

Eventi

  • Event ID 4657: Creazione o modifica della chiave di Registro: “HKLM:\System\CurrentControlSet\Control\Lsa\DsrmAdminLogonBehavior” (solo se le audit policy sono attive)
  • Event ID 4264: Account Logon
  • Event ID 4634: Account Logoff
  • Event ID 4672: Admin Logon
  • Event ID 4794: An attempt was made to set the Directory Services Restore Mode administrator password (richiede il controllo delle sottocategorie Gestione account/Gestione utenti abilitato nella versione 2008 R2 e successive).

Figura 25 – DSRM – Audit Policy

Mitigazioni

  • Assicurarsi che le credenziali per gli account DSRM siano diverse per ogni Domain Controller e che vengano aggiornate regolarmente.
  • La chiave di registro:
    HKLM\System\CurrentControlSet\Control\Lsa\DsrmAdminLogonBehavior” non deve esistere o deve avere come valore “1”. Questo forza l’arresto del servizio “Directory Services” al logon del DSRM.

Figura 26 – DSRM – Events

Figura 27 – DSRM – Event 4657

Ad esempio, utilizzare il comando:

Set-ItemProperty “HKLM:\SYSTEM\CURRENTCONTROLSET\CONTROL\LSA” -name DsrmAdminLogonBehavior -value 1 -Verbose

Figura 28 – DSRM – Set Key

Malicious SSP (Security Support Provider)

L’interfaccia SSPI (Security Support Provider Interface) consente di estendere facilmente i metodi di autenticazione di Windows consentendo l’aggiunta di nuovi Security Support Providers.

In questo caso, se un attaccante riesce ad avere i privilegi di Domain Admin può utilizzare questa tecnica per creare una persistenza.

Eventi

  • Event ID 4657: Creazione o modifica della chiave di Registro: “HKLM:\System\CurrentControlSet\Control\Lsa\SecurityPackages\”

Comandi

  • Controllare l’esistenza del file “mimilsa.log” o “kiwissp.log” (solitamente in System32) sui Domain Controller

Mitigazioni

  • Controllare le chiavi di registro:
    “HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Security Packages” e
    “HKLM\SYSTEM\CurrentControlSet\Control\Lsa\OSConfig\Security Packages” se nei loro valori è presente “mimilib” o valori riconducibili a Mimikatz.
  • Monitorare l’esecuzione di comandi su cmd.exe e PowerShell.

Kerberoasting

Kerberoasting è una tecnica di attacco usata nella fase di post-exploitation per tentare di decifrare la password di un account di servizio all’interno di Active Directory. Può essere eseguita da qualsiasi utente all’interno del dominio, non necessariamente da un domain admin, anche “offline”; pertanto, non necessita di inviare pacchetti al servizio target.

In un attacco di questo tipo, un attaccante “mascherato” da un account utente, richiede un ticket per un Service Principal Name (SPN), che contiene una password crittografata o Kerberos. Dopo aver richiesto il ticket, utilizza tecniche di brute force per craccare l’hash della password ricevuta.

Eventi

  • System Event ID 4769: A kerberos ticket was requested
  • Siccome l’evento 4769 è loggato molto frequentemente sui DC è consigliato utilizzare dei filtri:
    • Il service name deve essere diverso da krbtgt
    • Il service name non termina con “$”
    • L’account name deve essere diverso da “macchina@dominio” (Così dai filtrare le richieste dalle macchine”)
    • Il Failure code “0x0”
    • La tipologia di ticket encryption “0x17” – Crittografia RC4 più debole (obsoleta) di AES-256
    • Il Ticket Options “0x40810000”

Figura 29 – Kerberoast – Event 4769

Comandi

Get-WinEvent -FilterHashtable @{Logname=’Security’;ID=4769} -MaxEvents 1000 |
?{$_.Message.split(“n")[8] -ne 'krbtgt' -and
$_.Message.split("
n”)[8] -ne ‘*$’ -and
$_.Message.split(“n")[3] -notlike '*$@*' -and $_.Message.split("n”)[18] -like ‘*0x0*’ -and $_.Message.split(“`n”)[17] -like “*0x17*”} | select -ExpandPropertymessage

Mitigazioni

  • Le password degli account di servizio devono essere complesse (maggiori di 25 caratteri).
  • Utilizzare Managed Service Accounts (Cambio password degli SPN periodico automatico).

Un Managed Service Account (sMSA) è un account di dominio che si occupa della gestione delle password in maniera automatica, semplifica la gestione dei Service Principal Name (SPN) e ha la possibilità di delegare la gestione ad altri. Questa funzionalità è stata introdotta con Windows Server 2008 R2 e Windows 7

Delegation

Questa tecnica consiste nell’identificazione di configurazioni errate nell’utilizzo della Unconstrained Delegation (Delega Svincolata). L’attaccante potrebbe utilizzare questo approccio per movimenti laterali o privilege escalation.

Comandi

  • Mostra le macchine su cui è abilitata l’unconstrained delegation
    Get-ADComputer -Filter {TrustedForDelegation -eq $true -and primarygroupid -eq 515} -Properties trustedfordelegation,serviceprincipalname,description
  • Mostra gli utenti con costrained delegation abilitata
    Get-DomainUser -TrustedToAuth

Mitigazioni

  • Disabilitare l’unconstrained delegation e configurare la constrained delegation ove necessario.
  • Abilitare il parametro “Account is sensitive and cannot be delegated” per account amministrativi come i Domain Admins.
  • Aggiungere gli account amministrativi a rischio all’interno del gruppo “Protected Users Group” così da prevenire la possibilità di deleghe.
  • Limitare la possibilità di accesso dei Domain Admin/Admin a specifici server.

DCShadow

Il DCShadow è una tecnica d’attacco utilizzata per imitare un Domain Controller ed effettuare modifiche in Active Directory. Per essere effettuata richiede privilegi elevati (Domain Admin oppure Enterprise Admin) ma è difficile da rilevare poiché utilizza un protocollo documentato/noto (MT-ADTS e MS-DRSR) per poter interagire con il dominio.

Eventi

  • Event ID 4742: monitor computer change events (controllare l’aggiunta di eventuali SPNs al computer)
  • Event ID 5137: Aggiunta di un nuovo DC (Contiene il nome del rouge DC e l’account con cui è stato creato)
  • Event ID 5141: Cancellazione dell’evento precedente e del rogue DC
  • Event ID 4928: An Active Directory replica source naming context was established
  • Event ID 4929: Replication event log (controllare se effettuato da un DC valido)
  • Event ID 4935/4936: Replication failure
  • A livello network è possibile verificare chi utilizza le API DrsAddEntry or DrsReplicaAdd, utilizzate solo dai Domain Controller.

Mitigazioni

  • Controllare i seguenti permessi, che siano associati alle corrette utenze:
    • Add/Remove Replica in Domain (DS-Install-Replica)
    • Manage Replication Topology (DS-Replication-Manage-Topology)
    • Replication Synchronization (DS-Replication-Synchronize)
  • Controllare i seguenti permessi sul dominio, che siano associati alle corrette utenze:
    • Create all child objects
    • Delete all child objects
  • Rimuovere eventuali permessi ad utenze non necessarie
  • Impedire la delega degli account Domain Admin e non utilizzarli come account di servizio

Zircolite

Come abbiamo avuto modo di constatare, il numero di oggetti da monitorare è enorme e l’attenzione da porre deve essere alta. Per aiutare quelle realtà dove non è sempre possibile utilizzare strumenti e tecnologie costose, è possibile utilizzare altro in grado di dare una mano nelle attività di un Blue Team.

Zircolite è tool opensource presente su github. Utilizza le SIGMA rules per l’analisi dei log di tipo EVTX, Auditd, Sysmon o JSONL/NDJSON: firme testuali scritte in YAML progettate per identificare attività sospette o cyber threat all’interno dei log.

Figura 30 – Zircolite – Home

Figura 31 – Zircolite – Matrix

Sottoponendo i log a questo tool è possibile effettuare anche l’analisi di grosse moli di dati, ottenendo dei risultati di semplice interpretazione basati sul framework MITRE ATT&CK.

Conclusioni

Le tecniche di attacco utilizzate da attori malevoli sono sempre più complesse ed intricate. Una buona prassi è quella di aggiungere altri livelli di sicurezza a patto di essere consapevoli del loro funzionamento. Microsoft mette a disposizione tutta una serie di possibili configurazioni gratuite che possono aiutare nelle attività di Blue Team ma, troppo spesso, restano immutate e con le impostazioni di default. Se, invece, configurate correttamente possono rendere molto complesso l’utilizzo di tool offensivi, facendo in modo che tutte queste tecniche siano rumorose, in grado di essere evidenziate tramite vari eventi e/o metodi. Tutto questo è sicuramente di grande aiuto nelle attività di rilevazione, contenimento ed eradicazione di un attacco.

Stay tuned!