Registrazione del modulo di PowerShell

Question

Registrazione del modulo di PowerShell

#1 da (2 voti)
#2 da (1 voti)

5

Sto cercando altre informazioni riguardanti white paper che entra in dettaglio sulla registrazione del modulo di PowerShell.

In particolare, una volta abilitato, i cmdlet predefiniti sono registrati? Ad esempio, Get-Service e così via. Esaminando About_Group_Policy_Settings per PowerShell, viene fornito un riferimento al seguente percorso di criteri di gruppo Computer Configuration\Administrative Templates\Windows Components\Windows PowerShell dove Module Logging elenca un esempio di abilitazione della registrazione per i moduli di Windows PowerShell Core utilizzando Microsoft.PowerShell.*

La mia domanda relativa a InfoSec, qualcuno ha esaminato questo dal punto di vista di un difensore? In particolare, abilitare la registrazione del modulo aumenta la possibilità di esporre più superficie di attacco e, in caso affermativo, ci sono dei passi o delle migliori pratiche per indurire i registri e così via nel tentativo di mitigare l'aumento della superficie di attacco?

La mia ipotesi sarebbe replicare il registro eventi per Windows PowerShell su un sistema ad alta sicurezza o utilizzare la crittografia in modo che, nel caso in cui un utente malintenzionato scoprisse che il modulo di registrazione era abilitato, la crittografia avrebbe impedito la modifica dei log nel tentativo di coprire le tracce degli attaccanti.

logging powershell hardening

posta user4317867 10.06.2015 - 04:21

fonte

2 risposte

Leggi altre domande sui tag logging powershell hardening

Un funzionario disabilita in modo efficace l'HTML (6?) elemento / wrapper di combattimento XSS? La BCE è sicura se posso garantire di non crittografare mai lo stesso blocco due volte?

score 2 · Answer 1

Innanzitutto, non hai specificato se si tratta di server o desktop.

Ma assumerò i server per il momento. Per indirizzare direttamente gli aspetti di registrazione della registrazione di PowerShell ... Sì, può registrare le chiamate dei cmdlet. Credo che 3.0 e precedenti facciano questo con le giuste impostazioni GP.

In secondo luogo, i registri eventi non sono crittografati e gli ACL per loro sono facilmente modificabili. Quindi, personalmente suggerisco di utilizzare un SIEM per monitorarli da remoto, in modo da poter cercare alcuni dei cmdlet più importanti, come quelli che si occupano di remoting, modifica del log degli eventi e qualsiasi cosa relativa alle autorizzazioni e riportarli allo strumento di monitoraggio in modo tale che nel caso in cui i registri locali vengano modificati da un attore malevolo, hai le informazioni nel tuo strumento di monitoraggio.

Tuttavia, se si è veramente interessati a rafforzare gli exploit di PowerShell, è necessario prendere in considerazione il rafforzamento di PowerShell stesso.

Porsi alcune domande pertinenti alla tua situazione ...

Indipendentemente dall'aggiornamento ad almeno PowerShell 4.0. Nessuna domanda su questo.
Vuoi che QUALSIASI utente sul computer esegua script PowerShell in remoto ? In caso contrario, disabilitare il servizio WinRM e bloccare le porte 8495 e 8496.
Vuoi che QUALSIASI utente sia in grado di eseguire script PowerShell localmente ? In caso contrario, rinomina:
3a). C: \ Windows \ SysWOW64 \ WindowsPowerShell \ v1.0 \ powershell.exe e powershell_ise.exe con un altro nome.
3b). C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe e powershell_ise.exe con un altro nome.

A seconda delle tue risposte a quanto sopra, questo è un buon inizio per montare una difesa. Ma fai attenzione, questo è solo uno strato di molti. Se hanno un amministratore nella casella, possono rinominare, riabilitare tutto in modo predefinito, includendo la cancellazione di tutti i registri.

A seconda del SIEM che usi, supponiamo Splunk per il momento - puoi aggiungere una fonte al file di prefetch per PowerShell che generalmente è:% systemroot% \ prefetch \ powershell.exe. *. pf e cerca ". ps1 "nel file. Puoi anche monitorare l'ultima modifica e altri campi pertinenti.

Questo è particolarmente efficace sui sistemi che utilizzano ancora PowerShell 2.0 e non hanno la possibilità di eseguire l'aggiornamento a PowerShell 3.0 o versioni successive per sfruttare i registri eventi di Windows PowerShell.

score 1 · Answer 2

Anche io sono interessato alla tua domanda, ma hai visto il seguente link su v5?

sicurezza avanzata in powershell v.5

In addition to over-the-shoulder style transcription, PowerShell v5 and KB 3000850 introduces deep script block logging. When you enable script block logging, PowerShell records the content of all script blocks that it processes. If a script block uses dynamic code generation (i.e.: $command = "'Hello World'"; Invoke-Expression $command), PowerShell will log the invocation of this generated script block as well. This provides complete insight into the script-based activity on a system – including scripts or applications that leverage dynamic code generation in an attempt to evade detection.

As with transcription support, this deep script block logging applies to any application that hosts the PowerShell engine – the command line shell, ISE, or custom host.

To enable automatic transcription, enable the ‘Turn on PowerShell Script Block Logging’ feature in Group Policy through Windows Components -> Administrative Templates -> Windows PowerShell. For automation, the configuration settings are stored under HKLM:\Software\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging. By default, PowerShell only logs scripts blocks the first time they are used. If you select ‘Log script block invocation start / stop events’, PowerShell also logs start and stop events for every time a script block is invoked. This latter setting can generate an extremely high volume of events, so should be enabled with caution.

Inoltre dice:

One concern when increasing the amount of logging on a system is the danger that logged content may contain sensitive data. For example, if you log the content of every PowerShell script that was run, there is the possibility that a script may contain credentials or other sensitive data.

If an attacker later compromises a machine that has logged this data, it may provide them with additional information with which to extend their reach.

To prevent this dilemma, Windows 10 introduces Protected Event Logging. Protected Event Logging lets participating applications encrypt sensitive data as they write it to the event log. You can then decrypt and process these logs once you’ve moved them to a more secure and centralized log collector.