En el blog hemos hablado de diferentes cosas relacionadas con el pentesting con Powershell. Ya hemos hablado sobre la protección de AMSI y las necesidades de hacer un bypass cuando uno está haciendo Ethical Hacking, sobretodo si hay sistemas Windows 10 por medio. Como nota dejar por aquí una charla y presentación de BlackHat de años anteriores donde se presentaban formas de saltarse AMSI, recomendable su lectura.

Figura 1: Pentesting con PowerShell: Powershell Transcription, Constrained Language y otras medidas de protección en un Ethical Hacking

El martes 26 daré un RootedLab sobre PowerShell y sus posibilidades ofensivas en un pentest. Los asistentes tendrán un cupón descuento para libros míos de 0xWord. Hoy, quería hablaros sobre las posibilidades de defensa que Powershell ha empezado a tener, ya que no todo es ataque para eso ya tenéis el libro de Pentesting con Powershell 2ª Edición.

Figura 2: Pentesting con Powershell 2ª Edición

Por supuesto, y como digo siempre, cuando sale una protección o una forma de restringir acciones, se investiga la forma de saltarse esa protección. Es una acción natural que ayuda a mejorar la solvencia y potencia de la protección. El juego del gato y del ratón, así que vamos a ver cómo hacer algo de lo que trata el libro de mi compañero Sergio de los Santos, aplicar políticas para alcanzar la "Máxima Seguridad en Windows"

Política de ejecución

La política de ejecución de scripts de Powershell es un concepto que está presenta desde hace mucho tiempo, desde las primeras versiones de Powershell. El objetivo inicial era marca qué se podía ejecutar y en qué ámbito. Un ejemplo sencillo es visualizar lo siguiente:

• Restricted: Política restringida, no se puede ejecutar ningún script de Powershell a través de dicho proceso.
• Unrestricted: Política totalmente no restringida. Se puede ejecutar cualquier script en Powershell.
• RemoteSigned: Se puede ejecutar solo scripts creados localmente y si son remotos o descargados, solo si están firmados.
• Signed: Se pueden ejecutar scripts solo si están firmados.

Aparecieron más políticas y se fue perdiendo el foco. Por ejemplo, hay una política que es ‘Bypass’.

Figura 3: Powershell.exe -Exec Bypass

Con esta política se puede ejecutar un proceso de Powershell, donde el usuario puede ejecutar scripts, simplemente arrancando el proceso con dicha política, por ejemplo: powershell.exe –Bypass.

Constrained Language

Una de las evoluciones para evitar ciertas acciones ‘maliciosas’ fue la llamada Constrained Language o modo de lenguaje restringido. La idea que radica detrás de este modo es poder utilizar o dar soporte a las tareas administrativas del día a día y restringir el acceso a la parte sensible del lenguaje de Powershell. Ese lenguaje que puede ser utilizado para invocar APIs de Windows orientadas a otro tipo de tareas, no tan administrativas.

Aquí tenemos una nueva protección, por lo que tenemos a gente buscando la posibilidad de saltar la protección. ¿El resultado? La mejora de la solución de protección, si se tiene en cuenta que hay vías de saltarla.

Figura 4: Deteccion del tipo de lenguaje

Para ver el tipo de lenguaje que tenemos se puede ejecutar $ExecutionContext.SessionState.LanguageMode. Si el modo de lenguaje se encuentra en Constrained, estaremos ante el modo de lenguaje restringido. Si el sistema base tiene Powershell versión 2, se puede hacer un bypass del CLM, ya que el modo Constrained aparece en la versión 3 de Powershell.

Figura 5: Constrained no está en v2

En Windows 10, desaparece la posibilidad, por defecto, de utilizar Powershell versión 2, por lo que se evita este bypass y debemos ir a otras opciones. Por ejemplo, se puede utilizar PSBypassCLM, una herramienta que permite hacer ese bypass.

Powershell Transcription

No todo es protección directa. En muchas ocasiones nos interesa saber qué es lo que está ocurriendo en el sistema y tener un buen sistema de logging es fundamental. En el caso de Powershell, éste ha ido evolucionando y mejorando. Hay varias opciones:

• Module Logging.
• Script Block Logging.
• Powershell Transcription.

Las tres opciones son funcionalidades para registrar acciones que ocurren a través de Powershell. Module Logging registra el uso de módulos, mientras que la segunda es capaz de registrar comandos, bloques de script o script-block, etcétera. La tercera es una de las más interesantes, ya que registra el input y output de la sesión con Powershell.

¿Dónde se activa esto?

Tenemos que abrir el binario mmc.exe, la consola de gestión de Windows, y añadir un nuevo complemento. El complemento es el objeto de políticas locales. Debemos ir a la parte de “Computer Configuration -> Windows Components -> Windows Powershell”.

Figura 6: Opciones de PowerShell en mmc.exe

Para habilitar Powershell Transcription se debe entrar en la configuración y habilitarla. Es importante seleccionar el directorio donde se quiere almacenar el fichero con los inputs y outputs generados por cualquier usuario a través de una Powershell.

Como se puede ver en la imagen siguiente, el proceso es sencillo y a partir de este momento se dispone de un sistema que registra cualquier acción sobre la Powershell. Esto permitirá, en la mayoría de los casos, registrar acciones sobre lo que hacen los usuarios y poder estudiar y detectar alguna acción “extraña” o alguna ejecución maliciosa.

Figura 7: Política para logging de inputs & outputs en Powershell

Para este ejemplo, podemos ver como el fichero de texto ha registrado las acciones de entrada y salida dentro de una Powershell. Lo que el usuario ejecutó y el resultado que éste obtuvo. Esto ayuda a un administrador a entender bien el entorno en el que se han estado moviendo los usuarios.

Figura 8: registro de acciones

Es importante conocer las defensas de Powershell para poder llevar a cabo la parte ofensiva, sin duda. Microsoft proporciona diferentes medidas de protección, en busca de un entorno lo más seguro posible. Sin duda, es interesante conocer, tanto la parte defensiva como la ofensiva, si te dedicas al pentesting. Powershell sigue evolucionando de la mano de Microsoft.