La escalada de privilegios es el uso por parte de un atacante de los derechos de la cuenta corriente para obtener un nivel de acceso adicional, generalmente mayor, al sistema. A pesar del hecho de que la escalada de privilegios puede ser el resultado de la explotación de vulnerabilidades de día cero, o el trabajo de piratas informáticos de primera clase que llevan a cabo un ataque dirigido o un malware disfrazado correctamente, pero con frecuencia esto ocurre debido a una configuración incorrecta de la computadora o cuenta. Al desarrollar aún más el ataque, los atacantes explotan una serie de vulnerabilidades separadas, que juntas pueden conducir a una fuga de datos catastrófica.
¿Por qué los usuarios no deberían tener derechos de administrador local?
Si es un especialista en seguridad, puede parecer obvio que los usuarios no deberían tener derechos de administrador local, ya que esto:
- Hace que sus cuentas sean más vulnerables a varios ataques.
- Hace que estos ataques sean mucho más serios.
Desafortunadamente, para muchas organizaciones este sigue siendo un tema muy controvertido y a veces se acompaña de acaloradas discusiones (ver, por ejemplo,
mi gerente dice que todos los usuarios deben ser administradores locales ). Sin entrar en los detalles de esta discusión, creemos que el atacante obtuvo los derechos de un administrador local en el sistema en estudio: ya sea a través de un exploit o porque las máquinas no estaban protegidas adecuadamente.
Paso 1. Invierta la resolución del nombre DNS a través de PowerShell
De forma predeterminada, PowerShell se instala en muchas estaciones de trabajo locales y en la mayoría de los servidores de Windows. Aunque no sin exagerar, se considera una herramienta de automatización y control increíblemente útil, es igualmente capaz de convertirse en un
malware casi invisible
sin archivos (un programa de piratería que no deja rastros de un ataque).
En nuestro caso, el atacante comienza a realizar el reconocimiento de la red utilizando el script de PowerShell, ordenando secuencialmente el espacio de la dirección IP de la red, tratando de determinar si esta IP está permitida para el host y, de ser así, cuál es el nombre de la red de este host.
Hay muchas formas de realizar esta tarea, pero el uso del cmdlet Get-ADComputer es una opción confiable porque 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 del trabajo en redes grandes causa problemas, se puede usar la devolución de llamada del sistema DNS:
[System.Net.Dns]::GetHostEntry('10.10.10.10').HostName
Este método de enumerar hosts en una red es muy popular ya que la mayoría de las redes no utilizan un modelo de seguridad de confianza cero y no rastrean las solicitudes internas de DNS para picos de actividad sospechosos.
Paso 2: Selección de objetivos
El resultado final de este paso es obtener una lista de los nombres de host del servidor y la estación de trabajo que se pueden usar para continuar el ataque.
A juzgar por el nombre, el servidor 'HUB-FILER' parece ser un objetivo digno, porque Con el tiempo, los servidores de archivos tienden a acumular una gran cantidad de carpetas de red y un acceso excesivo a ellas por parte de demasiadas personas.
La visualización con el Explorador de Windows nos permite determinar si hay una carpeta compartida abierta, pero nuestra cuenta actual no puede acceder a ella (probablemente solo tengamos derechos de listado).
Paso 3: Aprenda la ACL
Ahora en nuestro host HUB-FILER y la carpeta compartida de destino, podemos ejecutar el script de PowerShell para obtener la ACL. Podemos hacer esto desde la máquina local, ya que ya tenemos derechos de administrador local:
(get-acl \\hub-filer\share).access | ft IdentityReference,FileSystemRights,AccessControlType,IsInherited,InheritanceFlags –auto
Resultado de ejecución:
A partir de él, vemos que el grupo de usuarios de dominio solo tiene acceso a la lista, pero el grupo de servicio de asistencia también tiene derecho a cambiar.
Paso 4: identificar cuentas
Al ejecutar
Get-ADGroupMember , podemos obtener todos los miembros de este grupo:
Get-ADGroupMember -identity Helpdesk
En esta lista vemos una cuenta de computadora que ya hemos identificado y a la que ya hemos accedido:
Paso 5: use PSExec para trabajar desde una cuenta de computadora
PsExec de Microsoft Sysinternals le permite ejecutar comandos en el contexto de la cuenta del sistema SYSTEM @ HUB-SHAREPOINT, que, como sabemos, es miembro del grupo de trabajo Helpdesk. Es decir, es suficiente para nosotros realizar:
PsExec.exe -s -i cmd.exe
Bueno, entonces tiene acceso completo a la carpeta de destino \\ HUB-FILER \ share \ HR, ya que trabaja en el contexto de la cuenta de computadora HUB-SHAREPOINT. Y con este acceso, los datos pueden copiarse en un dispositivo de almacenamiento portátil o recuperarse y transferirse a través de la red.
Paso 6: detecta este ataque
Se puede detectar esta vulnerabilidad particular para establecer privilegios de cuenta (cuentas de computadora que acceden a carpetas de red compartidas en lugar de cuentas de usuario o cuentas de servicio). Sin embargo, sin las herramientas adecuadas, esto 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 cerrar el acceso a ellos.
DatAlert va más allá y le permite crear una notificación específicamente para tal escenario.
La captura de pantalla siguiente muestra una notificación de usuario que se activará cada vez que una cuenta de computadora acceda a datos en un servidor monitoreado.
Próximos pasos con PowerShell
¿Quieres saber más? Utilice el código de desbloqueo del "blog" para acceder de forma gratuita al
curso completo de
video de PowerShell y a los Fundamentos de Active Directory .