🥇Uso de PowerShell para elevar privilegios de cuentas locales

El aumento de privilegios es el uso por parte de un atacante de los derechos actuales de una cuenta para obtener acceso adicional, generalmente a un nivel más alto en el sistema. Aunque el aumento de privilegios puede ser el resultado de la explotación de vulnerabilidades de día cero, de un ataque dirigido de hackers altamente cualificados o de un malware astutamente camuflado, por lo general, ocurre debido a una configuración incorrecta de la computadora o cuenta. Al desarrollar el ataque, los atacantes utilizan una serie de vulnerabilidades individuales que, en conjunto, pueden llevar a una filtración de datos catastrófica.

¿Por qué los usuarios no deberían tener derechos de administrador local?

Si usted es un especialista en seguridad, puede parecer obvio que los usuarios no deben tener derechos de administrador local, ya que esto:

Hace que sus cuentas sean más vulnerables a diversos ataques
Hace que estos ataques sean mucho más graves

Desafortunadamente, para muchas organizaciones, este sigue siendo un tema muy controvertido y a menudo se acompaña de acaloradas discusiones (vea, por ejemplo, mi jefe dice que todos los usuarios deben ser administradores locales). Sin profundizar en los detalles de esta discusión, consideramos que un atacante ha adquirido derechos de administrador local en el sistema examinado: ya sea a través de un exploit o porque las máquinas no estaban debidamente protegidas.

Paso 1. Resolución inversa de nombres DNS a través de PowerShell

Por defecto, PowerShell se instala en muchas estaciones de trabajo locales y en la mayoría de los servidores Windows. Aunque es considerado, no sin exageración, una herramienta increíblemente útil para la automatización y gestión, también puede convertirse en casi invisible malware fileless (programa de hacking que no deja rastros de ataque).

En nuestro caso, el atacante comienza a realizar la reconocimiento en red usando un script de PowerShell, iterando secuencialmente a través del espacio de direcciones IP de la red, tratando de determinar si la IP dada se resuelve a un nodo, y si es así, cuál es el nombre de red de ese nodo.
Existen muchas formas de llevar a cabo esta tarea, pero usar el cmdlet Get-ADComputer es una opción confiable, ya que devuelve un conjunto de datos realmente rico sobre cada nodo:

 import-module activedirectory Get-ADComputer -property * -filter { ipv4address -eq ‘10.10.10.10’}

Si la velocidad de operación en redes grandes plantea problemas, se puede utilizar la llamada de sistema inversa DNS:

[System.Net.Dns]::GetHostEntry(‘10.10.10.10’).HostName

Este método de enumerar nodos en la red es muy popular, ya que la mayoría de las redes no utilizan un modelo de seguridad de cero confianza y no rastrean las consultas DNS internas por picos sospechosos de actividad.

Paso 2: Selección del objetivo

El resultado final de este paso es obtener una lista de nombres de host de servidores y estaciones de trabajo que puede ser utilizada para continuar el ataque.

A juzgar por el nombre, el servidor ‘HUB-FILER’ parece ser un objetivo digno, ya que con el tiempo, los servidores de archivos tienden a acumular una gran cantidad de carpetas de red y acceso excesivo de un amplio rango de personas.

Verificándolo con el Explorador de Windows, podemos determinar si hay una carpeta compartida abierta, pero nuestra cuenta actual no puede acceder a ella (probablemente solo tenemos derechos para listar).

Paso 3: Estudiando los ACL

Ahora en nuestro host HUB-FILER y en la carpeta compartida objetivo share, podemos ejecutar un script de PowerShell para obtener una lista de ACL. Podemos hacerlo desde la máquina local, ya que ya tenemos permisos de administrador local:

(get-acl hub-filershare).access | ft IdentityReference,FileSystemRights,AccessControlType,IsInherited,InheritanceFlags –auto

Resultado de la ejecución:

De esto vemos que el grupo Usuarios de Dominio tiene acceso solo para listar, pero el grupo Helpdesk también tiene derechos de modificación.

Paso 4: Identificación de Cuentas

Al ejecutar Get-ADGroupMember, podremos obtener todos los miembros de este grupo:

Get-ADGroupMember -identity Helpdesk

En esta lista vemos la cuenta de computadora que ya hemos identificado y a la que ya hemos obtenido acceso:

Paso 5: Usando PSExec para trabajar desde la cuenta de computadora

PsExec de Microsoft Sysinternals permite ejecutar comandos en el contexto de la cuenta del sistema SYSTEM@HUB-SHAREPOINT, que, como sabemos, es miembro del grupo objetivo Helpdesk. Es decir, solo necesitamos ejecutar:

PsExec.exe -s -i cmd.exe

Además, tendrá acceso completo a la carpeta de destino HUB-FILERshareHR, ya que trabaja en el contexto de la cuenta de computadora HUB-SHAREPOINT. Con este acceso, los datos pueden ser copiados a un dispositivo de almacenamiento portátil o extraídos y transmitidos a través de la red.

Paso 6: Detección de este ataque

Esta vulnerabilidad específica en la configuración de permisos de cuentas (cuentas de computadoras que acceden a carpetas de red compartidas en lugar de cuentas de usuario o cuentas de servicio) puede ser detectada. Sin embargo, hacerlo sin las herramientas adecuadas es muy difícil.

Para detectar y prevenir esta categoría de ataques, podemos usar DatAdvantage para identificar grupos con cuentas de computadora y luego restringir su acceso. DatAlert va más allá y permite crear una alerta específicamente para este tipo de escenario.

En la captura de pantalla a continuación, se muestra una alerta personalizada que se activará cada vez que una cuenta de computadora acceda a los datos en el servidor monitoreado.