Powershell 101
PowerShell 101
PowerShell es más que una línea de comandos. Es una herramienta escrita con el framewordk .NET esencial para administradores de sistemas, analistas de seguridad y desarrolladores. En este blog vamos a explorar su estructura y su seguridad, desde la gestión de módulos hasta sus políticas de ejecución y mecanismos de defensa.
Importar Módulos y Scripting
Uno de los aspectos más importantes y de mayor uso en PowerShell es la capacidad para extenderse mediante módulos. Los módulos contienen funciones que facilitan la automatización de tareas. Podemos importar módulos en nuestra sesión usando diferentes maneras:
- Usando Dot Sourcing:
Dot Sourcing permite cargar y ejecutar un script de PowerShell en la sesión actual, por lo que todas las funciones y variables dentro del script estarán disponibles para un uso futuro.
. .\ScriptPowerShell.ps1
-
Usando Import-Module:
Import-Module se usa para cargar no solo scripts, sino funciones, clases y cmdlets. Esto permite que los comandos dentro del modulo estén disponibles en la sesión.
Import-Module ScriptPowershell.ps1
Cargar módulos de forma remota
Una funcionalidad importante de PowerShell es la carga de módulos remotos. Esta técnica permite la descarga de scripts directamente en memoria y ejecutarlo sin necesidad de almacenarlo en disco.
- Usando Net.WebClient
Este método usa la clase .NET Net.WebClient para descargar un script de Powershell y ejecutarlo en memoria inmediatamente.
iex (New-Object Net.WebClient).DownloadString('https://192.168.1.12:8080/resource.ps1')
Vamos a explicar el comando:
- IEX: Hace referencia a Invoke-Expression. Esto ejecuta el string como código de PowerShell.
- New-Object WebClient: Crea una instancia de la clase WebClient y llama al método DownloadString para descargar el contenido de la URL.
- En resumen, carga en memoria el contenido de la URL y ejecuta el script descargado.
- Usando IWR
Este método usa el cmdlet IWR para descargar y ejecutar el script.
iex (iwr http://192.168.1.12:8080/resource.ps1)
Es similar al anterior, solo que esta vez se usa IWR, que hace referencia a Invoke Web Request, un cmdlet de powershell usado para enviar solicitudes HTTP/HTTPS.
Seguridad en PowerShell
Desde 2016, Microsoft ha fortalecido PowerShell con características avanzadas de seguridad y registro para mejorar la visibilidad de su uso y detectar actividades sospechosas.
Registro Global de Transcripciones
PowerShell puede registrar toda la actividad de la sesión, incluso si se intenta evadir la ejecución mediante código sin gestionar.
- Objetivo: Registrar cada comando y su salida en archivos de texto, brindando mayor visibilidad y dificultando la evasión por parte de atacantes.
-
Ejemplo de activación:
Start-Transcript -Path "C:\Logs\session.log"
Script Block Logging
Desde PowerShell 5, se introdujo el registro de bloques de script, lo que permite almacenar información detallada sobre el código ejecutado.
- Eventos generados: 4103 y 4104 en el Visor de Eventos.
- Propósito: Capturar el contenido de scripts ejecutados, incluyendo código ofuscado.
-
Habilitar Script Block Logging:
Set-ItemProperty -Path "HKLM:\Software\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" -Name "EnableScriptBlockLogging" -Value 1
AMSI (Antimalware Scan Interface)
AMSI analiza el código de PowerShell antes de su ejecución, enviándolo a soluciones de seguridad como Windows Defender.
- Funcionamiento:
- Examina los scripts y compara su contenido con firmas de malware.
- Si detecta amenazas, bloquea la ejecución antes de que se ejecute el código.
-
Verificando si AMSI está activo:
[Ref].Assembly.GetType('System.Management.Automation.AmsiUtils')
Constrained Language Mode (CLM)
PowerShell soporta diferentes modos de ejecución que restringen las operaciones permitidas:
- No Language: Solo comandos esenciales permitidos (usado en JEA - Just Enough Administration).
- Constrained Language: Limita la ejecución a módulos firmados y confiables.
- Restricted Language: Solo permite comandos básicos administrativos.
- Full Language: Habilita todas las funciones sin restricciones (modo predeterminado).
CLM se puede reforzar mediante AppLocker o WDAC (Windows Defender Application Control) para bloquear scripts no firmados.
Execution Policy: Control de Ejecución de Scripts
PowerShell utiliza políticas de ejecución para restringir la ejecución de scripts maliciosos, aunque no es un mecanismo de seguridad en sí mismo, sino una medida para evitar ejecuciones accidentales.
Políticas más comunes:
- Restricted: No permite ejecución de scripts.
- RemoteSigned: Requiere firma digital para scripts descargados.
- Unrestricted: Permite todos los scripts, pero muestra advertencias sobre scripts de internet.
Cambiar la política de ejecución:
Set-ExecutionPolicy RemoteSigned -Scope CurrentUser
AppLocker: Reforzando la Seguridad de PowerShell
AppLocker permite definir reglas que restringen la ejecución de scripts y aplicaciones en entornos empresariales.
Configuración de reglas para PowerShell
- Abrir gpedit.msc
- Navegar a Configuración del equipo -> Directivas de seguridad -> Políticas de restricción de software -> AppLocker
- Configurar reglas para bloquear o permitir scripts (
.ps1).
Ejemplo de regla en PowerShell para permitir solo scripts firmados:
Set-AppLockerPolicy -XmlPolicy (Get-Content "C:\Policy.xml" -Raw)
Esto refuerza la seguridad en entornos donde la ejecución de scripts debe estar estrictamente controlada.
Bibliografía
https://medium.com/@dineshkumaar478/the-road-to-crtp-cert-part-3-c0a591848b90
https://learn.microsoft.com/es-es/windows/win32/amsi/how-amsi-helps
https://devblogs.microsoft.com/powershell/powershell-constrained-language-mode/
https://viperone.gitbook.io/pentest-everything/everything/powershell/constrained-language-mode