Registro del módulo de PowerShell

5

Estoy buscando más información acerca de papel blanco que se detalla en el registro del módulo de PowerShell.

Específicamente, una vez que está habilitado, ¿se registran los cmdlets predeterminados? Por ejemplo, Get-Service y así sucesivamente. Al revisar About_Group_Policy_Settings para PowerShell, se proporciona una referencia a la siguiente ruta de la Política de grupo Computer Configuration\Administrative Templates\Windows Components\Windows PowerShell donde el Registro de módulos muestra un ejemplo de cómo habilitar el registro para los módulos de Windows PowerShell Core utilizando Microsoft.PowerShell.*

Mi pregunta en relación con InfoSec, ¿alguien ha investigado esto desde el punto de vista de un defensor? Específicamente, ¿el hecho de habilitar el registro del Módulo aumenta la posibilidad de exponer más superficie de ataque y, de ser así, hay algunos pasos o mejores prácticas para fortalecer los registros y así sucesivamente en un esfuerzo por mitigar el aumento de la superficie de ataque?

Mi conjetura sería replicar el Registro de eventos para Windows PowerShell en un sistema de alta seguridad o utilizar un cifrado para que, en caso de que un atacante descubriera que el Registro del módulo estuviera habilitado, el cifrado impidiera que los registros se alteren en un esfuerzo por cubrir Las pistas de los atacantes.

    
pregunta user4317867 10.06.2015 - 04:21
fuente

2 respuestas

2

Primero, no especificó si esto es para servidores o para equipos de escritorio.

Pero asumiré servidores por el momento. Para abordar directamente los aspectos de registro del registro de PowerShell ... Sí, puede registrar llamadas de cmdlet. Creo que 3.0 y superior hacen esto con la configuración de GP correcta.

En segundo lugar, los registros de eventos no están cifrados y las ACL para ellos se modifican fácilmente. Por lo tanto, personalmente sugiero usar un SIEM para monitorearlos de forma remota, de modo que pueda buscar algunos de los cmdlets más importantes, como los que se ocupan de la comunicación remota, la modificación del registro de eventos y todo lo relacionado con los permisos, e informar de ello a su herramienta de monitoreo. En caso de que los registros locales sean modificados por un actor malintencionado, tendrá la información en su herramienta de monitoreo.

Sin embargo, si realmente estás interesado en fortalecerte contra los ataques de PowerShell, deberás considerar el fortalecimiento de PowerShell.

Hágase algunas preguntas pertinentes a su situación ...

  1. Pase lo que pase, actualice al menos a PowerShell 4.0. No hay preguntas en este caso.

  2. ¿Desea que CUALQUIER usuario en la máquina ejecute los scripts de PowerShell de forma remota ? De lo contrario, deshabilite el servicio WinRM y bloquee los puertos 8495 y 8496.

  3. ¿Desea que CUALQUIER usuario pueda ejecutar los scripts de PowerShell localmente ? Si no, cambia el nombre
    3a). C: \ Windows \ SysWOW64 \ WindowsPowerShell \ v1.0 \ powershell.exe y powershell_ise.exe a otro nombre.
    3b). C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe y powershell_ise.exe con otro nombre.

Dependiendo de sus respuestas a lo anterior, este es un buen comienzo para montar una defensa. Pero tenga en cuenta, esto es sólo una capa de muchos. Si tienen administradores en el cuadro, pueden cambiar el nombre, volver a habilitar todo a su valor predeterminado, incluida la eliminación de todos los registros.

Dependiendo de lo que SIEM use, asumamos Splunk por el momento: puede agregar una fuente al archivo de búsqueda previa para PowerShell que generalmente es:% systemroot% \ prefetch \ powershell.exe. *. pf y busque ". ps1 "en el archivo. También puede monitorear la última modificación y otros campos pertinentes.

Esto es especialmente efectivo en los sistemas que aún utilizan PowerShell 2.0 y no tienen la capacidad de actualizarse a PowerShell 3.0 o superior para aprovechar los registros de eventos de Windows PowerShell.

    
respondido por el mumbles 29.12.2016 - 08:05
fuente
1

También me interesa tu pregunta, pero ¿has visto el siguiente enlace sobre v5?

seguridad avanzada en powershell v.5

  

Además de la transcripción de estilo por encima del hombro, PowerShell v5   y KB 3000850 introduce el registro de bloque de script profundo. Cuando habilitas   el registro de bloque de secuencias de comandos, PowerShell registra el contenido de todas las secuencias de comandos   Bloques que procesa. Si un bloque de script usa código dinámico   generación (es decir, $command = "'Hello World'"; Invoke-Expression $command ), PowerShell registrará la invocación de este script generado   bloque tambien Esto proporciona una visión completa de la base de comandos   actividad en un sistema, incluidos scripts o aplicaciones que aprovechan   generación de código dinámico en un intento de evadir la detección.

     

Al igual que con el soporte de transcripción, este registro de bloque de secuencia de comandos se aplica   a cualquier aplicación que aloja el motor PowerShell: la línea de comandos   shell, ISE o host personalizado.

     

Para habilitar la transcripción automática, habilite la ‘Activar PowerShell   Función de registro de bloque de scripts en la Política de grupo a través de Windows Components -> Administrative Templates -> Windows PowerShell . por   automatización, los ajustes de configuración se almacenan en   %código%.   De forma predeterminada, PowerShell solo registra los bloques de scripts la primera vez que   son usados. Si selecciona ‘Log script block block start / stop   'eventos', PowerShell también registra los eventos de inicio y detención para cada vez que   Se invoca el bloque de script. Este último ajuste puede generar un extremadamente   un gran volumen de eventos, por lo que debe habilitarse con precaución.

También dice:

  

Una de las preocupaciones al aumentar la cantidad de registro en un sistema es la   peligro de que el contenido registrado pueda contener datos confidenciales. Por ejemplo, si   registra el contenido de cada script de PowerShell que se ejecutó, hay   la posibilidad de que un script pueda contener credenciales u otros   datos sensibles.

     

Si un atacante compromete luego una máquina que ha registrado estos datos,   les puede proporcionar información adicional para ampliar   su alcance.

     

Para evitar este dilema, Windows 10 introduce Evento protegido   Explotación florestal. El registro de eventos protegido permite a las aplicaciones participantes   encripta los datos confidenciales a medida que los escriben en el registro de eventos. Entonces puedes   descifre y procese estos registros una vez que los haya movido a un lugar más seguro   y colector de registro centralizado.

    
respondido por el user86114 05.09.2015 - 15:13
fuente

Lea otras preguntas en las etiquetas