La escalada de privilegios es el uso por parte de un atacante de los derechos actuales de una cuenta para obtener un nivel de acceso adicional, generalmente más alto, al sistema. Si bien 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 realizan un ataque dirigido, o malware bien disfrazado, en la mayoría de los casos se debe a una configuración incorrecta de la computadora o la cuenta. Desarrollando aún más el ataque, los atacantes usan una serie de vulnerabilidades individuales, 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 profesional de la 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 esos mismos ataques sean mucho más severos.
Desafortunadamente, para muchas organizaciones este sigue siendo un tema muy controvertido y, a veces, va acompañado de discusiones acaloradas (ver, por ejemplo, ). Sin entrar en los detalles de esta discusión, creemos que el atacante obtuvo derechos de administrador local en el sistema bajo investigación, ya sea a través de un exploit o porque las máquinas no estaban debidamente protegidas.
Paso 1: Resolución DNS inversa con PowerShell
De forma predeterminada, PowerShell está instalado en muchas estaciones de trabajo locales y en la mayoría de los servidores de Windows. Y aunque no es exagerado que se considere una herramienta de automatización y control increíblemente útil, es igualmente capaz de transformarse en un dispositivo casi invisible. (un programa de piratería que no deja rastros del ataque).
En nuestro caso, el atacante comienza a realizar un reconocimiento de la red utilizando un script de PowerShell, iterando secuencialmente sobre el espacio de direcciones IP de la red, tratando de determinar si una IP determinada se resuelve en un host y, de ser así, cuál es el nombre de red de este host.
Hay muchas formas de realizar esta tarea, pero con el cmdlet ADComputer es una opción sólida 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 en redes grandes es un problema, se puede usar una devolución de llamada de 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 supervisan las consultas DNS internas en busca de ráfagas de actividad sospechosas.
Paso 2: elige un objetivo
El resultado final de este paso es obtener una lista de nombres de host de servidores y estaciones de trabajo que se pueden usar para continuar con el ataque.
Por el nombre, el servidor 'HUB-FILER' parece un objetivo digno, ya que Con el tiempo, los servidores de archivos, por regla general, acumulan una gran cantidad de carpetas de red y un acceso excesivo a ellas por parte de demasiadas personas.
Navegar con el Explorador de Windows nos permite detectar la presencia de una carpeta compartida abierta, pero nuestra cuenta actual no puede acceder a ella (probablemente solo tengamos derechos de listado).
Paso 3: aprenda las ACL
Ahora, en nuestro host HUB-FILER y recurso compartido de destino, podemos ejecutar un script de PowerShell para obtener la ACL. Esto lo podemos hacer desde la máquina local, ya que tenemos derechos de administrador local:
(get-acl hub-filershare).access | ft IdentityReference,FileSystemRights,AccessControlType,IsInherited,InheritanceFlags –autoResultado de la ejecución:
Desde allí vemos que el grupo Usuarios del dominio tiene acceso solo a la lista, pero el grupo Helpdesk también tiene los derechos para cambiar.
Paso 4: Identificación de la cuenta
Correr , podemos obtener todos los miembros de este grupo:
Get-ADGroupMember -identity Helpdesk
En este listado vemos una cuenta de equipo que ya hemos identificado y ya hemos accedido:
Paso 5: use PSExec para ejecutar como una cuenta de computadora
de Microsoft Sysinternals le permite ejecutar comandos en el contexto de la cuenta del sistema SYSTEM@HUB-SHAREPOINT, que sabemos que es miembro del grupo objetivo de Helpdesk. Es decir, sólo tenemos que hacer:
PsExec.exe -s -i cmd.exeBueno, entonces tiene acceso completo a la carpeta de destino HUB-FILERshareHR, ya que está trabajando en el contexto de la cuenta de computadora HUB-SHAREPOINT. Y con este acceso, los datos pueden copiarse a un dispositivo de almacenamiento portátil o recuperarse y transmitirse a través de la red.
Paso 6: Detectar este ataque
Esta vulnerabilidad particular de ajuste de privilegios de cuenta (cuentas de computadora que acceden a recursos compartidos de red en lugar de cuentas de usuario o cuentas de servicio) se puede descubrir. Sin embargo, sin las herramientas adecuadas, esto es muy difícil de hacer.
Para detectar y prevenir esta categoría de ataques, podemos utilizar para identificar grupos con cuentas de computadora en ellos y luego denegar el acceso a ellos. va más allá y le permite crear una notificación específica para este tipo de escenario.
La siguiente captura de pantalla muestra una notificación personalizada que se activará cada vez que una cuenta de computadora acceda a datos en un servidor monitoreado.
Próximos pasos con PowerShell
¿Quiere saber más? Utilice el código de desbloqueo del "blog" para acceder de forma gratuita a la totalidad .
Fuente: habr.com