Análisis y detección de Hoaxshell "¿una la shell indetectable?"

Hoaxshell proporciona de forma client-side una shell inversa que por el momento Microsoft Defender y posiblemente otros motores de AVs no están detectando ya que se basa únicamente en el tráfico http y https, según nos comenta su desarrollador. Aunque más adelante veremos como esto puede ser detectado a nivel de eventos de Windows y no por eventos producidos en la red.

Hoaxshell: obteniendo una shell remota

Nos descargamos el repositorio e instalamos el requirements.txt de python.

git clone https://github.com/t3l3machus/hoaxshell

cd ./hoaxshell

sudo pip3 install -r requirements.txt

chmod +x hoaxshell.py

Existen principalmente dos modos de ejecutar Hoaxshell o bien de forma normal donde hace uso del puerto 8080/http o bien usando un canal cifrado SSL usando el puerto 443/https, para este segundo es necesario generar un certificado auto firmado.

sudo python3 hoaxshell.py -s <your_ip>

Figura 1: Ejecución de hoaxshell obteniendo una shell inversa.

Buscando indicadores de compromiso para la detección de Hoaxshell

Analizando el tráfico de red

Si analizamos la comunicación de red una vez hemos lanzado el ataque de ejecución de la shell sin cifrar (8080/http) se monta un servidor web apache con una URI generada aleatoriamente donde la máquina víctima descargará el payload automáticamente cuando lo ejecute. Este es posible a través del llamada Invoke-WebRequest incluido en el payload codificado en base64 que veremos descodificado más adelante.

Figura 2: Hoaxshell sin cifrar - Detección de tráfico de red.

En el caso de lanzar el ataque con un certificado auto firmado vía 443/https en la captura de tráfico vemos el establecimiento de conexión Client Hello de TLS y el intercambio de claves en el handshake entre cliente/servidor. Por otro lado esto también nos genera un evento en el provider de Powershell en el cual vemos texto claro la decodificación del payload que se ejecutó en base64.

Figura 3: Hoaxshell cifrando - Detección de tráfico de red.

Analizando los eventos de Windows

En este parte ha colaborado el compañero @noloseconseguridad el cual ha podido identificar y crear los indicadores de compromiso para la detección de Hoaxshell.

En un primer momento revisamos de forma manual en el visor de eventos a ver que logs se están registrando relacionados con el provider de Powershell. 

Ejecutando con Hoaxshell una shell sin una comunicación cifrada encontramos en el registro "Microsft-Windows-Powershell/Operational" un evento con Id. 4103 en el que vemos un CommandInvocation seguido de un Invoke-Expression donde tenemos un parámetro con el nombre name="Command" que tiene un valor: whoami;split-path $pwd'\0x00'. 

Podemos saber gracias a esto, el comando ejecutado y tenemos una string la cual podemos utilizar para crear una expresión regular y generar un IOC.

;split-path $pwd'\0x00'

Figura 4: Event Id. 4103 de Powershell generado por la ejecución de Hoaxshell sin comunicación cifrada.

El payload de Hoaxshell se genera codificado en base64 tanto para obtener una shell sin cifrar como cifrada, en el caso de lanzar una shell cifrada lógicamente el tamaño del payload será más largo. Decodificando este payload podemos ver lo que está haciendo para poder invocar la shell inversa que después se nos proporciona.

Figura 5: Decodificando payload de Hoaxshell en base64.

Lanzando el ataque en su modo de comunicación cifrada vemos que nos genera en el provider de Powershell los eventos Id. 4103 e Id. 4104 mostrando en texto claro las instrucciones del scriptblock de Powershell y que coincide con la decodificación vista anteriormente en la figura 5.

Figura 6: Event Id. 4103 y 4104 de Powershell generado por la ejecución de Hoaxshell con comunicación cifrada.

Creando IOC y reglas de detección en Wazuh

En este escenario vamos a utilizar Wazuh como SIEM para la creación de los indicadores de compromiso y generar una regla de detección cuando se registre un evento relacionado con un posible ataque de Hoaxshell. Lógicamente esto puede ser exportable a otros formatos de reglas compatibles para otros sistemas de monitorización de eventos de seguridad.

En el caso de Wazuh añadimos al fichero agent.conf el provider de registro de Powershell indicando la recolección de este tipo de eventos.

Figura 7: Añadir el provider de registro Powershell/Operational.

En el fichero local_rules.xml creamos las reglas para su detección, la última regla será la que realmente nos registre el posible ataque indicando el eventID 4103 y los posibles IOCs vistos anteriormente. 

 <rule id="100535" level="0">

  <if_sid>60009</if_sid>

  <field name="win.system.providerName">^Microsoft-Windows-PowerShell$</field>

  <group>powershell,</group>

  <description>Powershell Information EventLog</description>

</rule>

<rule id="100536" level="0">

  <if_sid>60010</if_sid>

  <field name="win.system.providerName">^Microsoft-Windows-PowerShell$</field>

  <group>powershell,</group>

  <description>Powershell Warning EventLog</description>

</rule>

<rule id="100537" level="0">

  <field name="win.system.providerName">^Microsoft-Windows-PowerShell$</field>

  <field name="win.system.severityValue">^ERROR$</field>

  <group>powershell,</group>

  <description>Powershell Error EventLog</description>

</rule>

<rule id="100538" level="0">

  <if_sid>60012</if_sid>

  <field name="win.system.providerName">^Microsoft-Windows-PowerShell$</field>

  <group>powershell,</group>

  <description>Powershell Critical EventLog</description>

</rule>

  

<rule id="100540" level="12">

  <if_sid>100535</if_sid>

  <field name="win.system.eventID">4103</field>

  <field name="win.system.message" type="pcre2">(?i)powershell.exe.*-e</field>

  <field name="win.system.message" type="pcre2">(?i)Command.*;split-path.\$pwd.\\0x00</field>

  <field name="win.system.message" type="pcre2">(?i)Invoke-Expression</field>

  <description>Powershell hoaxshell detected</description>

</rule>

Por lo que se pudo comprobar y dado los indicadores de compromiso encontrados la detección es exitosa tanto si se ejecuta Hoaxshell en un modo de payload sin cifrar como con una comunicación cifrada.

Figura 8: Creación de reglas de detección e IOCs de Hoaxshell.

Con la regla guarda, ejecutamos de nuevo Hoaxshell y... bingo! vemos como nos está detectando la ejecución y generación de sesión de este tipo de shell en Powershell.

Figura 9: Alerta en la ejecución de un "Powershell hoaxshell detected"

Conclusiones

Podemos decir entonces que "esa shell indetectable" quizás no lo es tanto. Si bien es cierto que actualmente no está siendo detectada automáticamente por Microsoft Defender como protección por defecto en un sistema Windows y es posible que otros motores de antivirus tampoco lo estén haciendo hay que saber que estableciendo unas políticas de auditoría habilitadas en las máquinas, prácticamente todo deja un rastro que se acaba traduciendo en un evento o registro de log del sistema.

Sobre el tipo de payload cifrado o sin cifrar que podemos generar con Hoaxshell vemos que a nivel de evento de sistema es detectable, sin embargo a nivel de comunicación de red es realmente donde está su ventaja ya que en una comunicación sin cifrar podemos identificar la URI que genera pero en una comunicación cifrada la comunicación es TLS y no podría ser leída en un primer intento de detección.

Personalmente me resulta curioso que MS Defender no esté detectando una simple ofuscación codificada en base64 a través de Powershell y que su vez no haga un monitoreo continuo de los eventos registrados donde se encuentran decodificados. Aunque estoy seguro de que Microsoft no tardará mucho en poner solución a esto y más con el revuelo que está habiendo actualmente con Hoaxshell y su facilidad de uso.

Saludos!

Con la colaboración del señor @noloseconseguridad.

Port Knocking: Ocultar y mejorar la seguridad en conexiones SSH

Port knocking o golpeteo de puertos es un método que proporciona seguridad frente ataques de servicios de red, consiste en realizar una serie de peticiones de conexión con una secuencia ordenada de puertos para poder habilitar una regla previamente configurada en el máquina remota que nos permita abrir una comunicación única entre cliente/servidor y establecer finalmente una conexión abierta SSH hacia el servidor remoto. El uso de esta implementación puede ser catalogado como seguridad por oscuridad. 

¿Cómo funciona una conexión SSH usando Port knocking? 

1. Tenemos un servidor SSH que expone el puerto por defecto 22 o bien otro un puerto específico como por ejemplo 4422 (será el puerto que se trate en este escenario).
2. Se añade una regla a nivel de firewall del propio servidor para rechazar todas conexiones entrantes sobre el puerto SSH previamente configurado 4422.
3. Para poder conectarnos a este servidor usando una técnica de port kockning de hasta tres "golpeteos" de puertos para establecer una conexión SSH, necesitamos realizar una petición a estos puertos, en este escenario mostraré tres formas de hacerlo (knockd, telnet y nmap).
4. Una vez realizado el knocking de puertos en el orden establecido (que veremos posteriormente en el fichero de configuración) este disparará la acción de ejecutar un comando, este comando no será más que establecer una nueva regla en este caso vía iptables para permitir la conexión SSH únicamente desde la IP origen que realizó la secuencia de golpeteo de puertos y no desde ninguna otra IP alcanzable de la misma red.
5. Finalmente para volver aplicar la regla de bloqueo y restablecer esta configuración al terminar nuestra sesión, se lanzará el golpeteo de puertos de salida de SSH. De modo que la configuración vuelva a restablecerse y vuelva a cerrarse el puerto hacia el exterior.

Configurando Iptables

Bloquear puerto SSH configurado vía Iptables

En este escenario el servidor SSH se ejecuta en un entorno Debian y expone el puerto 4422 (en vez del puerto 22 por defecto).

Añadimos un regla iptables para rechazar todas las conexiones entrantes hacia el puerto 4422 del servidor SSH configurado. 

sudo iptables -A INPUT -p tcp --dport 4422 -j REJECT --reject-with tcp-reset

Iptables: diferencias entre DROP y REJECT (estado de puertos "filtered" o "closed")

La teoría nos dice que uso de DROP no hará nada con el paquete recibido, simplemente lo descartará sin enviar ningún tipo de respuesta. Al contrario de REJECT donde se genera un paquete de respuesta rechazando la conexión, si no se especifica el tipo de respuesta por defecto este paquete sería un "ICMP Destination port unreachable".

En la práctica esto no es del todo cierto. Cuando la regla es DROP es cierto que el paquete se descarta y no se envía ningún paquete de respuesta, sin embargo una regla DROP anunciará que existe un control de puertos y los escáneres sabrán que se está haciendo uso de un firewall devolviendo un estado de puerto "filtered". Ocurre lo mismo si solo usamos REJECT sin especificar un tipo concreto de respuesta, este responderá con un paquete "ICMP Destination port unreachable" anunciando así el filtrado de dicho puerto.

Si lo que queremos es ocultar el puerto y devolver un estado "closed" como resultado en un escaneo de puertos, haciendo creer que el puerto o servicio que se ejecuta en el lado servidor no se está usando o simplemente no existe, debemos especificar un tipo de respuesta en una regla REJECT. 

Cuando usamos TCP o UDP sobre un puerto la respuesta debe responder con los flags RST/ACK, de este modo estaremos indicando a los escáneres un estado de puerto "closed".

• TCP: iptables -A INPUT -p tcp --dport 4422 -j REJECT --reject-with tcp-reset
• UDP: iptables -A INPUT -p udp --dport 4422 -j REJECT --reject-with icmp-port-unreachable

Capturando este tipo de tráfico de red con un sniffer como Wireshark, en la siguiente captura de pantalla se muestran todas las combinaciones posibles para este caso donde se puede ver el tipo de paquete de respuesta que genera según el tipo de regla aplicada en el lado servidor.

Reglas DROP y REJECT con estado "FILTERED" (TCP/UDP)

iptables -A INPUT -p tcp --dport 4422 -j DROP

Figura 1: Estado de puerto "filtered" usando DROP en TCP.

iptables -A INPUT -p udp --dport 4422 -j DROP

Figura 2: Estado de puerto "open|filtered" usando DROP en UDP.

iptables -A INPUT -p tcp --dport 4422 -j REJECT

Figura 3: Estado de puerto "filtered" usando REJECT en TCP.

Reglas DROP y REJECT con estado "CLOSED" (TCP/UDP)

iptables -A INPUT -p tcp --dport 4422 -j REJECT --reject-with tcp-reset

Figura 4: Estado de puerto "closed" usando REJECT en TCP.

iptables -A INPUT -p udp --dport 4422 -j REJECT --reject-with icmp-port-unreachable

o

iptables -A INPUT -p udp --dport 4422 -j REJECT

Figura 5: Estado de puerto "closed" usando REJECT en UDP.

Guardado y persistencia de reglas Iptables después de reiniciar la máquina

Instalamos el paquete iptables-persistent.

sudo apt-get install iptables-persistent

Guardamos y cargamos reglas configuradas de Iptables.

sudo netfilter-persistent save
sudo netfilter-persistent reload

Para proporcionar la persistencia de las reglas configuradas de Iptables después un reinicio de la máquina. En el fichero /etc/crontab añadimos la ejecución para cargar las reglas guardas después cada arranque del sistema.

sudo echo "@reboot sudo netfilter-persistent reload &" >> /etc/crontab

Implementación de Port Knocking - knockd

Instalamos el servicio de knockd

sudo apt install -y knockd

Configuración de knockd

Editamos el fichero de configuración de /etc/knockd.conf.

[options]
        #UseSyslog
        logfile     = /var/log/knockd.log

[openSSH]
        sequence    = 7500,8200,9800
        seq_timeout = 5
        command     = /sbin/iptables -I INPUT -s %IP% -p tcp --dport 4422 -j ACCEPT
        tcpflags    = syn

[closeSSH]
        sequence    = 9300,4500,6200
        seq_timeout = 5
        command     = /sbin/iptables -D INPUT -s %IP% -p tcp --dport 4422 -j ACCEPT
        tcpflags    = syn

Por cuestiones de monitorización y depuración de posibles errores establecemos un logfile específico para este servicio con el path donde se almacenarán los logs de knockd. Comentamos UseSyslog ya que si mantenemos esto por defecto los logs se almacenarán en el fichero de sistema /var/log/syslog.

Disponemos de dos principales directivas. Una para abrir la conexión SSH (openSSH) y otra para cerrar y restablecer la configuración de la conexión SSH (closeSSH).

Sección openSSH:

• sequence: Se define la configuración secreta de puertos a golpear. Se puede especificar tres o más puertos y su vez indicar el tipo de protocolo, bien sea por tcp o udp. Por defecto se estable a tres puertos en protocolo tcp. En este caso modifiqué los puertos y secuencia en el siguiente orden: 7500,8200,9800.
• seq_timeout: Tiempo de esperará entre la ejecución de un golpeteo a otro de puertos. Por defecto se establece a 5 segundos, aunque podemos aumentarlo si no fuese suficiente. No se recomienda establecer grandes intervalos de tiempo para evitar ataques de fuerza bruta que realizan esta acción de forma automatizada intentando encontrar la combinación correcta de puertos. Una herramienta utilizada podría ser KnockIt - https://github.com/eliemoutran/KnockIt.
• command: Comando que el servidor ejecutará cuando detecte la combinación correcta de puertos previamente golpeados. En este caso se agregará en una nueva regla (iptables -I) en el primer orden de la jerarquía de prioridad de la tabla INPUT de iptables para permitir únicamente desde la dirección IP origen la la conexión hacia el puerto 4422 configurado para este servidor SSH.
• tcpflags: Tipo de paquetes que reconocerá el servidor como válidos para el port knocking (en este caso con un flag syn).

Sección closeSSH:

Los parámetros son los mismos que las anteriores con la diferencia de indicar otro número de secuencia distinta (en este caso: 9300,4500,6200) para ejecutar otra regla en el parámetro de command.

• command: Se eliminará (iptables -D) la regla añadida anteriormente. De modo que el servidor vuelva a "restablecer" con la configuración inicial rechazando todas las solicitudes origen hacia el puerto 4422 de SSH.

Habilitar el daemon knockd

Editamos el fichero /etc/default/knockd. Establecemos START_KNOCKD a valor "1" para habilitar el servicio y en KNOCKD_OPTS indicamos la interfaz de red que que usará el servicio, en este caso enp0s3.

START_KNOCKD=1
KNOCKD_OPTS="-i enp0s3"

Iniciamos el servicio knockd y habilitamos un tipo de inicio automático del servicio en el arranque del sistema.

sudo systemctl start knockd
sudo systemctl enable knockd

¿Cómo conectarse a un servidor SSH usando Port Knocking?

Analizando el escenario actual

• Máquina Debian - Cliente: 10.0.0.23
• Máquina Debian - Servidor: 10.0.0.22

En la siguiente captura se muestra un intento de conexión SSH desde la máquina cliente (10.0.0.23) sin el uso de Port knocking y vemos como la conexión ha sido rechazada.

Si comprobamos el estado de puerto con Nmap vemos que el puerto se muestra en un estado cerrado "closed". Esto es así porque previamente habíamos especificado el tipo de respuesta en REJECT con un tcp-reset el cual nos devuelve un paquete RST/ACK (ver figura 1 para más detalles).  

Si revisamos la configuración de reglas de iptables en la máquina servidor (10.0.0.22) vemos como hay una regla que rechaza cualquier tipo de conexión por el puerto 4422 desde cualquier IP origen.

Figura 6: Intento de conexión SSH usando knockd sin el uso de secuencia Port Knocking.

Opción 1: usando knock con Port Knocking

Desde la máquina cliente instalamos knockd. Para conectarnos al servidor remoto ejecutamos lo siguiente.

$ knock -v 10.0.0.22 7500 8200 9800
hitting tcp 10.0.0.22:7500
hitting tcp 10.0.0.22:8200
hitting tcp 10.0.0.22:9800

Una vez golpeado los puertos el orden de secuencia de correcto, ejecutamos ssh para conectarnos al servidor por el puerto configurado 4422.

ssh -p 4422 user@10.0.0.22

En la siguiente captura de pantalla podemos ver como después realizar el intento de conexión SSH al servidor remoto usando la combinación correcta de golpeteo de puertos este ejecuta el comando establecido en la directiva "openSSH" configurado en el fichero /etc/knockd.conf donde se indica que se añada en primer orden una nueva regla iptables para permitir la comunicación únicamente a la IP origen de la máquina cliente permitiendo así la conexión SSH hacia la máquina servidor remota.

Como prueba podemos comprobar el estado de conexión de puertos con Nmap, desde la máquina cliente permitida vemos como el puerto 4422 está en estado abierto "open", sin embargo si comprobamos lo mismo desde otra máquina de la red con otra IP origen distinta vemos como para esa otra máquina el estado del puerto 4422 es "closed". Por lo tanto podemos decir que las reglas están funcionando correctamente y estamos "ocultando" o más bien filtrando el uso de las comunicaciones en un puerto concreto entre otras máquinas, la máquina cliente origen y la máquina servidor.

Si revisamos la máquina servidor vemos como ahora existe una nueva regla de iptables en el orden de prioridad 1 (será la primera regla que interprete el firewall) permitiendo la conexión al puerto 4422 desde la IP origen 10.0.0.23 (máquina cliente). Si analizamos los logs /var/log/knockd.log también verificamos que se ejecutó correctamente el orden de secuencia de golpeteo de puertos y el comando que agrega esta regla al firewall local de iptables.

Finalmente salimos de la sesión SSH remota, para volver restablecer las reglas iptables de la máquina servidor y así volver rechazar las conexiones por el puerto 4422 a todas las máquinas e incluida la máquina cliente. Ejecutamos la secuencia de golpeteo de puertos establecida en la directiva de "closeSSH". De esta forma si volvemos a revisar las reglas en la máquina servidor vemos como esta se elimina y se vuelve establecer con prioridad 1 la regla de bloqueo que rechaza todas las conexiones desde cualquier IP origen.

Figura 7: Intento de conexión SSH usando knockd con la secuencia correcta de Port Knocking.

Opción 2: usando telnet con Port Knocking

Otra forma de realizar port knocking es hacer uso del comando telnet. Recibirá un mensaje de "Connection refused", pero está bien, ya que telnet está deshabilitado en ese puerto y solo queremos enviar un paquete con flag "TCP SYN". 

$ telnet 10.0.0.22 7500

Trying 10.0.0.22...

telnet: Unable to connect to remote host: Connection refused

$ telnet 10.0.0.22 8200

Trying 10.0.0.22...

telnet: Unable to connect to remote host: Connection refused

$ telnet 10.0.0.22 9800

Trying 10.0.0.22...

telnet: Unable to connect to remote host: Connection refused

Una vez se concluya el comando telnet durante las tres secuencias de puertos, la conexión SSH por el puerto 4422 se abrirá para la máquina cliente.

Figura 8:  Intento de conexión SSH usando telnet con la secuencia correcta de Port Knocking.

Opción 3: usando Nmap con Port Knocking

Otra forma de realizar port knocking es hacer uso de la herramienta de escaneo de puertos Nmap. Con el parámetro -sS podemos enviar hacia el servidor paquetes con flag "TCP SYN". Concatenando la secuencia de comandos correcta podemos lanzar este tipo de paquetes ejecutando así la regla que nos permite establecer conexión con el servidor SSH remoto.

sudo nmap -sS -p7500 10.0.0.22 ; nmap -sS -p8200 10.0.0.22 ; nmap -sS -p9800 10.0.0.22

Figura 9: Intento de conexión SSH usando Nmap con la secuencia correcta de Port Knocking.

Conclusiones

Añadir este mecanismo como método de autenticación SSH en servidores es una buena medida de seguridad por oscuridad. Si bien este proceso es divertido de implementar y verlo en acción, es posible que no sea factible implementarlo en entornos de producción donde hay una gran cantidad de servidores SSH o si se necesita automatizar accesos SSH.

Considero que es una buena medida de seguridad a implementar solamente para aquellos servidores realmente críticos y que tengan una cierta exposición externa en los que dado su diseño de arquitectura subyacente de red no permita ser protegido en capas anteriores con un firewall o DMZ. Incluso podríamos añadir una segunda capa de protección como sería la implementación de un segundo factor de autenticación 2FA en conexiones SSH.

Saludos!

Segundo factor de autenticación 2FA en conexiones SSH

Implementar un segundo factor de autenticación 2FA en servicios SSH sin duda es una muy buena opción de seguridad no solo para servidores expuestos a internet sino para aquellos usuarios que pueden elevarse a un contexto privilegiado de sudo y servidores críticos en una red interna corporativa. 

Con este mecanismo de autenticación en dos pasos se estaría reduciendo en gran medida la superficie de ataque de los vectores de entrada a estos sistemas por parte de un posible atacante.

Implementación 2FA en SSH (Google Authenticator)

Instalar el paquete del módulo PAM para 2FA libpam-google-authenticator de Google Authenticator, también se instalará el paquete libqrencode4 que permite generar códigos QR en la propia terminal. 

sudo apt install libpam-google-authenticator -y

Configurar SSH para que haga uso de este módulo PAM. Añadir la siguiente línea en el fichero /etc/pam.d/sshd.

auth required pam_google_authenticator.so

Habilitar esta configuración el fichero de configuración del servicio de SSH /etc/ssh/sshd_config. Añadimos o modificamos si ya existe la siguiente política a un valor "yes".

ChallengeResponseAuthentication yes

Reiniciamos el servicio sshd para aplicar los cambios realizados en el servicio de SSH.

sudo systemctl restart sshd

Finalmente vinculamos la cuenta de usuario en la que queremos habilitar 2FA. Se nos mostrará un código QR el cual debemos vincular con nuestra App de doble factor, ya sea Google Authenticator u otra que utilicemos para generar códigos de un solo uso basado en tiempo TOTP.

google-authenticator

Se lanzará el asistente de configuración donde asociaremos la clave secreta con nuestra App de segundo factor. También se generarán "5 códigos de emergencia de un solo uso" los cuales los almacenaremos de forma segura en caso de perder el acceso a nuestra App de TOTP instalada en un dispositivo físico.

Figura 1: Creación de código QR - Asistente de vinculación para habilitar 2FA. 

Una vez finalizado el asistente de vinculación. Si nos intentamos autenticar en el servidor nos solicitará la contraseña de usuario y un código de verificación TOTP.

Figura 2: Verificación del uso de 2FA en la autenticación SSH al servidor. 

En este caso se ha vinculado con la App de Google Authenticator donde cada 30 segundos se generará un nuevo código TOTP. 

Figura 3: Código TOTP en la App de Google Authenticator.

Aclarar que aunque tengamos la política de "PasswordAuthentication no" establecida en nuestro fichero de servicio SSH al implementar 2FA será ignorada y será exigido introducir la contraseña de usuario para autenticarse en el servidor.

Paranoid Mode 3FA: Combinar autenticación SSH Public Key + Password + TOTP 

¿Qué pasa si previamente tenemos configurado una autenticación de clave pública en nuestro servicio de conexión SSH hacia el servidor y añadimos 2FA TOTP?

Si ya tenemos configurado un tipo de autenticación asimétrico de clave pública y añadimos un segundo factor bastado en TOTP a priori con esta configuración actual, no nos funcionará.

Si queremos combinar un tipo de factor TOTP junto con nuestra autenticación de clave pública en SSH debemos añadir la siguiente política en el fichero de configuración del servicio de SSH /etc/ssh/sshd_config. 

AuthenticationMethods publickey,keyboard-interactive

Reiniciamos el servicio SSH para aplicar los cambios.

sudo systemctl restart sshd

De este modo cuando nos conectamos al servidor SSH no solo estaremos combinando SSH Public Key y TOTP sino que también debemos introducir la contraseña de usuario. Por lo que estaremos usando tres factores de autenticación (3FA) para acceder al servidor vía SSH.

• Autenticación con clave pública/privada.
• Autenticación password de la cuenta de usuario.
• Autenticación con código de verificación TOTP.

Aunque en el fichero de configuración del servicio SSH tengamos establecida la política "PasswordAuthentication no" al combinarla con "keyboard-interactive" nos obligará a introducir la password de la cuenta de usuario con el que nos autenticamos.

Figura 4: Verificación del uso de 3FA en la autenticación SSH al servidor.

Si en la máquina servidor disponemos de más usuarios que necesiten autenticarse vía SSH y por el momento estos usuarios aún no han configurado 2FA para sus cuentas o simplemente sean usuarios sin privilegios en los que no se considere la implementación de 2FA pero que igualmente pueda autenticarse e iniciar sesión en el servidor sin necesidad de utilizar TOTP como segundo factor.

Podemos añadir el valor nullock a la siguiente directiva del módulo de PAM editando el fichero /etc/pam.d/sshd.

auth required pam_google_authenticator.so nullok

Saludos!

KrbRelayUp PrivEsc: Escalada de privilegios local en entornos Active Directory y mitigación

KrbRelayUp es una herramienta que nos permite en una post-explotación la escala de privilegios locales en máquinas unidas a un dominio Active Directory y persistencia para realizar este privesc en cualquier máquina del dominio a través de movimientos laterales hasta llegar a la máquina objetivo, de ahí su criticidad y riesgo alto.

No se trata de una vulnerabilidad en sí con un CVE asignado, sino del aprovechamiento de un fallo de configuración por defecto de Windows por parte de los controladores de dominio.

Esta explotación es exitosa en cualquier máquina cliente Windows 10 bajo controladores de dominio Window Server 2012, 2016 y 2019. Actualmente Microsoft no ha dando solución con ningún parche de actualización. 

Más información en el repositorio del autor Mor Davidovich @dec0ne:

• https://github.com/Dec0ne/KrbRelayUp

Explotación (PoC)

Previamente debemos compilar el proyecto, dejo referencia del binario ya compilado KrbRelayUp.exe (fuente de la descarga: https://kb.offsec.nl/). La explotación es sumamente sencilla, una vez comprometida la máquina y descargado el ejecutable lanzamos el exploit. Hasta el momento el servicio de protección para ejecución malware de Windows no lo detecta.

Primera fase del ataque, el usuario de dominio autenticado y sin privilegios retransmitirá una petición Kerberos a LDAP y creará una máquina de control sobre la máquina local usando RBCD.

.\KrbRelayUp.exe relay -Domain <Domain> -CreateNewComputerAccount -ComputerName <hostName>$ -ComputerPassword <Password>

Segunda fase del ataque, utilizará la máquina creada de control para obtener un ticket de servicio de Kerberos y lo utilizará para crear un nuevo servicio que se ejecute como SYSTEM (en este caso está desarrollado para lanzar un cmd.exe).

.\KrbRelayUp.exe spawn -d <Domain> -cn <HostName>$ -cp <Password>

Figura 1: Escalada de privilegios local a SYSTEM usando KrbRelayUp.exe.

Si verificamos en la consola de Active Directory (dsa.msc) vemos como se ha creado una nueva máquina "host01". 

Aclarar que esta máquina será usada como persistencia en el dominio un posible atacante podría moverse lateralmente entre máquinas aprovechando el principio de localidad hasta llegar a una máquina servidor objetivo donde estuviese autenticado un usuario del grupo administradores de dominio o el propio administrador de dominio. Al poder escalar privilegios a SYSTEM sería más que posible realizar un volcado de hashes en memoria de dicha cuenta.

Por esta razón considero que se trata de algo crítico, con un alto riesgo de seguridad y que se debería subsanar lo antes posible. Más adelante veremos como mitigar esto.

Figura 2: Creación de la máquina maliciosa por parte de un usuario del dominio en Active Directory.

Detección (Event ID 4768)

Este artículo no está enfocado al detalle de detección, sino más bien a la explotación y mitigación de esta vulnerabilidad. Considero que en este caso es más eficiente realizar una mitigación para este fallo de configuración que generar las alertas de detección en nuestro SIEM.

La mitigación para esta vulnerabilidad tiene una sencilla implementación a nivel global de todo el dominio, sin embargo en las reglas de detección se nos puede escapar algo nuevo y que no se estaría alertando.

Uno de los logs que podemos registrar (en una configuración de Auditoría por defecto de AD) sería el evento 4768 "Solicitud de ticket de autenticación de Kerberos (TGT)". Donde el Account Name sería la creación de máquina en AD.

Figura 3: EventID 4768 - Autenticación Kerberos solicitud de ticket TGT del host malicioso

También he intentado buscar un evento estado buscando un evento 4741 "Creación de una cuenta de máquina", sin éxito. Es posible que la incorporación de Sysmon nos pueda dar más detalles para su detección y poder crear un indicador de compromiso válido.

Para el uso de reglas Sigma y otros eventos de Windows aconsejo consultar el repositorio donde se mantiene actualizada esta información.

• https://github.com/Dec0ne/KrbRelayUp#mitigation--detection

Mitigación y verificación

Para evitar el aprovechamiento de esta mala configuración por defecto en entornos de dominio, podemos elegir diversas opciones de mitigación:

• Opción 1. Requerir firma LDAP del servidor.
  
• Opción 2: Eliminar los permisos de los "usuarios autenticados" para que no puedan unir máquinas al dominio.
• Opción 3. Limitar el valor del atributo MS-DS-Machine-Account-Quota.

Opción 1. Requerir firma LDAP del servidor

Debemos aplicar únicamente la siguiente política en la GPO "Default Domain Controllers Policy":

Polices > Windows Settings > Security Settings > Local Polices > Security Options > "Domain controller: LDAP server signing requirements" y establecerla como "Require signing"

De esta forma se rechazan las solicitudes de LDAP simples y solicitudes LDAP a través de SSL. Esto puede tener impacto en sistemas Windows XP o Server 2003.

No es necesario aplicar ambas políticas: "Network Security: LDAP client signing requirements" y "Domain controller: LDAP server signing requirements" en la GPO Default Domain Policy.

Figura 4: Mitigación KrbRelayUp - Aplicar política "Domain controller: LDAP server signing requirements".

Verificamos la mitigación y vemos que al aplicar esta política la conexión LDAP falla. En la segunda fase del exploit tampoco es posible realizar la conexión solicitando el ticket Kerberos TGT para autenticarnos en la máquina creada y poder levantar la terminal privilegiada SYSTEM.

Aunque el ataque no fue exitoso, si ha sido posible crear una nueva máquina en el dominio, no nos daría persistencia ya que la autenticación no se va poder realizar en ningún caso, pero en caso de ejecutar el ataque se estarían creando de forma residual estas máquinas en la OU por defecto de "Computers".

Figura 5: Verificación mitigación - LDAP server signing requirements.

Opción 2. Eliminar los permisos de los "usuarios autenticados" para que no puedan unir máquinas al dominio

De todas las opciones de mitigación que se comentan en este artículo, es la que aplicaría por escalabilidad y gestión centralizada de permisos a través de grupos de seguridad de Active Directory.

Debemos aplicar únicamente la siguiente política en la GPO "Default Domain Controllers Policy":

Polices > Windows Settings > Security Settings > Local Polices > User Rights Assignment > "Add workstations to domain"

Por defecto esta política establece que todos los "usuarios autenticados" tienen la capacidad de unir máquinas al dominio. Un solución sería eliminar este grupo y agregar los grupos que autorizados para realizar esta tarea. En este caso agregué "Domain Admins" y un grupo específico creado en AD de este modo podremos agregar otros grupos o usuarios específicos y autorizados pudiendo así granular los permisos para realizar esta tarea.

Figura 6: Mitigación KrbRelayUp - Limitar permisos para la política "Add worksations to domain".

Con esta política propagada y aplicada en los DCs, si probamos a ejecutar nuevamente el exploit vemos que falla mostrando un mensaje de que el usuario no tiene permisos suficientes (esto se refiere a que no es posible que este usuario pueda crear máquinas unidas al dominio).

Lógicamente esta opción no llegará ni si quiera a crear la máquina en AD. Por lo que ya estaríamos eliminando una posible persistencia en el dominio por parte del atacante.

Figura 7: Verificación mitigación - Permisos insuficientes para poder unir máquinas al dominio.

Opción 3. Limitar el valor del atributo MS-DS-Machine-Account-Quota

Otra mitigación que dificultaría los requisitos del ataque sería limitar limitar el número de máquinas que un usuario pueda unir al dominio. Si optamos por esta opción debemos establecer un valor 0 al atributo del dominio ms-DS-MachineAccountQuota.

Este atributo lo podemos encontrar y editar directamente desde las propiedades del dominio en una consola de Active Directory (dsa.msc) o también acceder a él a través desde la consola de editor ADSI (adsiedit.msc).

Figura 8: Mitigación KrbRelayUp - Limitar el valor del atributo ms-DS-MachineAccountQuota.

Si verificamos la aplicación de este cambio vemos como al intentar ejecutar el exploit el servidor no puede gestionar esta solicitud, esto estaría bloqueando el ataque y tampoco crearía la máquina en AD evitando así, al igual que la opción anterior, una posible persistencia en el dominio.

Figura 9: Verificación mitigación - ms-DS-MachineAccountQuota = 0.

Si con el mismo usuario, desde otra máquina nueva, intentamos unirla al dominio de modo gráfico nos muestra el siguiente error indicando que "hemos superado el número máximo de cuentas de máquina que puedes crear o unir en este dominio".

Figura 10: Verificación mitigación - Mensaje de error al intentar unir una máquina al dominio.

¿Cómo identificar quién agregó un nueva maquina al dominio?

El usuario "user.sinpriv" es un usuario de dominio sin ningún otro privilegio otorgado, sin embargo el exploit hace uso del cmdlet New-AddComputer sumado a esta configuración por defecto en entornos de dominio este usuario puede crear máquinas en Active Directory. 

Podemos identificar y verificar quien a creado una máquina en AD examinando el atributo ms-DS-CreatorSID.

Get-ADComputer <Host> -Properties mS-DS-CreatorSID | Select-Object -Expandproperty mS-DS-CreatorSID | Select-Object -ExpandProperty Value | Foreach-Object {Get-ADUser -Filter {SID -eq $_}}

Figura 10: Identificar al usuario en la creación de nuevas máquinas unidas al dominio.

Saludos!

Instalar y configurar Microsoft LAPS para evitar movimientos laterales (Local Administrator Password Solution)

Microsoft LAPS (Local Administrator Password Solution) se trata de una herramienta de Microsoft que pone solución a la gestión de contraseñas administrador local de los equipos unidos a un dominio. 

Entendiendo el riesgo de seguridad y escenarios comunes en las organizaciones

En la mayoría de compañías es una práctica común establecer la misma contraseña para la cuenta del administrador local en todos los equipos que forman parte de un dominio, principio de localidad entre máquinas, ya puedan ser clientes o servidores (exceptuando los Domain Controller que por defecto carecen de una cuenta de administrador local).

Se considera una reducción del riesgo alto la implementación de este tipo de soluciones que evita configurar una misma contraseña para la cuenta de administrador local en todas las máquinas, al hacer que cada máquina use una contraseña diferente y compleja para la cuenta de administrador local se establece una importante medida defensiva que evita principalmente el movimiento lateral entre equipos (pivoting), una vez se obtuviese una contraseña o un hash NTLM válido en el que poder realizar técnicas de Pass the Hash (PtH).

Este tipo de soluciones es conocida por muchas empresas pero implementada por muy pocas en la realidad, no tanto por su complejidad sino por el impacto significativo que supone en la operativa diaria de gestión del cambio en la administración remota de los equipos, despliegues automáticos mal configurados en las que se haga uso de la contraseña de administrador local parametrizada, mantenimiento en los posibles endpoints que se encuentren fuera de la oficina en la que la conexión con la VPN a la red central se realice en pocas ocasiones y sea necesario gestionarlo a través de una cuenta local privilegiada, etc. 

En cualquier caso para entornos on-premise existen alternativas de gestión remota para estos equipos como puede ser la creación de un grupo en AD en el cual se añada a través de GPO al grupo administradores locales de las máquinas de modo que cada usuario que pertenezca a ese grupo principal pueda autenticarse en el equipo con su contraseña de dominio de forma nominal. En el caso de disponer de un entorno híbrido integrado con algún proveedor cloud MDM no solo se simplifica la gestión de los equipos sino que se gana en monitorización y administración de seguridad de los mismos.

Características de LAPS

LAPS determina si la contraseña de la cuenta del administrador local ha caducado. Si la contraseña ha caducado, cambia la contraseña del administrador local a un nuevo valor aleatorio y transmite la nueva contraseña y la fecha de caducidad a Active Directory donde se almacena en unos atributos especiales asociados con el objeto de equipo de AD. Las contraseñas se almacenan en Active Directory y están protegidas por listas de control de acceso (ACLs) por lo que solo los usuarios elegibles pueden leerlas o solicitar su restablecimiento.

• Gestión centralizada y almacenamiento de las contraseñas de los administradores locales de forma segura dentro de AD DS.
• Las contraseñas se almacenan en valores de atributos que sólo estarán visibles para los usuarios o grupos de seguridad que se definan a través de Active Directory.
• Las contraseñas de los administradores locales son únicas en cada máquina.
• Las contraseñas se cambian de forma automática, estableciendo contraseñas aleatorias y complejas en base a patrones que previamente estén definidos en su propia plantilla GPO (AdmPwd.admx).
• Transmite las contraseñas al cliente de manera segura y cifrada.
• Permite controlar los permisos en usuarios o grupos para el acceso a la visualización y restablecimiento de las contraseñas.
• Dispone de sus propios ID de eventos para su análisis en auditorías.

Instalación de LAPS

Instalador de LAPS (Local Administrator Password Solution).

• https://www.microsoft.com/en-us/download/details.aspx?id=46899

Documentación oficial LAPS: https://download.microsoft.com/download/C/7/A/C7AAD914-A8A6-4904-88A1-29E657445D03/LAPS_OperationsGuide.docx

En uno de los controladores de dominio, preferiblemente un PDC (Primary Domain Controller), instalamos y agregamos las características del cliente pesado, módulo de PowerShell y las plantillas del editor de políticas de grupo.

GPO CSE (Client-Side Extension) solo deberá estar presente en cada endpoint gestionado.

Figura 1: Instalar características para la gestión LAPS.

Figura 2: LAPS instalado.

Importamos el módulo AdmPwd.ps, se actualiza el esquema de Active Directory, y se definen las unidades organizativas donde se quieran aplicar los permisos para la gestión de LAPS.

Import-Modulo AdmPwd.ps
Update-AdmPwdADSchema
Set-AdmPwdComputerSelfPermission -Identity "<OU_AD>"

Figura 3: Importar módulo AdmPwd y actualizarlo en el esquema de AD.

El permiso de escritura en los atributos ms-Mcs-AdmPwdExpirationTime y ms-Mcs-AdmPwd de todas las cuentas del equipo tiene que ser añadido a la cuenta integrada. Esto es necesario para que la máquina pueda actualizar la contraseña y la fecha de caducidad de su propia contraseña de administrador local gestionada.

Para visualizar todos los cmdlets disponibles de un módulo podemos usar Get-Command y especificar el módulo.

Get-Command -Module AdmPwd.ps

Figura 4: Ver todos los cmdlets disponibles de un módulo.

Configuración GPO LAPS en Active Directory

Se crea una nueva GPO desde el editor de administrador de políticas de grupo (gpmc.msc). Al instalar la plantilla AdmPwd.admx de LAPS se añaden las nuevas políticas para establecer su configuración.

Computer Configuration > Polices > Administrative Templates > LAPS

Se habilita la política y en el caso de que el administrador local no sea el nombre por defecto (Administrator o Administrador) indicamos el nombre de la cuenta local tipo administrador que esté configurada en los equipos del dominio y los parámetros de las passwords como la: complejidad, longitud y expiración.

Figura 5: Crear y configurar GPO LAPS.

Desplegar el MSI de LAPS al resto de equipos del dominio a través de GPO

Es necesario desplegar el mismo instalador al resto de los equipos del dominio donde se necesite implementar LAPS ya sea en su versión de x64 o x86 y solamente con la característica por defecto habilitada.

La operativa de despliegue dependerá de la herramienta que se estemos usando para la gestión de endpoints de la infraestructura ya sea con SCCM System Center, Microsoft Intune, Puppet, etc.

msiexec /i <PATH>\LAPS.x64.msi /quiet

msiexec /i <PATH>\LAPS.x86.msi /quiet

Para este ejemplo al tratarse de un fichero Microsoft Installer .msi se puede desplegar directamente a través de otra GPO.

Computer Configuration > Policies > Software Settings > Software installation

Se indica la ruta donde está el instalador, el tipo de deployment será "Assigned" (sin modificaciones en sus características de instalación) ya que con la configuración por defecto solo instalaría la característica del cliente (GPO CSE).

Figura 6: Desplegar LAPS a los equipos del dominio a través de GPO. 

Funcionamiento y administración de LAPS

En los objetos tipo "Computer" de la unidad organizativa de Active Directory donde se delegaron los permisos para LAPS podemos comprobar que se han añadido dos nuevos atributos: 

• ms-Mcs-AdmPwd: Almacena la password local del equipo.
• ms-Mcs-AdmPwdExpirationTime: Tiempo en la que la password expirará y será renovada por otra password aleatoria cumpliendo los requisitos establecidos en la GPO.

A través del Editor de interfaces de servicios de Active Directory ADSI (adsiedit.msc) comprobamos como se han creado estos atributos y ver su valor desde la pestaña de editor de atributos de la propia ficha del objeto en la consola de Active Directory (dsa.msc).

Figura 7: Atributos de objeto donde se almacenará la password local aleatoria y rotatoria.

LAPS UI es la interfaz gráfica para una gestión más sencilla de LAPS donde podemos buscar por hostname un equipo del dominio para visualizar su password de administrador local, fecha de expiración y también restablecer su password (en caso de que tengamos permisos de escritura sobre los atributos comentados anteriormente).

Otra forma de visualizar la passwords es a través de PowerShell haciendo uso de los cmdlets que se importan a través del módulo AdmPwd.ps en la instalación de LAPS.

Get-AdmPwdPassword <HOSTNAME> | fl

Get-AdmPwdPassword <HOSTNAME>.Password

Figura 8: LAPS UI para ver y restablecer las passwords locales de los equipos de AD.

También es posible restablecer la password de administrador local de un equipo del dominio desde PowerShell.

Reset-AdmPwdPassword -ComputerName:<HOSTNAME>

Establecer permisos específicos según roles (RBAC)

Solo los usuarios privilegiados del dominio como los Domain Admins tienen permisos de lectura y escritura sobre los valores de los atributos donde se almacena la password y la fecha de expiración. 

En el caso de que se necesite conceder la capacidad de poder ver o editar estos valores de atributos a usuarios que no sean administradores, sino usuarios menos privilegiados a nivel de dominio que proporcionen mantenimiento y soporte a otros empleados de la compañía, se pueden crear grupos de seguridad en Active Directory de solo lectura (LAPS_R) y otro de lectura y escritura (LAPS_RW) donde se puedan asignar estos usuarios de soporte y de esta manera tener un control de permisos más granular.

En este caso asignamos el permiso de solo lectura sobre estos atributos al grupo "LAPS_R". Es posible conceder estos permisos de dos modos: 

Una forma automática a través del siguiente cmdlet donde se hará referencia el grupo de AD y la OU.

Set-AdmPwdReadPasswordPermission -Identity "<OU_AD>" -AllowedPrincipals "<Grupo_Solo_Lectura>"

Con el siguiente cmdlet verificamos la asignación de permisos asignados a la OU.

Find-AdmPwdExtendedRights -Identity "<OU_AD>"

Figura 9: Establecer un grupo de permiso de lectura para LAPS. 

La otra opción sería hacerlo de manera manual estableciendo las DACLs de la OU. En este caso agregando el grupo LAPS_R a las propiedades de seguridad de la OU y en los permisos avanzados permitir las siguientes ACEs "Read ms-Mcs-AdmPwd" y "Read ms-Mcs-AdmPwdExpirationTime".

Figura 10: LAPS - ACEs de lectura establecida a un grupo en una OU de AD.

En el caso que necesitemos agregar un grupo de usuarios para poder restablecer passwords, es decir otorgar permisos de escritura sobre los valores de los atributos de LAPS, usaremos el siguiente cmdlet.

Set-AdmPwdResetPasswordPermission -Identity "<OU_AD>" -AllowedPrincipals "<Grupo_Lectura_Escritura>"

Comprobar los permisos establecidos

Para comprobar de los permisos asignados anteriormente, el usuario de dominio "user2" no forma parte del grupo "LAPS_R" por lo tanto desde la consola de Active Directory no podrá visualizar los atributos de LAPS del equipo "PC10D2".

Figura 11: Comprobación de lectura sin permisos en el atributo de password de AD.

Para cambiar esto y conceder permisos de lectura. Se asigna el usuario "user2" al grupo "LAPS_R" de AD, se reinicia sesión con este usuario para aplicar los cambios y vemos como es posible visualizar desde el editor de atributos del tipo de objeto equipo el valor de la contraseña y la fecha de expiración. 

Figura 12: Comprobación de lectura correcta en el atributo de password de AD

Auditoría de eventos LAPS

La activación de auditoría de los usuarios que consultan y leen con éxito la contraseña de Administrador local de un equipo se puede activar mediante el siguiente cmdlet parte del módulo de AdmPwd.ps. 

Set-AdmPwdAuditing -OrgUnit: <OU_AD> -AuditedPrincipals: <GRUPO/USUARIO>

Cuando una contraseña se lee con éxito, se registra un ID de evento 4662 en el registro de seguridad del controlador de dominio.

Figura 13: Auditar eventos LAPS de consulta y lectura exitosa de la contraseña.

Saludos!